Seguridad

Vulnerabilidad de Log4j: por qué su versión caliente es incorrecta

Comentario: aquellos que buscan una causa única para la vulnerabilidad de Log4j, ya sea que el código abierto no sea seguro o que el código abierto no sea sostenible, se equivocan. Es un tema complicado.

security concept 1
Imagen: tu/Shutterstock

Discúlpeme si no quiero escuchar su «toma caliente» sobre la vulnerabilidad de Log4j. Por todos los medios, dame los detalles de lo que pasó, así como también cómo está afectando a empresas como la mía. Aún mejor, dame una idea de cómo puedo probar mis servidores para ver si estoy a salvo.

Simplemente no publiques titulares como «El código abierto puede ser [an] puertas abiertas para los piratas informáticos”, como hizo el Financial Times. Y no uses el problema para empezar golpeando el tambor de las crisis de la “sostenibilidad del código abierto”. El código abierto no es un problema de seguridad, y la sostenibilidad del código abierto es un tema complicado. En cambio, es hora de reconocer, como Matt Klein, fundador y mantenedor del proyecto de código abierto Envoy, ha hechoque “Todo lo que podemos hacer es aceptar la realidad de los errores/interrupciones, hacer lo mejor que podamos para mitigar, aprender y mejorar, y esperar al siguiente”.

VER: Política de gestión de parches (Premium de Tecnopedia)

Hacer de la seguridad un proceso

¡Sé que sé! Eso no hace que la lectura sea emocionante. No hay arma humeante. Ningún interno a quien culpar. Es solo… software. Y el software se rompe, tiene errores, etc.

Como Klein destacó,

He evitado una toma caliente en la situación de log4j porque, francamente, estoy cansado de las tomas calientes tecnológicas. Sin embargo, mi opinión negativa es que ocurren errores, algunos de ellos muy malos, y ocurren por una serie de razones complejas. Quejándose del villano del día ([open source] financiación, seguridad de la memoria, etc.) es una pista falsa, y centrarse demasiado en una causa no conduce a ninguna mejora real. Todos somos humanos y hacemos malabarismos con una montaña de limitaciones; es un milagro que la tecnología funcione un 1 % tan bien como lo hace”.

Pero… ¿qué pasa con el hecho de que, aparentemente, a los mantenedores de Log4j no se les paga por hacer ese trabajo? Eso puede ser cierto o no, pero también es algo irrelevante, como dijo Andrew Clay Shafer de Red Hat. argumentó: “[P]diciendo [open source] Los salarios de software totalmente competitivos de los mantenedores tendrían un impacto insignificante en la prevención de problemas de seguridad similares a log4j”. A primera vista, esto suena mal, pero considere su seguimiento: “[H]¿Cuánto dinero han gastado los bancos en ‘seguridad’ desde 2013? [W]mientras ejecuta log4j en prod todo el tiempo? [H]¿Cuántos exploits no descubiertos están en juego en su banco en este momento?

LEER  BeyondTrust lanza una plataforma de evaluación de vulnerabilidades basada en la nube

Él tiene un punto. Una buena.

Incluso el software más financiado tiene errores, agujeros de seguridad, etc. Absolutamente podemos hacerlo mejor, pero ningún software, ya sea de código abierto o propietario, es inmune a las fallas. Claro, podría hacer que los mantenedores se sientan mejor si se les paga mientras se les grita «¡ARREGLE ESTO AHORA!» pero hay algunos (como beka valentin) quien argumentaría que reducir toda la sustentabilidad del código abierto a una cuestión de dinero, sin darse cuenta, le quita parte de su mayor fortaleza: la pasión del desarrollador.

VER: Log4j: Cómo protegerse de esta vulnerabilidad de seguridad (República Tecnológica)

De hecho, sobre este punto, el fundador de Ruby on Rails, David Heinemeier Hansson, declaró que “no dejaré que me paguen por mi código abierto”. ¿Por qué? “El código abierto, visto a través de la lente altruista de la licencia de obsequio del MIT, tiene el poder de liberarnos de estos toros de análisis de costo-beneficio excesivamente racionales, que están empobreciendo nuestras vidas de muchas otras maneras”. En otras palabras, quiere que la gente contribuya si les da alegría, y no quiere sentirse obligado a hacer nada con el proyecto que no le traiga también felicidad. La introducción de dinero hace que el código abierto sea común, en su opinión.

Independientemente de si está de acuerdo, y volviendo al punto de Shafer, no eliminaremos mágicamente a Log4j ni a ningún software de código abierto (o propietario) de errores simplemente arrojándoles dinero. Esa no es la magia del código abierto. No, la seguridad es un proceso de código abierto, no algo que se obtiene al otorgar licencias de código bajo una licencia de código abierto. Tuiteé en diciembre de 2023: «No es que el código abierto sea inherentemente más seguro, sino que es un proceso inherentemente mejor para asegurar el código».

Por todos los medios, asegurémonos de que se pague a los contribuyentes de código abierto (o no, siguiendo el razonamiento de DHH y Valentine), pero no celebremos nuestras tontas tomas calientes que intentan reducir el problema de Log4j a una sola cosa. La seguridad es complicada. El software es complicado. Pero el código abierto, al hacer que el software y los procesos que lo rodean sean permeables, accesibles, mejora la seguridad (o puede), en lugar de degradarla.

Divulgación: trabajo para MongoDB, pero las opiniones expresadas aquí son mías.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Botón volver arriba