Depurando fallos: por qué es el momento de gestionar mejor los parches

La monotonía del mundo de la divulgación de vulnerabilidades tuvo este año un comienzo espectacular después de que Google y Microsoft se enfrentaran desde principios de enero. El escenario parecía dispuesto a que se produjera un enfrentamiento mayor: el gigante de la web con su equipo de jóvenes e impacientes investigadores de seguridad de Proyecto Zero versus el “viejo gigante de las TI”. Fue una pena cuando todo se disipó después de que Google hiciera algunas concesiones.

Sin embargo, las preguntas que pusieron de relieve la divulgación de vulnerabilidades todavía están en el aire. Y más importante aún, ¿qué pasa con los pobres administradores de sistemas que tan a menudo quedan atrapados en el medio? ¿Cómo pueden mantener la cabeza cuando todos a su alrededor están perdiendo la suya?

¿Revelar o no revelar?

Puede haber división de opiniones sobre si lo que finalmente Google hizo fue correcto o no. Por un lado se encontrarán aquellos que se hayan alegrado de que la compañía entendiera y moderara su inflexible política de divulgación de 90 días. Revelar públicamente el fallo de Windows 8 sólo dos días antes de que fuera a arreglarse en una actualización programada hizo un flaco favor. Añadir un período de gracia de dos semanas extra para que los fabricantes puedan demostrar que ellos tienen un parche en camino era lo sensato y justo.

En el mercado hay fabricantes de seguridad con políticas de divulgación de 90 días pero, como ha ocurrido con varios fallos de Android se han notificado a Google de forma privada; si el fabricante necesita más tiempo, se opta por trabajar con él para hacerlo público solo cuando estén listos. Se trata de ser flexibles y colaboradores, después de todo, con un enemigo común tan determinado y ágil como el nuestro, es la única alternativa para mantener a nuestros clientes a salvo.

Pero, por otra parte, están aquellos que consideran que es necesario publicar las vulnerabilidades más peligrosas tan pronto como sea posible. Si Google encontró un gran fallo en el software de un fabricante y sólo le informó a él, lo más probable es que no fuera el único en conocerlo. Desde bandas cibernéticas con motivación económica a espías del gobierno financiados por contribuyentes, hay un montón de terceros técnicamente preparados y con buenos recursos que son capaces de explotar dichos fallos para aprovecharlos antes de que esté disponible el parche.

¿Quién pierde en este caso? Los consumidores y las organizaciones que utilizan el software afectado.

Si los administradores de sistemas conocen la existencia del fallo tan pronto como sea posible pueden tomar las mejores medidas para gestión de riesgos. Cuanto más tiempo permanezca abierta la ventana de divulgación, más posibilidades existen de que los hackers puedan explotarla.

La diversidad es positiva

Pero, ¿debemos sentir lástima por los fabricantes que parece que se ahogan bajo el peso de la divulgación de vulnerabilidades? Microsoft lanzó sólo 28 boletines críticos el año pasado, bastantes menos si se compara con los 42 de 2013, pero últimamente está concentrando más CVEs por boletín. No, no es algo que deba tomarse a la ligera con la industria multimillonaria del software. Necesitan aprender el valor de la garantía de calidad y si la divulgación pública de fallos les ayuda a centrarse en esta tarea, que así sea. De hecho, Microsoft es uno de los mejores ejecutores cuando se trata de codificación – comete una media de 20 errores por 1.000 líneas de código, en comparación con el promedio de 15-50.

Una foto más amplia debería ayudar a comprender a los directores de TI que los sistemas operativos rígidos siempre llaman más la atención. Es simple economía. Un investigador de malware en busca de vulnerabilidades a explotar se centrará en las plataformas más populares, aquellas que permitan generar el máximo ROI. Invierta en sistemas Linux y los riesgos de exposición serán mucho más pequeños. Incluso el terrible bug Shellshock tuvo menos impacto en los usuarios que lo que a primera vista se calculó debido a la multiplicidad de sistemas Linux. Se puede ir incluso un paso más allá y contar con un sistema personalizado.

Reducir el riesgo

Desafortunadamente el manejo y facilidad de uso siempre triunfan frente a la seguridad, por lo que sistemas como el de Microsoft permanecerán entre los favoritos para la mayoría. Pero si el CIO ha hecho esa elección, debe tener en cuenta una serie de consideraciones para reducir el riesgo. Monitorizar la integridad de los archivos, la protección de las vulnerabilidades y las listas blancas puede ayudar a proteger los sistemas del software defectuoso e incluso de parches rotos. Estos sistemas pueden requerir tiempo y esfuerzo de configuración inicial, pero devuelven más tiempo. Tiempo para ejecutar procesos de control de calidad para garantizar que los parches que se aplican no van a fragmentar los sistemas críticos, por ejemplo.

Lo cierto que es, puestos a elegir, nadie jamás a va dar prioridad a un código más seguro y depurado. Prefieren lo que tienen ahora, incluso si es defectuoso. Así que es hora de utilizar las herramientas y técnicas que se tienen al alcance para ser un poco más eficientes sobre cómo gestionar las vulnerabilidades. Si algo nos han enseñado los dos últimos meses es que, desde luego, éstas no van a desparecer tan pronto.