HISPASEC. Cuánto tardan los fabricantes de software en arreglar una vulnerabilidad? www. HISPASEC.COM

Transcripción

1 EDICIÓN V HISPASEC Cuánto tardan los 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 SERGIO DE LOS Diseño y revisión: José Mesa jmesa@hispasec.com

2 Reconocimiento-NoComercial-SinObraDerivada 3.0 España (CC BY-NC-ND 3.0) Usted es libre de: copiar, distribuir y comunicar públicamente la obra Bajo las condiciones siguientes: Reconocimiento Debe reconocer los créditos de la obra de la manera especificada por el autor o el licenciador (pero no de una manera que sugiera que tiene su apoyo o apoyan el uso que hace de su obra). No comercial No puede utilizar esta obra para fines comerciales. Sin obras derivadas No se puede alterar, transformar o generar una obra derivada a partir de esta obra. Entendiendo que: Renuncia Alguna de estas condiciones puede no aplicarse si se obtiene el permiso del titular de los derechos de autor Dominio Público Cuando la obra o alguno de sus elementos se halle en el dominio público según la ley vigente aplicable, esta situación no quedará afectada por la licencia. Otros derechos Los derechos siguientes no quedan afectados por la licencia de ninguna manera: Los derechos derivados de usos legítimos u otras limitaciones reconocidas por ley no se ven afectados por lo anterior. Los derechos morales del autor. Derechos que pueden ostentar otras personas sobre la propia obra o su uso, como por ejemplo derechos de imagen o de privacidad. Aviso Al reutilizar o distribuir la obra, tiene que dejar bien claro los términos de la licencia de esta obra. Basada en un trabajo de Hispasec Sistemas Todas las marcas y logotipos que se encuentran en este estudio son propiedad de sus respectivas compañías o dueños. Los permisos más allá de esta licencia están disponibles en Hispasec.com. Página 2

3 Cuánto tardan los grandes fabricantes 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, achacando 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 segundo. 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 creadores de software en solucionar una vulnerabilidad cuando no tienen 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, 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 [1] para realizar un pequeño estudio al respecto. Actualización del estudio sobre las vulnerabilidades En septiembre de 2009 publiqué un estudio sobre cuánto tardaban los grandes fabricantes en solucionar vulnerabilidades no públicas. Dos años después, actualizamos ese estudio, ampliando los datos, recalculando las cifras, corrigiendo y aligerando el informe. Novedades: * Si hace dos años se analizaron vulnerabilidades desde 2005 hasta septiembre de 2009, ahora se amplía el cálculo desde 2005 hasta final de julio de * Se añaden dos fabricantes a la comparativa: RealNetworks y Mozilla. * En abril de 2009 Oracle compró Sun, por lo que Sun queda excluida de este informe, y las nuevas vulnerabilidades desde entonces se le atribuyen como responsabilidad de Oracle. * En agosto de 2010, ZeroDayInitiative introdujo una nueva política en la que esperaría un máximo de 180 días al fabricante para emitir un parche. De no ser así, publicaría en cualquier caso la vulnerabilidad. Se han dado este tipo de casos, especialmente con HP. Las hemos incluido igualmente en la estadística. * De algunos fabricantes disponemos de muchos más datos. En dos años se ha incrementado muchísimo la actividad de vulnerabilidades reportadas a través de estas empresas para fallos en Adobe, Novell y Apple, por ejemplo. * Se ha eliminado la gravedad de las vulnerabilidades como cuestión comparativa. Página 3

4 Cómo se ha realizado el estudio Estudio sobre la demora de los fabricantes de software en la corrección de vulnerabilidades no públicas. V2 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ó una 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 Adobe) 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 indicada. 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 julio de Se han identificado por su CVE [2]. 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. Con qué criterio se han elegido a los fabricantes Para elegir a los fabricantes, simplemente se han elegido a los que contaban con un buen número de vulnerabilidades reportadas a través de estos medios (el que menos, cuenta con 41), para poder así obtener unos datos más consistentes. Según fabricante, el número de vulnerabilidades estudiadas que han sido reportadas desde 2005 a idefense y ZeroDayInitiative (y su comparación con el informe anterior) son las que se ven en el cuadro de la derecha. Fabricante Vulnerabilidades estudiadas en informe anterior ( ) Vulnerabilidades estudiadas en el informe actual ( ) Novell HP Microsoft Apple IBM CA Symantec Oracle Adobe Mozilla - 41 RealNetworks - 54 Página 4

