Con tantos equipos de seguridad y desarrolladores haciendo autopsias sobre el fiasco de la vulnerabilidad de seguridad de Log4j que se desarrolló a fines de 2021, solo 10 días antes de Navidad, la pregunta principal es:¿cómo evitamos este tipo de dolor en el futuro? La respuesta, lamentablemente, es... es complicado.
Cobertura de seguridad de lectura obligada
Según nuevos datos de (ISC)2, la asociación sin fines de lucro más grande del mundo de profesionales certificados en seguridad cibernética, casi la mitad (48 %) de los equipos de seguridad cibernética dedicaron vacaciones y fines de semana para ayudar con la remediación, y el 52 % de los equipos pasaron “semanas o más ” remediando Log4j. No es exactamente cómo querían pasar las vacaciones los desarrolladores que ya estaban al límite.
Sin embargo, por el lado positivo, el dolor de esa experiencia ha provocado un importante replanteamiento de la seguridad de la cadena de suministro de software por parte de los desarrolladores y los equipos de seguridad.
Corrección de vulnerabilidades sin romper el código heredado
Uno de los aspectos más problemáticos de Log4j no fue la vulnerabilidad en sí, sino cuán profundamente integrada está la tecnología en el código heredado. 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 toca no solo una tonelada de sistemas de producción, sino también una gran cantidad de sistemas heredados. código.
“Nadie quiere tocar el código heredado”, dijo Sergei Egorov, CEO de AtomicJar, la nueva empresa detrás del marco de prueba de integración de código abierto, Testcontainers. “No solo necesita reparar una vulnerabilidad de seguridad, debe saber que solucionó la vulnerabilidad sin romper su sistema. Cuando tiene una vulnerabilidad con una biblioteca de registro súper popular como Log4j, está hablando de dependencias en código heredado que generalmente carece de pruebas, y donde a veces los desarrolladores que escribieron el código y entienden cómo funciona ni siquiera trabajan en la empresa. nunca más.”
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, con los sistemas Java, la vinculación del código ocurre en tiempo de ejecución, por lo que no hay manera de tener un 100 % de confianza en que la aplicación se comportará correctamente hasta que realmente la ejecute y pruebe la vinculación en tiempo real entre dependencias y compilaciones.
Egorov dijo que Log4j ha acelerado el interés en la ya popular plataforma Testcontainers, como una forma de probar estas interacciones antes de la implementación de producción. Él ve a los desarrolladores que fueron picados por Log4j ahora creando pruebas de integración entre sistemas y dependencias externas, de modo que la próxima vez que llegue una vulnerabilidad de seguridad, los desarrolladores puedan probar que sus correcciones no derribarán los sistemas de producción cuando se implementen. Testcontainers se está convirtiendo en un emparejamiento popular con Snyk, porque los desarrolladores pueden obtener solicitudes de extracción para solicitudes de seguridad automatizadas, y las pruebas de integración les dan la confianza de que pueden fusionarlos sin romper nada.
¿Qué es peor... la vulnerabilidad o interrumpir a los usuarios?
La llegada de la vulnerabilidad de seguridad Log4j y su terrible momento durante la temporada alta de vacaciones crearon una opción perversa para los equipos de desarrolladores:implementar correcciones ahora y arriesgarse a desactivar los sistemas durante los ciclos pico de comercio electrónico de vacaciones, o llevar la implementación de correcciones a intervalos comercialmente menos riesgosos. ?
Es una decisión que es imposible de tomar si no tienes 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 reparación afectaría a sus usuarios”, dijo Marcin Kurc, director ejecutivo de la startup de confiabilidad de software Nobl9, cuyos clientes incluyen grandes minoristas electrónicos. “Hay un análisis de costo-beneficio que debe realizarse en cualquier remediación de seguridad. Debe determinar el intervalo correcto 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 puede aceptar".
La empresa de Kurc está defendiendo un movimiento llamado objetivos de nivel de servicio (SLO) que nació en las prácticas de ingeniería de confiabilidad del sitio 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; digamos, por ejemplo, qué porcentaje de pagos del carrito de compras se ejecutan correctamente. Las empresas que están modelando SLO, dice Kurc, pueden tener una conversación real sobre el riesgo de parchear versus no parchear.
Tales soluciones, sin embargo, vienen después del hecho o, más bien, después de que se haya escrito el software de fuente abierta. Pero, ¿qué hacemos para que sea inherentemente más seguro?
Un problema más amplio:¿quién posee la seguridad para el código abierto?
Nadie va a dejar de usar código abierto. Sería absurdo crear una solución de registro desde cero, en lugar de buscar herramientas como Log4j. Actualmente, los desarrolladores escriben menos lógica e integran más marcos, bibliotecas y API, y eso no va a cambiar.
Como escribió Filippo Valsorda de Google en una publicación viral, muchos de estos mantenedores de código abierto “caen en una de dos categorías:voluntarios o empleados de grandes empresas. A veces ambos. Ninguno de los modelos es saludable”.
Log4j iluminó el hecho de que gran parte de la cadena de suministro de software moderna se basa en proyectos de código abierto con un puñado de mantenedores, o incluso un solo mantenedor, que a menudo creó la tecnología como un proyecto paralelo. (Y seamos claros:los datos recientes sugieren que la gran mayoría de todo el software de código abierto está escrito por menos de 10 personas).
“Las aplicaciones modernas se crean 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 en (ISC)2. "Una gran parte de calificar e identificar problemas es saber qué componentes y bibliotecas usa su software y mantener una lista de materiales de software (SBOM)".
Pero según un profesional de seguridad anónimo en la encuesta de remediación de Log4 de (ISC)2, “los desarrolladores en general han sido muy poco estrictos con el seguimiento de lo que usan en su software. Cuando un evento como este requiere que identifiquemos si nuestro código utiliza alguna biblioteca o componente, esa falta de trazabilidad se convierte en un punto crítico importante. Convierte un simple ejercicio de verificación de inventarios y SBOM en un proceso de escaneo complejo, con muchas oportunidades para falsos positivos y falsos negativos. Si alguna vez necesitábamos una llamada de atención, con Log4j la obtuvimos”.
Google y otros pesos pesados están poniendo su fuerza en este desafío de vulnerabilidad de seguridad de código abierto, y el tiempo dirá si una inversión más profunda y la colaboración de proveedores pueden ayudar a reducir la frecuencia y el dolor de incidentes como Log4j. Pero mientras tanto, los desarrolladores están ideando estrategias para evitar terribles sorpresas de seguridad la próxima temporada navideña.
Divulgación:trabajo para MongoDB, pero estas vistas son solo mías.
Enlace de origen