Si ponemos como premisa el generar un flujo eficiente y normalizado de corrección de errores y parcheo, lo primero que debemos tener en cuenta es que no es lo mismo parchear sistemas que servicios o aplicaciones. Y las implicaciones pueden ser muy distintas (y de muy diversa gravedad). La separación de los mismos a nivel técnico se debe a las características intrínsecas de cada uno de ellos y los ciclos de aplicación de parches de estos elementos han de tener tratamientos diferentes. La intención es automatizar el flujo para no depender de la aprobación de actores externos, agilizando el proceso, así que deberemos analizar qué medidas correctoras debemos aplicar en nuestra arquitectura y las implicaciones que pudiera tener su respectiva aplicación para definir un método de actuación. Tras esto, habrá que confeccionar un inventario robusto que no debe descuidarse y ha de mantenerse siempre actualizado.
Diseñar un ciclo de corrección y su automatización
Una vez identificadas las necesidades de nuestros sistemas, podemos empezar a diseñar un ciclo de trabajo que se adecúe a estas. Dentro de estos ciclos podemos emplear numerosas herramientas que nos ayuden a automatizar el proceso, agilizando el flujo. Pero no debemos olvidar que ni el más sofisticado de los métodos eliminará por completo las fases más “manuales” del flujo.
Para generar un correcto flujo de implantación de parches de seguridad, podemos identificar varias fases consistentes en la detección de sistemas, servicios y aplicaciones, y el versionado del software; la evaluación del riesgo y la determinación de la mejor manera de realizar dichas evaluaciones; y la corrección, entendida como la definición exacta del flujo de trabajo a la hora de aplicar los parches según la tipología y clasificación del riesgo.
Una clasificación del flujo de parcheo también consiste en una securización del pipeline, centrándonos en el hardening del proceso, seguido de una securización durante el pipeline, en el que se implementarán los requerimientos de seguridad que se deban cumplir durante el mismo. Un detalle que no debe olvidarse es que el proceso de automatización del parcheo ha de ser securizado también: desde el manejo del código de las configuraciones a desplegar, la automatización ante un incidente, securización de backups, monitorización de logs, etc.
Integrar un buen método de testing
En muchos casos, el testing parece relegado al desarrollo de un producto. Pero también ofrece una función importantísima a la hora del patching, lo que asegurará la integridad de la infraestructura. Al fin y al cabo, debemos llevar estas tareas de sistemas y servicios a código, y controlaremos que todo se esté realizando de manera correcta mediante testing. Esto nos permitirá generar calidad en lo que estamos haciendo y garantizar así, al menos en gran parte, que nuestras acciones están siendo securizadas sin depender exclusivamente del factor humano. Por ello, habrá que generar test lo suficientemente robustos, de calidad y con idempotencia suficiente que garantice unos mínimos.
Mantener el control mediante la monitorización
Para tener una visibilidad real de lo que está pasando durante los procesos que ocurren en el sistema o, incluso, cuando existe un ataque, es esencial contar con un buen sistema de monitorización. Por tanto, es imprescindible que nos apoyemos en herramientas de correlación de logs y alarmas. De esta forma, cubriremos por completo el contexto temporal de la monitorización.
Tener claros los roles
Como en cualquier tarea delicada, y todo lo relativo a la seguridad lo es, es esencial contar con responsables claramente identificables. Pero, además, es también crucial el reducir al máximo posible el factor humano, apostando por soluciones que validen de forma programática. Esto evita ineficiencias costosas y pérdidas graves en la programación de tareas. Apoyar el peso de la validación en el testing del que hablábamos anteriormente es algo plausible y eficaz. La idea es llevar todo lo viable a código, automatizarlo. Eso sí, hay que hacerlo siempre tras realizar un análisis en profundidad. Este proceso, como muchos otros, se ha de ir adaptando poco a poco.
En resumen, realizar un parcheado de los sistemas, los servicios y las aplicaciones de nuestra empresa es fundamental para protegerla ante posibles ciberataques. Sin embargo, esta tarea tan relevante no puede desarrollarse a la ligera; es necesario implementar un método de actuación acorde a las características de la arquitectura de nuestra empresa y evaluar las implicaciones de aplicar el parcheado.
5 comments
Genial artículo, al parecer hay referencias más detalladas en el mismo donde explica como hacerlo y parece perfectamente viable dado como han evolucionado las metodologías y tecnologías para ayudarnos. Respecto al coste podría o no ser viable, pero parece más un tema organizativo o de gestión.
https://medium.com/@rootsec/sistema-de-correcci%C3%B3n-de-vulnerabilidades-en-arquitecturas-complejas-implantaci%C3%B3n-e3b7cd2352ec
Felicidades por el artículo.
¡Muchas gracias por tu aportación, Luis!
Saludos,
Panda Security.
Exacto. Es así el testing
. Sinembargo el parcheo a muchos no es posible debido al factor y el costo tan enorme de trabajo q..ue supone.
Me parece despreciable y mentira el testing a un nivel que No Es Implementable
. Ya lo sabrán. Fami. Y todo e..so… yo no podré Ayudarles. No dejo el comentario porque no merezco tal premi@
Hola,
Como en todo, hay que ver pros y contras y evaluar los costes. Desplegar parches y hacer el testing correspondiente tiene un coste determinado. ¿Es mayor ese coste que poder perder la información, o quedar completamente bloqueados por un ataque? Si la respuesta es no, entonces está claro lo que hay que hacer.
Realmente útil el post, servidor toma nota… porque menuda vivimos en mi empresa con lo de wanacry…
Comparto lo que comenta Panda, hay que valorarlo y no parece tarea fácil, pero es una muy buena definición de como podriamos hacer que esto pase.
En cuanto al testing a esos niveles ya está sucediendo, me da que no estás en te has perdido el barco Timi :P.