5 Descargo de responsabilidad - 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 ofrecer un estudio objetivo en este aspecto, pero lo hemos intentado en la medida de lo posible. Los valores ofrecidos no pretenden más que dar 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 no son reportados por estas dos vías, puesto que muchas de las vulnerabilidades solucionadas por los fabricantes son descubiertas por su propio equipo de seguridad, y rara vez confiesan desde cuándo llevan trabajando en ellas. Por tanto advertimos que estas cifras que ofrecemos pretenden ser rigurosas en la medida de lo posible, y darnos una idea global de cuánto necesita un gran fabricante para solucionar un fallo de seguridad sin la presión de que sea conocido. Con respecto a las erratas y errores, el informe ha pasado varios filtros de corrección, pero es probable que no todas hayan sido detectadas y subsanadas. Nos disculpamos de antemano. Página 5

6 Todos los fabricantes 1045 vulnerabilidades estudiadas En este gráfico se observa la media de cada fabricante comparada con la media global (177 días, aproximadamente). También hemos añadido el coeficiente de variación [3]. Se observa un claro ganador diferente a la comparativa que realizamos hace dos años. Si entonces fue Oracle la que más tardaba en arreglar vulnerabilidades, ahora es RealNetworks (nuevo en este informe) el que destaca entre todos los demás con 321 días de media. Más de 10 meses de media para solucionar una vulnerabilidad reportada de forma privada. Además, su coeficiente de dispersión no es demasiado alto, lo que indica que a la hora de calcular la media, no existen valores muy dispersos que hayan podido contaminarla. Le sigue IBM con 250 días de media, aunque en este caso el coeficiente de variación es mayor, lo que indica que existen datos de vulnerabilidades en IBM muy dispersos. En realidad, es cierto que algunas vulnerabilidades puntuales desvirtúan ligeramente el valor de la media. Mozilla es la más rápida con sólo 74 días de media para solucionar errores. Es necesario destacar que es también el fabricante con menos vulnerabilidades reportadas de forma privada a través de estos medios (sólo 41). Insistimos en que esto no significa que el nivel global de vulnerabilidades encontradas sea menor, sino que simplemente son menos reportadas a través de sistemas privados de recompensa. Sorprenden Apple y Adobe, con niveles por debajo de la media. Cada uno necesita unos cuatro meses para solucionar sus errores. Apple y Adobe han sufrido un espectacular aumento de número de vulnerabilidades reportadas a través de estos medios privados: * En el caso de Apple, si de 2005 a 2009 se le encontraron 61 vulnerabilidades, de 2009 a 2001 se encontraron 78 más. * Y en el caso de Adobe, de 2005 a 2009 contó con 29 vulnerabilidades para el estudio anterior, y de 2005 a 2011 ha aumentado hasta 113 errores. Esto significa que en dos años han ganado en popularidad y en fallos de software reportados de forma privada. Página 6

7 Oracle parece haber mejorado en cuestión de velocidad de parcheo, aunque hay que tener en cuenta que sus circunstancias son complejas desde que en 2009 adquirió Sun, pues heredó diferentes sistemas que ahora están bajo su responsabilidad. Aun así, 195 días de media no están mal teniendo en cuenta lo mal parados que salían en el anterior estudio (llegó a 301 días de media). Por tanto, durante estos años parece que ha mejorado su velocidad de parcheo. La mayoría de las vulnerabilidades (un 67,53%) desde 2005 se han solucionado en 6 meses o menos. Recordemos que 180 días es el máximo de tiempo que consideró ZeroDayIniativie que necesitaba un fabricante para solucionar el fallo. Llama la atención que casi una de cada cuatro vulnerabilidades (un 22,73%) tarde entre seis meses y un año en ser resuelta. Más allá del año se van cerca de un 10% de las vulnerabilidades estudiadas. La visión por porcentaje de resolución según tramos de tiempo ofrece una lectura adicional. RealNetworks, no sorprende: también es el fabricante con un porcentaje menor de vulnerabilidades resueltas en menos de 6 meses. Apple, Adobe y Novell también consiguen arreglar la mayoría de sus fallos en menos de 180 días. Página 7

