Retrospectiva sobre Log4j, parte 4: 5 lecciones que hemos aprendido de Log4j
En la parte 4 de la serie de artículos sobre Log4j, quiero analizar más profundamente las principales conclusiones. Aprenderemos mucho más a medida que avancemos en la lucha por erradicar esta vulnerabilidad. No obstante, ya podemos mencionar cinco conclusiones fundamentales.
1. La nueva norma
Tanto la complejidad del software como la velocidad a la que los usuarios finales exigen nuevas funciones siguen aumentando rápidamente y sin límites. Para satisfacer las necesidades de los usuarios finales en los plazos requeridos, los desarrolladores deben confiar en un conjunto de bibliotecas disponibles, ecosistemas de lenguajes e infraestructura y servicios de terceros que no dejan de proliferar. Como resultado, una gran parte de las funcionalidades de cualquier software está formada por componentes que los propios desarrolladores nunca han comprobado ni comprendido en su totalidad.
En cualquier gráfico de dependencias de software, las vulnerabilidades se heredan de los nodos hoja o del código y los servicios compartidos, y progresan hasta el nodo raíz o el producto que se programa. A medida que se agregan más nodos hoja a un proyecto, como resulta necesario según el enunciado anterior, también aumentan los riesgos de vulnerabilidades.
Este proceso conduce a una conclusión inevitable: Estos tipos de vulnerabilidades no solo han llegado para quedarse, sino que cada vez son más frecuentes y su impacto tiene más incidencia.
Esta es la nueva norma.
2. El riesgo es recurrente
Con frecuencia pensamos equivocadamente en el riesgo de los sistemas, el software y las funciones que podemos controlar directamente. Las organizaciones más avanzadas están empezando a evaluar los riesgos de un nivel adicional; por ejemplo, pidiendo a sus desarrolladores que examinen la fiabilidad de una biblioteca concreta.
Sin embargo, a medida que cada vez más sistemas y aplicaciones de software están compuestos por capas de código externo, las organizaciones tendrán que evaluar cada vez más no solo el riesgo de una biblioteca o un socio determinado, sino también las prácticas de esa comunidad de desarrollo o proveedor concreto para garantizar que también examinan sus dependencias.
Debe someter a evaluación todos los nodos del árbol de dependencias y de la cadena de suministro, sus socios o la comunidad de desarrollo correspondiente para determinar si se cumplen los niveles de riesgo tolerables.
3. Visibilidad y velocidad
Incluso después de evaluar todos los riesgos mencionados, se detectarán vulnerabilidades. Tenemos que aceptar este hecho. La cuestión es cómo podemos abordar la situación de forma más eficaz una vez que se produce; no cómo podemos evitarla por completo.
Para ello, la visibilidad es un factor primordial. Muchas organizaciones se enfrentan a dificultades al aplicar parches porque no saben qué equipos se verán afectados en primer lugar. Las empresas deben disponer de sistemas que proporcionen visibilidad de los sistemas que se ejecutan en el centro de datos y en la nube.
Cuanto más completa y precisa sea esa visibilidad, más rápido podrá reaccionar una organización, y podrá aplicar los parches a los activos necesarios.
4. Descartar lo obvio
Muchas vulnerabilidades solo pueden hostigarse a través de una cadena de ataques. Con frecuencia, un ataque suele poder evitarse solo con eliminar una pieza de esa cadena. Como consecuencia, los sistemas que filtran ataques tanto previos como obvios son fundamentales.
Las organizaciones deben dar prioridad a los siguientes sistemas:
- Plataformas de protección de terminales (EPP)
Protegen los terminales de software malicioso conocido
Firewall de aplicaciones web (WAF)
Protegen las aplicaciones web de cargas maliciosas conocidas y de agentes de amenazas; considere la protección que ofrece la solución Kona de Akamai, la mejor de su clase
Firewall DNS
Protegen los terminales de la visita a dominios maliciosos y filtran las cargas DNS maliciosas. Considere la solución Enterprise Threat Protector de Akamai
Puerta de enlace web segura (SWG)
Protege los terminales de la descarga de malware y de la visita a sitios maliciosos en Internet. Considere la solución Enterprise Threat Protector de Akamai
Autenticación multifactorial (MFA)
Reduce el riesgo del robo de credenciales que permiten acceder a su empresa donde se puede introducir una cadena de ataque. Considere la solución MFA de Akamai
Segmentación basada en identidades
Restringe las comunicaciones del software y los sistemas únicamente con los equipos necesarios para completar sus tareas; considere la solución Guardicore Segmentation de Akamai
Acceso de red Zero Trust (ZTNA)
Limita el impacto de los usuarios finales infectados que acceden a la red; considere la solución Enterprise Application Access de Akamai
5. El poder absoluto del mínimo privilegio
Por último, las organizaciones deben adoptar plenamente el principio del mínimo privilegio. Los servidores, equipos y software deben bloquearse para que solo puedan acceder a los sistemas necesarios para realizar sus funciones.
Por ejemplo, muchos de los sistemas que realizan llamadas LDAP salientes como parte del servicio Log4j nunca han tenido que utilizar LDAP. Este tipo de sistemas se deberían haber enrutado a través de un firewall a LDAP. Veamos otro ejemplo: Si un servicio solo responde a las solicitudes entrantes, bloquee las conexiones salientes.
Al aplicar los principios del mínimo privilegio a todos los sistemas y software bajo su control, es posible reducir en gran medida la superficie de amenazas cuando se detecta una vulnerabilidad y, en muchos casos, detener la cadena de ataques antes de que sus sistemas se vean afectados.
Más información
Gracias por acompañarme hasta el final en esta serie de artículos. Aunque esta serie termina aquí, nuestra labor de investigación y protección a nuestros clientes de las vulnerabilidades continúa. No dude en ponerse en contacto con su responsable de Akamai si desea obtener más información Nuestras recomendaciones sobre mitigación de Log4j y otras amenazas.
