{"id":18115,"date":"2019-03-28T14:02:01","date_gmt":"2019-03-28T12:02:01","guid":{"rendered":"https:\/\/www.kaspersky.es\/blog\/?p=18115"},"modified":"2019-11-22T10:55:08","modified_gmt":"2019-11-22T08:55:08","slug":"patching-strategy-rsa2019","status":"publish","type":"post","link":"https:\/\/www.kaspersky.es\/blog\/patching-strategy-rsa2019\/18115\/","title":{"rendered":"Estrategias para parchear vulnerabilidades de seguridad"},"content":{"rendered":"

\u201cDisculpe, se\u00f1or, \u00bftiene un momento para hablar sobre actualizaciones de seguridad?\u201d<\/p>\n

\u201cLo siento, estoy demasiado ocupado instalando parches\u201d.<\/p>\n

Ahora en serio, merece la pena reflexionar sobre la eficiencia (o no) con la que gestionas los parches.<\/p>\n

En un mundo perfecto instalar\u00edas todos los parches de todo el software<\/em> que utilizas en tu compa\u00f1\u00eda inmediatamente despu\u00e9s de su lanzamiento. Pero en la vida real es m\u00e1s complicado, hay demasiados parches y no tenemos tiempo para todos, por lo que hay que priorizar. Pero \u00bfcu\u00e1l es la mejor forma de hacerlo?<\/p>\n

En la conferencia RSA 2019, Jay Jacobs de Cyentia Institute y Michael Roytman de Kenna Security<\/a>\u00a0presentaron un estudio titulado \u201cThe Etiology<\/a>\u00a0of Vulnerability Exploitation\u201d (\u201cLa etiolog\u00eda del uso de vulnerabilidades\u201d en espa\u00f1ol). Este informe aborda qu\u00e9 vulnerabilidades<\/strong> requieren m\u00e1s atenci\u00f3n y c\u00f3mo mejorar significativamente la estrategia para la instalaci\u00f3n de parches y las actualizaciones de seguridad.<\/p>\n

La premisa b\u00e1sica es que, en la pr\u00e1ctica, no todas las vulnerabilidades se acaban explotando. Si damos esto por hecho, se pueden retrasar una gran cantidad de actualizaciones, priorizando las vulnerabilidades que pueden utilizarse con m\u00e1s seguridad en un ciberataque<\/strong>. Pero \u00bfc\u00f3mo podemos distinguir las vulnerabilidades \u201cpeligrosas\u201d de las m\u00e1s \u201cinofensivas\u201d?<\/p>\n

Equipados con la base de datos de CVE (vulnerabilidades y exposiciones comunes) y las bases de datos de exploits<\/em><\/strong> a disposici\u00f3n del p\u00fablico, adem\u00e1s de los datos de an\u00e1lisis de vulnerabilidades y sistemas IPS\/IDS (un total de 7,3 mil millones de ataques registrados y 2,8 mil millones de vulnerabilidades en 13 millones de sistemas), los investigadores elaboraron un modelo que desempe\u00f1a perfectamente esta tarea. Para ponernos en perspectiva, es necesario un ligero an\u00e1lisis del panorama de vulnerabilidades de seguridad<\/strong>.<\/p>\n\n

\u00bfCu\u00e1ntas vulnerabilidades o CVE existen?<\/h3>\n

Cualquier experto en seguridad de la informaci\u00f3n te dir\u00e1 que el n\u00famero de vulnerabilidades conocidas es enorme, pero ninguno o casi ninguno conoce la cifra exacta. De momento, se han publicado unas 108000 CVE<\/strong>.<\/p>\n

Hay que tener en cuenta que, en el \u00faltimo par de a\u00f1os, la tasa de publicaciones mensuales ha aumentado. Si entre los a\u00f1os 2005 y 2017 se publicaron unas 300-500 CVE al mes, a finales del 2017 la media mensual se dispar\u00f3 a m\u00e1s de 1000 y se ha mantenido desde entonces. \u00bfLo has pensado bien? \u00a1Son una docena de bugs <\/em>nuevos al d\u00eda!<\/p>\n

\"La<\/p>\n

Los exploits<\/em> se suelen dar a conocer justo antes o justo despu\u00e9s de que se publique la CVE pertinente. Hay excepciones, pero en la mayor\u00eda de los casos el margen es m\u00e1s o menos dos semanas alrededor de la fecha de publicaci\u00f3n de la CVE. Por ello, las vulnerabilidades o CVE requieren una respuesta r\u00e1pida.<\/p>\n

\"En<\/p>\n

No hace falta decir que los \u00edndices de instalaci\u00f3n de actualizaciones se quedan un poco atr\u00e1s. Como promedio, un mes despu\u00e9s de la detecci\u00f3n, solo se parchean un cuarto de las vulnerabilidades. Se tarda unos 100 d\u00edas en eliminar la mitad y, a\u00fan as\u00ed, un cuarto queda sin parchear un a\u00f1o despu\u00e9s.<\/p>\n

\"Como<\/p>\n

M\u00e1s de dos tercios de las vulnerabilidades sin parche<\/strong> que existen se encuentran en los productos de tan solo tres proveedores. No hace falta que digamos qu\u00e9 vendedores o productos:<\/p>\n

\"M\u00e1s<\/p>\n

\"Los<\/p>\n

Mientras tanto, el 77 % de las CVE no ha publicado ning\u00fan exploit<\/em>. Cabe destacar que no todas las vulnerabilidades publicadas aparecen en entornos reales, de hecho, solo 37000 de las 108000 CVE que existen. Adem\u00e1s, solo existen 5000 CVE en simultaneidad y que se puedan explotar. Estas son las vulnerabilidades que deber\u00edan<\/em> priorizarse, basta con tan solo identificarlas de forma correcta.<\/p>\n

\"De<\/p>\n

Estrategias para parchear<\/h3>\n

Los investigadores miden la relevancia de las estrategias para parchear con dos m\u00e9tricas: el intercambio de vulnerabilidades \u201cpeligrosas\u201d en el n\u00famero total de las parcheadas (con eficiencia) y, por el contrario, el intercambio de vulnerabilidades parcheadas<\/strong> en el n\u00famero total de las \u201cpeligrosas\u201d (cobertura).<\/p>\n

\"Los

Si esta imagen te resulta familiar, seguramente nada ha cambiado<\/a><\/p><\/div>\n

Una de las estrategias para parchear m\u00e1s aceptadas se basa en el CVSS (Sistema de puntuaci\u00f3n de vulnerabilidades comunes), priorizando las puntuaciones del CVSS por encima de un valor en concreto. Por ejemplo, si calculamos la eficiencia y la cobertura de CVSS 10, obtenemos un 23 % de eficiencia y un 7 % de cobertura. Resulta interesante que el mismo resultado (al menos por estas m\u00e9tricas) se puede conseguir instalando parches de forma aleatoria.<\/p>\n

\"La<\/p>\n

La estrategia m\u00e1s com\u00fan, parchear todas las vulnerabilidades con una puntuaci\u00f3n CVSS \u201celevada\u201d (7 o m\u00e1s), da mejor resultado. Este enfoque no est\u00e1 mal en general, pero lleva mucho tiempo, ya que tienes que priorizar la instalaci\u00f3n de una gran cantidad de parches de seguridad<\/strong>.<\/p>\n

\"Comparaci\u00f3n<\/p>\n

Otra estrategia ser\u00eda priorizar la instalaci\u00f3n de parches seg\u00fan el vendedor. Despu\u00e9s de todo, los desarrolladores presentan diferencias entre las explotaciones reales y el n\u00famero total de CVE, por lo que resultar\u00eda l\u00f3gico priorizar a aquellos cuyos productos contengan las vulnerabilidades con m\u00e1s posibilidades de explotaci\u00f3n.<\/p>\n

\"Las<\/p>\n

No obstante, si nos basamos en la eficiencia y la cobertura, esta estrategia es peor<\/em> que parchear de forma aleatoria, de hecho, resulta m\u00e1s o menos la mitad de eficaz.<\/p>\n

\"Las<\/p>\n

Por lo que, a la larga, esta estrategia es incluso menos relevante que las que se basan en CVSS.<\/p>\n

Modelo de c\u00e1lculo de probabilidad para la explotaci\u00f3n de vulnerabilidades<\/h3>\n

Esto nos lleva de nuevo al modelo desarrollado por los investigadores. Comparando los datos de las CVE, bases de datos de exploits<\/em><\/strong> disponibles al p\u00fablico, y los sistemas IPS\/IDS, el equipo ha podido identificar un conjunto de indicios que influencian la probabilidad de que se utilice una vulnerabilidad.<\/p>\n

Por ejemplo, por un lado, los indicios como una referencia CVE de Microsoft<\/strong> o la presencia de un exploit<\/em> en Metasploit, aumentan dr\u00e1sticamente las probabilidades de explotaci\u00f3n de la vulnerabilidad en cuesti\u00f3n.<\/p>\n

\"Los<\/p>\n

Por otro lado, ciertos signos reducen la probabilidad de explotaci\u00f3n, como una vulnerabilidad en el navegador Safari<\/strong>, un exploit<\/em> que se public\u00f3 en la base de datos ExploitDB (que no es muy conveniente a efectos pr\u00e1cticos) o la presencia de los t\u00e9rminos \u201cautentificado\u201d o \u201cdoble liberaci\u00f3n de memoria\u201d en las CVE entre otros. Gracias a la combinaci\u00f3n de estos factores, los investigadores pudieron calcular la probabilidad de que se utilice una vulnerabilidad en concreto.<\/p>\n

\"Ciertos<\/p>\n

Para verificar la precisi\u00f3n del modelo, los investigadores compararon sus predicciones con datos de ciberataques reales y esto fue lo que descubrieron:<\/p>\n