Cómo evitar futuros desastres de seguridad como la vulnerabilidad de Log4j

Con tantos equipos de seguridad y desarrollo realizando evaluaciones posteriores a la vulnerabilidad de seguridad de Log4j que se desarrolló a finales de 2021, justo 10 días antes de Navidad, la pregunta principal es: ¿cómo evitamos este tipo de problemas en el futuro? La respuesta, desafortunadamente, es... es complicado.

Según los nuevos datos de (ISC)2, la asociación sin fines de lucro más grande del mundo de profesionales certificados en ciberseguridad, casi la mitad (48%) de los equipos de ciberseguridad renunciaron a su tiempo libre durante las vacaciones y los fines de semana para ayudar con la remediación, y el 52% de los equipos pasaron "semanas o más" reparando Log4j. No es precisamente cómo los desarrolladores que ya tienen ocupaciones querían pasar las vacaciones.

Por otro lado, el dolor de esa experiencia ha desencadenado una importante reconsideración de la seguridad de las cadenas de suministro de software por parte de los desarrolladores y los equipos de seguridad.

Corrigiendo vulnerabilidades sin romper el código legacy

Una de las aspectos más problemáticos de Log4j no fue la vulnerabilidad en sí, sino lo profundamente integrada que está la tecnología en el código legacy. Después de todo, Java es una de las plataformas más populares del mundo y Log4j es un sistema de registro de Java increíblemente popular cuyo lanzamiento inicial se remonta a 2001. Por lo tanto, Log4j afecta no solo a una gran cantidad de sistemas en producción, sino también a mucho código heredado.

"Nadie quiere tocar el código legacy", dijo Sergei Egorov, CEO de AtomicJar, la nueva startup detrás del marco de pruebas de integración de código abierto, Testcontainers. "No solo necesitas solucionar una vulnerabilidad de seguridad, también necesitas saber que solucionaste la vulnerabilidad sin romper tu sistema. Cuando tienes una vulnerabilidad en una biblioteca de registro tan popular como Log4j, estás hablando de dependencias en código heredado que generalmente carece de pruebas, y donde a veces los desarrolladores que escribieron el código y entendían cómo funciona ni siquiera trabajan más en la empresa".

Según Egorov, Log4j a menudo es una dependencia transitiva de otras bibliotecas que deben actualizarse. A diferencia de las plataformas que proporcionan binarios estáticos, en los sistemas de Java, la vinculación del código se realiza en tiempo de ejecución, por lo que no hay forma de tener un 100% de confianza en que la aplicación se comportará correctamente hasta que realmente la ejecutes y pruebes la vinculación en tiempo real entre dependencias y compilaciones.

Protección antivirus en línea: McAfee Clinic lleva la seguridad de tu PC al siguiente nivel

Egorov dijo que Log4j ha aumentado el interés en la plataforma Testcontainers, que ya era popular, como una forma de probar estas interacciones antes de la implementación en producción. Ve a los desarrolladores que fueron afectados por Log4j creando pruebas de integración entre sistemas y dependencias externas, para que la próxima vez que llegue una vulnerabilidad de seguridad, los desarrolladores puedan probar que sus correcciones no afectarán los sistemas en producción cuando se implementen. Testcontainers se está volviendo popular en combinación con Snyk, porque los desarrolladores pueden obtener solicitudes de extracción para revisiones automáticas de seguridad, y las pruebas de integración les dan la confianza de que pueden fusionarlas sin romper nada.

¿Qué es peor... la vulnerabilidad o interrumpir a los usuarios?

La aparición de la vulnerabilidad de seguridad de Log4j y su terrible momento durante la temporada alta de vacaciones crearon una elección perversa para los equipos de desarrollo: implementar correcciones ahora y correr el riesgo de interrumpir los sistemas durante los ciclos de comercio electrónico más fuertes de las vacaciones, o posponer la implementación de correcciones a intervalos con menos riesgo comercial.

Es una decisión imposible de tomar si no se tiene el contexto adecuado.

