Log4j: Dos trucos para que tu próxima vulnerabilidad sea menos caótica

InvGate diciembre 15, 2021
- 4 minutos de lectura

En pocas palabras: Log4j es un desastre, si estabas buscando aplicaciones, servicios y servidores que utilicen Java, considera las sugerencias de abajo para hacer que la instalación del parche del día cero sea más fácil.

Se descubrió una vulnerabilidad grave (CVE-2021-44228) en múltiples versiones de la utilidad Apache Log4j 2 a través del GitHub del proyecto el 9 de diciembre de 2021. La vulnerabilidad impacta desde las versiones 2.0 a la 2.14.1 de Apache Log4j 2.

Los administradores de configuración alrededor del mundo tuvieron mucho trabajo la semana pasada cuando se anunció uno de los ataques de día cero más extendido. Si tu equipo contaba con una práctica madura de gestión de la configuración, una buena CMDB y algún mapeo básico de dependencias, ¡quizás ya tengas el parche! 

Si ese no es el caso, probablemente estés apagando el incendio por semanas y busques desarrollar herramientas que simplifiquen el camino de aquí en adelante.

¿Cómo llegamos aquí?

Decir que el desarrollo de aplicaciones es complicado sería quedarse corto. La mera creación de una página de inicio de sesión da lugar a cientos de preguntas fundacionales. ¿Deberíamos usar una herramienta de terceros? ¿De código abierto? ¿Crearla nosotros mismos? ¿Qué lenguaje e infraestructura utilizaríamos?

La respuesta a estas preguntas determinarán las herramientas, arquitectura y decisiones que tú y tu equipo tomarán a medida que la aplicación madura y crece. A veces, optarás por desarrollar ciertas funcionalidades y componentes, mientras que en otras ocasiones elegirás comprarlas.

Una de las decisiones más importantes que los desarrolladores tomarán es la gestión del registro de eventos. Los logs de las aplicaciones le permiten a los desarrolladores identificar bugs, revisar el desempeño y monitorear la actividad de la aplicación. Dado que el registro de eventos de las aplicaciones está prácticamente fuera de la vista de los clientes, tiene sentido que muchas personas utilicen herramientas de terceros prefabricadas que son fáciles de implementar.

Por último, una plataforma de registro de eventos de código abierto es más propensa a acaparar este mercado, en especial si es gratuita. Si combinamos este factor con una plataforma de aplicaciones muy usada como Java, es probable que obtengamos una mayor probabilidad de adopción masiva.

¿Cómo salimos de aquí? 

Este ataque no es particularmente difícil de parchear. Una coincidencia simple de patrones corrige el problema. El problema real aparece cuando dependemos de los proveedores para que parcheen la vulnerabilidad y no pueden hacerlo o no disponen del tiempo necesario para hacerlo. De esta manera, será necesario identificar, parchear, retirar o evaluar aquellos servicios y aplicaciones que dependen de estos proveedores de software, quienes impulsan activamente Log4j, para determinar el próximo curso de acción.

¿Cómo simplificarlo la próxima vez?

Puede que sea obvio, pero la mejor manera de parchear un ataque de día cero es tener un panorama claro de tu ecosistema. Una base de datos de las aplicaciones, los servidores y los servicio que provee IT es solo el comienzo. Por más valiosa que sea esta base de datos, el valor real aparece cuando estos elementos están relacionados entre sí. Esto significa que ahora, por ejemplo, descubrir qué servidores tienen Java instalado ahora se convierte en información crítica. Una consulta rápida y podrás identificar todas las máquinas que están en riesgo.f

 

Diagrama 1: Las bases de datos de la gestión de la configuración (CMDB) son unas de las mejores formas de empezar a monitorear información completa sobre elementos físicos y virtuales.

Si tus equipos y procesos pueden conectar los componentes que se combinan para entregar el servicio, entonces tendrás una lista prioritaria de no solo los servidores y aplicaciones que necesitan parches e inspección, sino también una forma de priorizar ese trabajo (los servicios más críticos primeros).

Diagrama 2: Un mapa de componentes de servicio como este de InvGate le permite a tu personal de IT identificar los problemas, priorizar el trabajo y comprender la complejidad de una forma más rápida y sencilla.

¿Qué aprendimos?

Los ataques de día cero no se irán a ninguna parte. A medida que las aplicaciones continúen haciéndose más complejas y tengan una mayor cantidad de dependencias, representar a los sistemas y servicios de manera precisa será una tarea cada vez más importante. El trabajo de construir los datos puede tomar un tiempo, pero es probable que tus equipos de gobernanza tengan algunos trucos bajo la manga.

Una vez que documentes y descubras los servicios críticos, asegúrate de proteger los datos a través de los procesos de cambio, entregas y gestión de proyectos. De esta manera, cuando anuncien el próximo ataque, tendrás tus datos seguros y podrás confiar en ellos.

¿Cómo se protegen los datos de la CMDB con la gestión de cambio?

Diagrama 3: Creamos este gráfico para mostrar cómo se protegen los datos de la CMDB a través de la gestión del cambio (la cual proviene de la gestión de entregas que a su vez proviene de la gestión de proyectos).

Existen herramientas para acelerar esto. Ya sea desde agentes que se comunican para reportar aplicaciones instaladas hasta herramientas de descubrimiento de red; existen numerosas herramientas que permitirán simplificar estos procesos. Si no cuentas con una herramienta que capture y documente esta información, ¡prueba InvGate Insight gratis hoy!

Prueba a InvGate cómo tu solución ITSM

Pruébalo 30 días sin costo - Sin tarjeta de crédito

Comienza ahora