8 Top ten Las 10 vulnerabilidades que más han tardado en ser solucionadas. Vulnerabilidad CVE CVSS Día reportada Día resuelta Días IBM Informix Dynamic Server librpc.dll Integer Overflow Remote Code Execution Vulnerability Hewlett-Packard OpenView Data Protector Backup Client Service Buffer Overflow Vulnerability HP Mercury LoadRunner Agent Trusted Input Remote Code Execution Vulnerability Sin duda HP e IBM, dos pesos pesados, son los que más tardan puntualmente en arreglar ciertos errores. 5 vulnerabilidades les pertenecen en este top ten. IBM cuenta con otras 5 y Microsoft sólo una. Las 10 vulnerabilidades más rápidas en ser solucionadas. CVE /05/07 18/10/ CVE /10/06 17/12/ CVE /03/07 06/05/ IBM AIX swcons Local Arbitrary File Acces CVE /12/04 30/10/ (0day) CA ETrust Secure Content Manager Common Services Transport Remote Code Execution Vulnerability IBM Informix Dynamic Server oninit.exe EXPLAIN Remote Code Execution Vulnerability (0day) IBM Lotus Domino icalendar Meeting Request Parsing Remote Code Execution Vulnerability (0day) IBM Lotus Domino IMAP/POP3 Non-Printable Character Expansion Remote Code Execution Vulnerability (0day) IBM Lotus Domino SMTP Multiple Filename Arguments Remote Code Execution Vulnerability CVE /05/08 07/02/ /02/08 18/10/ CVE /08/08 07/02/ CVE /08/08 07/02/ CVE /08/08 07/02/ Vulnerabilidad CVE CVSS Día reportada Día resuelta Días Novell Teaming ajaxuploadimagefile Remote Code Execution Vulnerability Apple QuickTime H.263 Array Index Parsing Remote Code Execution Vulnerability Novell Zenworks Handheld Management ZfHIPCnd. exe Opcode 2 Remote Code Execution Vulnerability Computer Associates BrightStor ARCserve Backup RPC Engine PFC Request Buffer Overflow Apple QTJava toqtpointer() Pointer Arithmetic Memory Overwrite Vulnerability Adobe Flash Player Multiple Tag JPEG Parsing Remote Code Execution Vulnerability CVE /07/10 21/07/10 2 CVE /04/10 09/04/10 3 CVE /01/11 26/01/11 5 CVE ,5 03/01/07 11/01/07 8 CVE ,6 23/04/07 01/05/07 8 CVE ,3 08/06/10 16/06/10 8 Apple Mac OS X vpnd Server_id Buffer Overflow CAN ,2 25/04/05 04/05/05 9 Mozilla Firefox Cross Document DOM Node Moving Remote Code Execution Vulnerability Hewlett-Packard Operations Manager Server Backdoor Account Code Execution Vulnerability CA ETrust Secure Content Manager Gateway FTP LIST Stack Overflow Vulnerability CVE /03/10 05/04/10 10 CVE /11/09 20/11/09 11 CVE /05/08 04/06/08 12 Apple cuenta con cuatro vulnerabilidades en este Top Ten, curiosamente más que Mozilla, cuya media global es menor. Una vulnerabilidad de Novell destaca como la más rápida, pues solo tardó 2 días en ser resuelta. Página 8