"Log4j hizo que muchos equipos de ingeniería entraran en pánico porque no tenían forma de predecir cómo la solución afectaría a sus usuarios", dijo Marcin Kurc, CEO de la startup de confiabilidad de software Nobl9, cuyos clientes incluyen grandes minoristas en línea. "Se debe realizar un análisis de costo-beneficio en cualquier remediación de seguridad. Debes determinar el intervalo adecuado para implementar la solución, lo que requiere una comprensión completa del riesgo en términos de cuántos usuarios podría afectar y el nivel aceptable de falta de confiabilidad que puedes aceptar".

La empresa de Kurc promueve un movimiento llamado objetivos de nivel de servicio (SLO, por sus siglas en inglés) que nació de las prácticas de ingeniería de confiabilidad de los sitios de Google y que Nobl9 ha comercializado en una plataforma.

Los SLO permiten a los desarrolladores modelar el tiempo de actividad y las tasas de éxito en las interacciones de software y definir umbrales para los resultados de los usuarios, por ejemplo, qué porcentaje de los pagos de carritos de compra se realizan correctamente. Las empresas que están modelando SLO, según Kurc, pueden tener una conversación real sobre el riesgo de implementar o no implementar un parche.

Cómo proteger tu computadora de los virus: métodos y consejos

Tales soluciones, sin embargo, llegan después del hecho o, más precisamente, después de que se haya escrito el software de código abierto. ¿Pero qué hacemos para hacerlo inherentemente más seguro?

Un problema más amplio: ¿quién es responsable de la seguridad del código abierto?

Nadie va a dejar de usar el código abierto. Sería absurdo construir una solución de registro desde cero en lugar de utilizar herramientas como Log4j. Los desarrolladores están escribiendo menos lógica e integrando más frameworks, bibliotecas y APIs en estos días, y eso no va a cambiar.

Como escribió Filippo Valsorda de Google en un post viral, muchos de estos mantenedores de código abierto "se dividen en dos categorías: voluntarios o empleados de grandes empresas. A veces ambas cosas. Ninguno de los modelos es saludable".

Log4j mostró que gran parte del moderno suministro de software se basa en proyectos de código abierto con unos pocos mantenedores, o incluso un único mantenedor, que a menudo creó la tecnología como un proyecto paralelo. (Y seamos claros: datos recientes sugieren que la gran mayoría de todo el software de código abierto es escrito por menos de 10 personas).

"Las aplicaciones modernas se construyen a partir de muchos componentes, muchos de los cuales no se desarrollan internamente, sino que se ensamblan utilizando soluciones 'listas para usar'", según John France, CISO de (ISC)2. "Gran parte de la calificación e identificación de problemas consiste en saber qué componentes y bibliotecas utiliza su software y mantener un inventario de software".

Pero según un profesional de seguridad anónimo en la encuesta de remediación de Log4j de (ISC)2, "los desarrolladores en general han sido muy descuidados al rastrear lo que usan en su software. Cuando un evento como este requiere que identifiquemos si alguna biblioteca o componente se usa en nuestro código, la falta de rastreabilidad se convierte en un gran dolor de cabeza. Transforma un ejercicio simple de verificar inventarios y SBOM en un proceso de escaneo complejo, con muchas oportunidades de falsos positivos y falsos negativos. Si alguna vez necesitamos una llamada de atención, la recibimos con Log4j".

¡Defiéndete! Protege tu seguridad en línea contra amenazas críticas

Google y otros gigantes de la industria están destinando esfuerzos para abordar este desafío de la vulnerabilidad de seguridad del código abierto, y el tiempo dirá si una mayor inversión y colaboración entre proveedores pueden ayudar a reducir la frecuencia y el impacto de incidentes como Log4j. Pero mientras tanto, los desarrolladores están ideando estrategias para evitar terribles sorpresas de seguridad la próxima temporada de vacaciones.

Divulgación: Trabajo para MongoDB, pero estas opiniones son solo mías.

En Newsmatic nos especializamos en tecnología de vanguardia, contamos con los artículos mas novedosos sobre Seguridad, allí encontraras muchos artículos similares a Cómo evitar futuros desastres de seguridad como la vulnerabilidad de Log4j , tenemos lo ultimo en tecnología 2023.