{"id":14250,"date":"2019-03-28T11:55:08","date_gmt":"2019-03-28T17:55:08","guid":{"rendered":"https:\/\/latam.kaspersky.com\/blog\/?p=14250"},"modified":"2022-03-27T05:14:35","modified_gmt":"2022-03-27T11:14:35","slug":"patching-strategy-rsa2019","status":"publish","type":"post","link":"https:\/\/latam.kaspersky.com\/blog\/patching-strategy-rsa2019\/14250\/","title":{"rendered":"RSAC 2019: en busca de la estrategia perfecta de parcheo"},"content":{"rendered":"

\u2014Disculpe, se\u00f1or \u00bftiene un minuto para hablarle sobre las actualizaciones de seguridad?<\/p>\n

\u2014Lo siento, pero estoy muy ocupado instalando parches.<\/p>\n

Bromas aparte, vale la pena detenerse a pensar sobre qu\u00e9 tan eficientemente administras los parches.<\/p>\n

<\/strong><\/p>\n

En un mundo ideal, instalar\u00edas los parches para todo el software<\/em> en uso en tu empresa tan pronto se lancen. Pero en la vida real, las cosas resultan m\u00e1s complicadas, y nunca hay tiempo suficiente para todos los parches. As\u00ed que debes establecer prioridades. Pero, \u00bfcu\u00e1l es el mejor modo?<\/p>\n

En la Conferencia RSA 2019, Jay Jacobs del Cyenta Institute y Michael Roytman de Kenna Security<\/a> presentaron un estudio titulado \u201cThe Etiology<\/a> of Vulnerability Exploitation\u201d (\u201cEtiolog\u00eda del aprovechamiento de vulnerabilidades\u201d). Este estudio bien argumentado abord\u00f3 las vulnerabilidades que merecen mayor atenci\u00f3n y c\u00f3mo mejorar dr\u00e1sticamente la instalaci\u00f3n de parches y la estrategia de actualizaci\u00f3n de seguridad.<\/p>\n

La premisa b\u00e1sica consiste en que, en la pr\u00e1ctica, no todas la vulnerabilidades se ven aprovechadas. Asumiendo que esto sea cierto, se pueden descartar la gran mayor\u00eda de las actualizaciones, dando prioridad a las vulnerabilidades que realmente pueden usarse (y que muy probablemente lo sean) en un ataque. Pero, \u00bfc\u00f3mo identificas las vulnerabilidades \u201cpeligrosas\u201d para una variedad en \u201csu mayor\u00eda\u201d inofensiva?<\/p>\n

Mediante las descripciones de la base de datos de CVE (Exposiciones y vulnerabilidades comunes, por sus siglas en ingl\u00e9s)\u00a0y las bases de datos p\u00fablicas sobre exploits<\/em>, as\u00ed como los datos provenientes de an\u00e1lisis de vulnerabilidad 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 construyeron un modelo que maneja bastante bien las tareas. Para poner eso perspectiva se necesita un poco de an\u00e1lisis sobre el panorama de vulnerabilidad.<\/p>\n\n

\u00bfCu\u00e1ntas CVE existen en activo?<\/h2>\n

Cualquier experto en seguridad inform\u00e1tica te dir\u00e1 que la cantidad de vulnerabilidades es enorme. Pocos, si alguno, saben la cifra exacta. A la fecha, se han publicado 108,000 CVE.<\/p>\n

Asimismo, toma en cuenta que hace un par de a\u00f1os la tasa de de publicaciones mensuales aument\u00f3: si durante los a\u00f1os 2005\u20132017 cerca de 300\u2013500 CVE se publicaron\u00a0 cada mes, al final del 2017, el valor promedio mensual se dispar\u00f3 a 1,000, y desde entonces ha sido alto. Pi\u00e9nsalo: \u00a1eso equivale a una docena de nuevos bugs<\/em> cada d\u00eda!<\/p>\n

\"La<\/strong><\/p>\n

La existencia de un exploit<\/em> generalmente se conoce poco antes o inmediatamente despu\u00e9s de la publicaci\u00f3n de la CVE pertinente. Existen excepciones, pero en la mayor\u00eda de los casos, la ventana es m\u00e1s o menos de dos semanas en torno a la fecha de publicaci\u00f3n de las CVE. De este modo, las CVE exigen una respuesta r\u00e1pida.<\/p>\n

\"En<\/strong><\/p>\n

Sobra decir que las tasas de instalaciones de actualizaciones se quedan un poco atr\u00e1s. En promedio, solamente un cuarto de las vulnerabilidades se parchan un mes despu\u00e9s de su detecci\u00f3n. Toma 100 d\u00edas eliminar la mitad, y un cuarto permanece sin parche un a\u00f1o despu\u00e9s.<\/p>\n

\"En<\/p>\n

M\u00e1s de tres tercios de las vulnerabilidades sin parche existen en productos provenientes de solo tres proveedores. No hay m\u00e9rito alguno en adivinar qu\u00e9 proveedores y qu\u00e9 productos:<\/p>\n

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

\"Productos<\/strong>Mientras, un 77% de las CVE no tienen exploits<\/em> publicados. Asimismo, resulta interesante que no todas las vulnerabilidades publicadas se encuentran en ambientes reales; solamente 37,000 de los 108,000 CVE existentes. Y solamente existen 5,000 CVE son al mismo tiempo aprovechables y en activo. Estas son las vulnerabilidades que deber\u00edan<\/em>\u00a0gozar prioridad; solamente hace falta que se las identifique correctamente.<\/p>\n

\u00a0<\/p>\n

\"De
\n<\/strong><\/p>\n

Estrategias de parcheo existentes<\/h2>\n

Los investigadores midieron la importancia de las estrategias de parcheo mediante dos m\u00e9tricas: la porci\u00f3n de vulnerabilidades \u201cpeligrosas\u201d dentro del n\u00famero total de aquellas parchadas (eficiencia); y a la inversa: la porci\u00f3n de vulnerabilidades parchadas dentro del n\u00famero total de aquellas \u201cpeligrosas\u201d (cobertura).<\/p>\n

\"

Si esta imagen te parece familiar, probablemente se deba a que no es nada nuevo<\/a>.<\/p><\/div>\n

\u00a0<\/p>\n

Una de las estrategias de parcheo generalmente aceptadas se basan en el Sistema de puntaje de vulnerabilidades comunes (CVSS, por sus siglas en ingl\u00e9s), mediante la cual se asigna prioridad a los puntajes de CVSS que rebasan un valor espec\u00edfico. El c\u00e1lculo de eficiencia y cobertura para CVSS de 10 arroja un 23% y un 7%, respectivamente. Es digno de menci\u00f3n que exactamente el mismo resultado (al menos seg\u00fan estas m\u00e9tricas) puede lograrse mediante la instalaci\u00f3n aleatoria de parches.<\/p>\n

La estrategia de \"parchar solamente las vulnerabilidades con CVSS de 10\" es tan efectiva como instalar parches aleatoriamente.<\/strong><\/p>\n

\u00a0<\/strong>El m\u00e9todo m\u00e1s com\u00fan es parchar todo lo que presente un puntaje \u201celevado\u201d de CVSS (7 o superior), lo cual produce resultados notablemente mejores. Este m\u00e9todo no es malo en su conjunto, pero requiere tiempo puesto que significa dar prioridad a la instalaci\u00f3n de una gran cantidad de parches.<\/p>\n

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

Una estrategia diferente ser\u00eda dar prioridad al parcheo seg\u00fan el proveedor. Despu\u00e9s de todo, los desarrolladores manejan diferentes cocientes entre la cantidad real de exploits<\/em> y el n\u00famero total de CVE, as\u00ed que es l\u00f3gico dar prioridad a aquellos cuyos productos contengan las vulnerabilidades con mayor probabilidad de aprovechamiento pr\u00e1ctico.<\/p>\n

\"Las<\/strong><\/p>\n

Sin embargo, con base en la eficiencia y cobertura, esta estrategia resulta peor\u00a0<\/em>que el parcheo aleatorio: es la mitad de efectiva.<\/p>\n

\"Las<\/strong><\/p>\n

\u00a0<\/strong>A la larga, este m\u00e9todo es todav\u00eda menos pertinente que aquel basado en CVSS.<\/p>\n

Modelo de c\u00e1lculo de probabilidad para el aprovechamiento de vulnerabilidades<\/h2>\n

Esto nos trae de vuelta al modelo que los investigadores elaboraron. Al comparar las descripciones de CVE, las bases de datos p\u00fablicas de exploits<\/em> y los sistemas de IPS\/IDS, el equipo pudo identificar una serie de signos que influyen en la probabilidad de que una vulnerabilidad tenga aprovechamiento pr\u00e1ctico.<\/p>\n

Por ejemplo, por una parte, los signos como la referencia de CVE de Microsoft, o la presencia de un exploit<\/em> en Metasploit, incrementa dram\u00e1ticamente la probabilidad de aprovechamiento de la vulnerabilidad en cuesti\u00f3n.<\/p>\n

\"Los<\/strong><\/p>\n

Alguno signos, por otra parte, reducen la probabilidad de aprovechamiento, como una vulnerabilidad dentro del navegador Safari, un exploit<\/em> que se public\u00f3 en la base de datos de ExploitDB (el cual, por cuestiones pr\u00e1cticas, no resulta conveniente), la presencia de t\u00e9rminos como \u201cautentificado\u201d o \u201cdoble liberaci\u00f3n de memoria\u201d en las descripciones de CVE y dem\u00e1s. Al combinar estos factores, los investigadores pueden calcular la probabilidad de aprovechamiento de una vulnerabilidad espec\u00edfica.<\/p>\n

\"Algunos<\/strong><\/p>\n

\u00a0<\/strong>Para verificar la precisi\u00f3n del modelo, los investigadores compararon sus predicciones frente a los datos provenientes de ataques reales. Estos fueron sus hallazgos:<\/p>\n