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

Comentario: Aquellos que buscan una sola causa 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.

Imagen: su / Shutterstock

Disculpe si no quiero escuchar su «opinión caliente» sobre la vulnerabilidad Log4j. Por supuesto, dame los detalles de lo que sucedió, así como también cómo está afectando a empresas como la mía. Mejor aún, dame una idea de cómo puedo probar mis servidores para ver si estoy a salvo.

Simplemente no grite titulares como «El código abierto puede ser [an] puerta abierta a los piratas informáticos «, como hizo el Financial Times. Y no utilice 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 hecho, que «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 el próximo».

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

Hacer de la seguridad un proceso

¡Sé que sé! Eso no es una lectura emocionante. No hay pistola humeante. No hay becario a quien culpar. Es solo … software. Y el software se rompe, tiene errores, etc.

Como Klein destacó,

He evitado una toma caliente de la situación de log4j porque, francamente, estoy cansado de las tomas tecnológicas calientes. Sin embargo, mi opinión que no es buena es que ocurren errores, algunos de ellos muy graves, 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 una mejora real. Todos somos humanos y hacemos malabarismos con una montaña de limitaciones; es un milagro que la tecnología funcione tan bien al 1% «.

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 inmaterial, como Andrew Clay Shafer de Red Hat argumentó: «[P]aying [open source] los mantenedores salarios de software totalmente competitivos tendrían un impacto insignificante en la prevención de problemas de seguridad como el 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ántas hazañas no descubiertas están en proceso en su banco en este momento? »

Él tiene un punto. Una buena.

Incluso el software más financiado tiene errores, agujeros de seguridad, etc. Podemos hacerlo mejor, pero ningún software, de código abierto o propietario, es inmune a los fallos. Claro, podría hacer que los mantenedores se sientan mejor si se les paga mientras se les grita «¡ARREGLO ESTO AHORA!» pero hay algunoscomo Beka Valentine) quien argumentaría que reducir toda la sostenibilidad del código abierto a una cuestión de dinero, sin saberlo, le quita parte de su mayor fortaleza: la pasión por los desarrolladores.

VER: Marco de ciberseguridad del NIST: una hoja de trucos para profesionales (PDF gratuito) (TechRepublic)

De hecho, en 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 este análisis de costo-beneficio demasiado racional, que está empobreciendo nuestras vidas de muchas otras maneras». En otras palabras, quiere que la gente contribuya si eso les da alegría, y no quiere sentirse obligado a hacer algo con el proyecto que no le traiga a él también felicidad. La introducción del 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 con el código de licencia bajo una licencia de código abierto. Tuiteé en diciembre de 2020: «No es que el código abierto sea intrínsecamente más seguro, sino que es un proceso intrínsecamente mejor para proteger el código».

Por supuesto, asegurémonos de que los contribuyentes de código abierto sean pagados (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 circundantes sean permeables, accesibles, mejora la seguridad (o puede), en lugar de degradarla.

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

Ver también