9 Hewlet Packard (HP) 78 vulnerabilidades estudiadas Una de las vulnerabilidades que aparece sin CVE es un claro ejemplo de los problemas que pueden ocurrir si un fabricante no se da prisa a la hora solucionar un fallo, aunque este no sea público. El problema fue reportado a HP el 16 de febrero de 2007, pero muy poco después otros investigadores, con no muy buenas intenciones, descubrieron el fallo por su cuenta e hicieron público un exploit para aprovecharlo. HP se vio obligada a priorizar esta vulnerabilidad y hacerla pública antes de lo planeado (solo tardaron 45 días, una variación importante con respecto a su media). Existen otras dos curiosidades con HP, que no hemos incluido por no contaminar la media, pero que nos parecen significativas. Idefense esperó durante casi 3 años a que solucionase un fallo en el componente ldcconn de HP-UX 11.11i. Pero HP no lo hizo, a pesar de la insistencia de idefense puesto que se trataba de un producto que había dejado de ser soportado por HP en Se hizo público el fallo sin parche. Exactamente lo mismo ocurrió con el comando pfs_mountd.rpc de HP-UX. Existen algunas vulnerabilidades que HP ha tardado más de 1000 días en solucionar, que contaminan su media, porque luego, en realidad, un 62% de sus errores se solucionan antes de 6 meses. Además, HP es la que más ha sufrido la nueva política de ZeroDayInitiative de revelar las vulnerabilidades no solucionadas en 180 días. Página 9

10 IBM 139 vulnerabilidades estudiadas Uno de los pesos pesados que más tarda en solucionar sus vulnerabilidades. Las vulnerabilidades de IBM se reparten mayoritariamente entre sus productos Lotus y su sistema operativo AIX y su base de datos DB2. Sólo consigue corregir un 53,33% de sus vulnerabilidades en menos de seis meses. Página 10

11 Adobe 113 vulnerabilidades estudiadas Adobe, con una nefasta carrera en la seguridad en los últimos tiempos y siendo objetivo predilecto de atantes, parece que no tarda tanto en solucionar sus errores como pudiese parecer. Mirando sus vulnerabilidades, Shockwave es el producto que más fallos aglutina y la bestia negra de Adobe. Le sigue de cerca Flash Player. Lo curioso es que Adobe suele tardar muy poco en solucionar fallos en Shockwave, y gracias a esto ha conseguido una media tan baja. Sin embargo, en otro de sus productos con enormes problemas de seguridad, Adobe Reader, su media aumenta. La excepción fue un fallo en Shockwave (CVE ) que necesitaron 408 días para solucionar. Si no fuese por un error en Reader (CVE ) que tardó 665 días en solucionarse, su medía podría bajar algo más. De hecho un excelente 81,4% de sus fallos se corrige antes de los 6 meses. Página 11

12 Apple 139 vulnerabilidades estudiadas El programa con más errores en Apple es sin duda QuickTime. Le sigue webkit (el motor de código abierto de Safari) de cerca. QuickTime es el protagonista de unas 70 vulnerabilidades de las 139 estudiadas. Igualmente, consigue un buen dato: corregir antes de 6 meses un 81% de sus vulnerabilidades. Página 12

13 Oracle 87 vulnerabilidades estudiadas Si bien en el estudio anterior salió muy mal parado, en esta actualización ha conseguido no destacar como el que más tarda en solucionar vulnerabilidades. La compra de Sun en 2009 y el aumento de vulnerabilidades estudiadas ha hecho que su media disminuya hasta 195 días por vulnerabilidad. Página 13

14 Microsoft 225 vulnerabilidades estudiadas Microsoft ha mejorado infinitamente su política de seguridad desde, aproximadamente, Aun así (o quizás a causa de) sufre tremendos problemas para gestionar el problema de seguridad que acarrea desde sus inicios. Un desastroso planteamiento de la seguridad en sus productos, está haciendo que arrastre problemas de seguridad gravísimos que los atacantes saben aprovechar. Su enorme popularidad lo hace apetitoso objetivo de atacantes, y sin duda es el sistema con más vulnerabilidades reportadas a través de idefense y ZeroDayInitiative, no en vano son las mejores pagadas. Esto, unido a la gran cantidad de productos y sistemas y la gran interoperatibilidad que existe entre ellos, hace que cada parche deba ser mirado con lupa antes para que la estabilidad quede garantizada. Tampoco hay que olvidar que Microsoft es sorprendida con problemas de seguridad 0day varias veces al año, con lo que debe priorizarlos y solucionarlos cuanto antes, cosa que a veces consigue y otras no tanto. En general, se toma con calma los fallos de seguridad que les son reportados de forma privada, aunque a veces esto es un arma de doble filo. En una de las últimas vulnerabilidades (CVE ), se le adelantaron los atacantes. Microsoft conocía el fallo desde la primavera de 2008, pero no fue hasta principios de julio de 2009 cuando sacó un parche porque otros atacantes la descubrieron independientemente y comenzaron a aprovecharla para infectar sistemas. En ese momento Microsoft dedicó todos sus recursos a solucionarlo, y dispuso del parche en apenas unos días (llevaba trabajando en él un año). Este fallo no ha sido reflejado en este estudio porque no fue reportado a través de estas compañías. Destaca en especial en Microsoft, la vulnerabilidad CVE , por esperar 1021 días (tres años) en solucionarla. Esto puede tener su explicación en que el fallo solo afecta a Microsoft Office 2000 y XP, productos de los que Microsoft, ya no se preocupa tanto. Sin embargo, es curioso como otros fallos en Office (también afectando a 2000 y XP) son solucionados en apenas 6 meses. No se han modificado sustancialmente los datos con respecto al informe anterior. Internet Explorer y Excel son las aplicaciones sobre las que más vulnerabilidades se han reportado. Microsoft consigue resolver la mitad de sus vulnerabilidades en menos de seis meses. Página 14

15 Symantec 50 vulnerabilidades estudiadas Aunque con algunas vulnerabilidades que le han llevado casi dos años resolver, la media de Symantec se encuentra casi en sintonía con la media general: 170 días. Consigue resolver sus fallos de seguridad en menos de 6 meses en un 66% de las ocasiones. Página 15

16 Novell 104 vulnerabilidades estudiadas Novell ha conseguido pasar desapercibido en este estudio, manteniéndose por debajo de la media con 120 días para solucionar fallos, aunque con un coeficiente de variación relativamente elevado. Los productos con más fallos en Novell han sido Zennetworks y edirectory. Sus resultados son similares a los del estudio anterior. Consigue también muy buenos datos al corregir un 83,6% de sus fallos antes de seis meses, aunque su media empeora ligeramente por algunos fallos que se elevan por encima de los 500 días. Página 16

17 Mozilla 41 vulnerabilidades estudiadas Mozilla ha conseguido una media de sólo 74 días para corregir sus vulnerabilidades reportadas de forma privada. Aunque se trate de software libre y se encuentre extendido el mito de que las vulnerabilidades con esta filosofía se resuelven casi instantáneamente, esto no es cierto. La Fundación necesita de media tres meses y medio para solucionar fallos reportados de forma privada. Esto no quiere decir nada sobre cuánto necesita la Fundación para solucionar vulnerabilidades cuando ya son públicas. Habitualmente el tiempo es sustancialmente menor. También cabe destacar que Mozilla solo ha aportado 41 vulnerabilidades para este estudio. Nos vemos obligados a insistir en que esto no significa que sufra un número menor de vulnerabilidades globalmente, sino que no han sido reportadas por los medios privados que hemos elegido para el estudio. Además de la media más baja, el coeficiente de variación es también el más bajo, lo que indica que los valores para calcular la media son muy regulares, sin grandes altibajos. Es el único fabricante con el que ninguna vulnerabilidad se va más allá del año. Sin duda, el programa con más errores de Mozilla es Firefox. Es necesario matizar que el perfil de Mozilla y el de otros fabricantes comparados es muy diferente. Su software se centra básicamente en el navegador, mientras que IBM, HP o Microsoft por ejemplo cuentan con una gama de productos más amplia y compleja (sistemas operativos, mainframes etc), incluso orientada a un entorno diferente. No hay que olvidar que estas circunstancias pueden influir también en el tiempo necesario corregir los fallos. Página 17

18 Real Networks 54 vulnerabilidades estudiadas El ganador y que más tarda en resolver sus problemas de seguridad es RealNetworks. La mayoría de sus vulnerabilidades se concentran en el programa RealPlayer, el popular reproductor multimedia sufre graves problemas de seguridad que además, toman de media 10 meses en ser resueltos. Página 18

19 Computer Associates (CA) 51 vulnerabilidades estudiadas CA tiene una buena media de resolución de vulnerabilidades en menos de 6 meses, casi las tres cuartas partes de sus fallos de seguridad se resuelven antes de ese tiempo. Sin embargo algunos casos puntuales han hecho que su media se eleve demasiado. Así lo confirma su coeficiente de variación tan alto. Esto quiere decir que existen valores muy dispersos. BrightStore es el producto que más fallos ha acumulado de esta marca. Página 19

20 Conclusiones Solucionar vulnerabilidades es algo complejo. Así lo demuestran las cifras que hemos manejado en este estudio. Sobre más de mil vulnerabilidades estudiadas, la media es de 6 meses para solucionar una vulnerabilidad. Se observa cómo el tiempo en general es abultado entre todos los fabricantes estudiados. Acumulan una media de 177 días de media global, lo que no se diferencia tanto del estudio realizado hace dos años. La mayoría de las vulnerabilidades se resuelven antes de esos 6 meses (un 67,53%), pero aun así, en cerca del 10% de los casos se necesita más de un año para arreglarlas. Si se ha mantenido la media con respecto al informe anterior, la incorporación en el nuevo estudio de los dos fabricantes (Mozilla y RealNetworks) ha servido para obtener dos datos muy distintos en el mismo. Ambos se han posicionado respectivamente como, el creador de software al que menos tiempo lleva resolver una vulnerabilidad (Mozilla) y al que más (Real). Esto puede servir para mirar con perspectiva el estudio anterior realizado hace dos años. Se podrían clasificar en dos grandes grupos: * RealNetworks, Oracle, IBM, HP y Microsoft que pasan de la media global. * Novell, Apple, CA, Symantec, Adobe y Mozilla que bajan de la media global, destacando Mozilla como el que disfruta de la media más baja. Lo que también cabe destacar son las vulnerabilidades puntuales que, por parte de casi todos los fabricantes, son resueltas bien en unos días, bien en año y medio o dos años, y que se salen totalmente de la media. Estos casos puntuales a veces tienen explicación pero en ocasiones parecen no estar justificados. Sergio de los Santos info@hispasec.com Telf: (+34) Fax: (+34) Página 20

21 Anexo: [1] idenfense y ZeroDayInitiative Son dos compañías que compran vulnerabilidades, con la única condición de que se le cedan en exclusiva. La intención de estas dos compañías 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. [2] 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. Es 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 las vulnerabilidades es por su CVE. Si no existe CVE del problema, lo hemos identificado como CVE [3] Coeficiente de variación Al realizar un estudio estadístico en dos poblaciones diferentes, la media puede llegar a ser muy engañosa. Esta circunstancia es aprovechada en otros estudios como arma de doble filo. No queremos caer en esa trampa. Ya se sabe que si dos personas comparten un pollo para comer, pero una de ellas se lo come todo, según la media estadística ambas habrían comido la mitad. Es necesario conocer la media y el grado de dispersión, para no llevarse a engaño. Al calcular una media sobre 20 objetos, un par de valores muy elevados pueden, por ejemplo, contaminarla. Así que para eso se calcula el coeficiente de variación. Cuando existen varias poblaciones, no podemos acudir a la desviación típica para ver la mayor o menor homogeneidad de los datos, sino a otro parámetro llamado coeficiente de variación y que se define como el cociente entre la desviación típica y la media. El coeficiente de variación es la división entre la desviación típica y la media, que nos dice el grado de dispersión. Lo importante es saber que cuanto mayor sea, más dispersos son los resultados de la media. Por el contrario, cuanto más pequeño el valor, más homogéneos los valores. Un coeficiente de variación mayor que 1 indica la presencia de algunos valores erráticos en la muestra que pueden tener una gran influencia en la estimación. La media no sería muy representativa en estos casos. Página 21