log

Durante las últimas semanas, el mundo de la seguridad informática se ha puesto patas arriba a medida que los equipos luchaban por comprender si tenían que preocuparse por la vulnerabilidad de Log4j . La biblioteca de Java relativamente pequeña no hizo nada llamativo, pero era una herramienta de código abierto bien construida para rastrear eventos de software, y eso la hizo popular entre los desarrolladores de Java. Eso significaba que a menudo llegaba a rincones que la gente no esperaba.

Si bien los equipos de seguridad continuarán debatiendo la naturaleza de la falla en sí y buscando problemas similares, muchos se preguntan cómo esto podría cambiar la dependencia de la industria de las prácticas de código abierto. Todo el mundo disfruta de las herramientas gratuitas hasta que aparece un problema como este. ¿Existe un problema más profundo con el desarrollo de código abierto que provocó esto? ¿Puede la sociedad seguir confiando en la generosidad del código abierto sin cambiar sus expectativas y responsabilidades?

VentureBeat habló con Brian Behlendorf para comprender la profundidad del problema y también tratar de entender cómo los desarrolladores de software pueden evitar que otra falla como esta obtenga una distribución tan amplia. Behlendorf fue uno de los desarrolladores originales de los servidores web Apache y durante mucho tiempo ha sido un líder en el desarrollo de código abierto. Ha estado trabajando con Linux Foundation y Open Source Security Foundation ( OpenSSF ) para encontrar mejores prácticas y respaldarlas en todo el ecosistema de código abierto.

VentureBeat: ¿Podría suceder algo así con el código cerrado también?

Brian Behlendorf : Absolutamente. No existe el software libre de errores, ¿verdad? Solo [hay] errores que aún no se han descubierto.

Obviamente, algún software recibe mucho más escrutinio que otro software, pero no hay razón para creer que el software comercial propietario esté más analizado que el software de código abierto.

VentureBeat : Probablemente no haya suficiente escrutinio en ninguna parte, ¿verdad?

Behlendorf : No es una práctica habitual que se pida a los desarrolladores de software que vuelvan a leer y volver a examinar el código antiguo. Ya sea comercial o patentado. Es por la misma razón por la que no ves a muchos científicos repitiendo experimentos antiguos. No se les recompensa por volver a visitar trabajos antiguos.

Son recompensados ​​por agregar nuevas funciones, por hacer un nuevo trabajo. No se le recompensa por refactorizar el código antiguo. ¿Sabes, este fragmento de código que escribió Larry? Después de que se fue o renunció o lo que sea, nadie volvió a visitarlo porque parece funcionar. Parece pasar las pruebas. Y si es tan espinoso y sin comentarios, solo queremos tratarlo como una caja negra.

VentureBeat : Es la misma situación en equipos de código abierto o cerrado.

Behlendorf : Los incentivos, ya sea en código comercial o de fuente abierta, realmente no favorecen volver atrás y mirar estas cosas. A menudo, se necesitan desastres como este para convencer a la gente de que se esfuerce por [encontrar] estas cosas.

VentureBeat : Estaba trabajando en un proyecto e hicimos una función de filtrado más elegante ofreciendo, digamos, filtrado de expresiones regulares arbitrario. El gerente dijo que era "demasiado maravilloso" y que "volver a marcarlo". Bueno, dejamos el código arbitrario de expresiones regulares allí y simplemente pusimos un menú desplegable con algunas opciones que, a su vez, alimentaron una expresión regular al backend. Creo que probablemente sucedió algo similar aquí con el equipo de Log4j , ¿verdad?

Behlendorf : Por supuesto. Creo que tanto en el código de fuente abierto como en el propietario, hay una tendencia a decir "sí" cuando alguien aparece con un código que implementa una nueva característica. Existe una inclinación a aceptarlo para hacer crecer el grupo de desarrolladores en torno al proyecto. Erremos y dirijamos "sí" a las personas que parecen personas razonables.

VentureBeat: Pero eso abre la puerta a problemas, ¿verdad?

Behlendorf : Por supuesto. ¿Debería tener una utilidad de registro que analice la entrada aportada por el usuario para formatear, instrucciones para expandir cosas a otras cosas? La respuesta seria no." De hecho, esto es algo que se encuentra en nuestra guía de codificación segura y materiales de capacitación que colocamos en EDX como parte de la actividad de OpenSSF. Recomendamos específicamente no confiar en ninguna forma de entrada del usuario. Pero si su inclinación es decir “sí” hasta que se demuestre que está equivocado con las nuevas funciones, entonces terminará con sorpresas como esta.

VentureBeat: Pero si empiezas a rechazar cosas, el proyecto también muere, ¿correcto?

Behlendorf : Lo opuesto a esto es decir "no" a todo a menos que sea examinado a fondo. Eso también puede ser una receta para la obsolescencia. Un camino hacia donde no hay ningún invento o riesgo o nuevas características en absoluto. Hay dos extremos de un espectro y tenemos que navegar por un camino entre ellos.

VentureBeat : Mencionaste algunos de los cursos de OpenSSF. ¿Crees que podemos desarrollar los metaprocedimientos para intentar captar este tipo de cosas?

Behlendorf : Definitivamente. Existe un corpus de conocimiento sobre cómo escribir software a la defensiva. Y cómo ser reflexivo sobre lo que sucede debajo de las capas de abstracción con las que normalmente se enfrenta. Estas no suelen formar parte del sistema educativo en ciencias de la computación. Ciertamente, tampoco forma parte del tipo de formación más profesional. Necesitamos pensar más en escribir codificación a la defensiva y escribir para un entorno de confianza cero.

Tal vez debamos comenzar a esperar que las personas que se convierten en mantenedores hayan tomado un curso, como este, o que de alguna manera demuestren competencia en esto.

VentureBeat: ¿Crees que es posible hacer algún tipo de automatización con esto? Recuerdo que algunos chicos del grupo OpenBSD escribieron muchos pequeños scripts buscando los anti-patrones básicos a evitar.

Behlendorf : Por supuesto, hay herramientas de análisis estático y fuzzers. Las herramientas SAST están realmente diseñadas para intentar buscar algunos de estos errores comunes. Pero en el caso de Log4j, no me queda claro si las herramientas lo habrían detectado. Fue una especie de defecto de diseño intencionalmente olvidado. No conozco ninguno de ellos que destaque arquitecturas problemáticas porque eso requiere casi un grado de conciencia a nivel de IA de cuál era la intención del programa.

VentureBeat: ¿Quizás podría convertirse en una parte más importante de la infraestructura?

Behlendorf : Sí. Podría ser a largo plazo cuando, ya sabes, hayamos comenzado a [ver] AI aplicada a la codificación del sistema. Lo has visto en GITHUB. Lo llaman, pero están las técnicas de desarrollo de software asistidas por inteligencia artificial y el tipo de técnicas de desarrollo de software en las que se [piensa] en él como Autocompletar, pero para el desarrollo de software.

Suelen costar dinero y eso puede ser una barrera para que los equipos lo recojan.

El otro problema es que muchas de estas herramientas generan muchos falsos positivos, muchas cosas que parecen estar mal, pero en realidad no lo son. Es increíblemente laborioso analizar los falsos positivos para tratar de resolver lo que realmente es un problema. ¿Es este un problema legítimo o simplemente algo que parece incorrecto?

Entonces, una cosa que nos gustaría hacer en OpenSSF es [trabajar para] averiguar, "¿Cómo podemos ayudar con eso quizás reuniendo un portal común sobre dónde se ejecutan los informes de este tipo de herramientas?" Los desarrolladores de software que son fundamentales para estos proyectos, como Log4j, pueden comenzar a separar los falsos positivos. Y márquelos como, "No me moleste con estos de nuevo", ya sabe, e intente obtener algo de economía de escala. Ir en lugar de muchas personas diferentes que ejecutan estas herramientas y tener que separarse de forma independiente. Es difícil hacerlo completamente a través de la automatización.

En mayo, creo que la Casa Blanca pidió una lista de materiales de software. Básicamente, etiquetado en un paquete de software que le dice qué hay dentro. Cuando surge una nueva vulnerabilidad, le permite descubrir rápidamente qué hay dentro de mi software implementado. Para decir, "Oh, aquí es donde estoy usando log4j, a pesar de que estaba incrustado con tres capas de profundidad dentro de alguna otra caja negra".

VentureBeat : Me preocupa que esto haga que la gente desconfíe aún más de las bibliotecas.

Behlendorf : Hemos tendido a fomentar la atomización en los paquetes de software. Hoy en día, es común incorporar cientos o miles de dependencias. Hace un tiempo, hubo una biblioteca ( bloc de notas izquierdo ) que se retiró porque alguien tuvo una disputa con alguien sobre si se trataba de licencias o marcas. Esto provocó este efecto dominó descendente en el que los servicios de Internet estaban cayendo porque los equipos no podían enviar actualizaciones a la producción o cuando lo hacían, las cosas estaban fallando y de manera frágil.

Esto debería despertar a la gente porque debemos tomarnos en serio la seguridad y la resistencia en la forma en que construimos y empujamos a la producción. Realmente sería útil juntar estos pequeños pedacitos en una plataforma común. Luego, examínelo para que todo en ella se mantenga actualizado. Así que todo aquí está diseñado para funcionar entre sí. Me encantaría ver un mayor enfoque en volver a las bibliotecas agregadas.

VentureBeat : Has hablado de algunos proyectos nuevos que se avecinan para abordar estos problemas desde OpenSSF. ¿Puedes hablar de ellos?

Behlendorf : Todavía estamos uniendo las piezas. Durante el último año, el proyecto, que es parte de la Fundación Linux, que tiene miembros como Microsoft, Google y muchas empresas de servicios financieros, se ha centrado en el software como cadena de suministro, ¿verdad? Desde los desarrolladores originales hasta la construcción e incorporación de estas dependencias hasta el usuario final, existen todos estos lugares donde hay una especie de suposiciones sobre cómo funciona el mundo.

Lo que ya lanzamos han sido esfuerzos de capacitación para mejorar la seguridad en edX. Comenzaremos a usar parte de los fondos que hemos podido adquirir para realizar intervenciones específicas y algunas de las piezas de infraestructura más críticas que serán realmente útiles. ¿Hay formas de realizar análisis de seguridad de ellos que, ya sabes, análisis de análisis estático y que alguien venga y haga alguna corrección?

VentureBeat: ¿Hay alguna forma de apoyar los proyectos en sí?

Behlendorf : Creemos que realmente no se ha prestado mucha atención a los equipos de seguridad que lo ubican como Apache, o la Fundación Python o la Comunidad Node.js. Como, ¿cómo operan? ¿Cómo se dotan de recursos? ¿Qué estándares adoptan? Lo que planeamos hacer es trabajar con esos equipos de seguridad, desarrollar estándares comunes sobre cómo ejecutar un equipo de seguridad en un proyecto de código abierto. Quizás encuentre formas de canalizar fondos directamente a esos equipos, para que puedan ser más proactivos.

Una de las cosas que intentan hacer los proyectos de código abierto es una administración mínima viable. Todos intentan decir: "¿Cuál es la menor cantidad de burocracia con la que podemos salirse con la nuestra mientras protegemos nuestras pieles desde un punto de vista legal?"

Eso significa que los equipos de seguridad tienden a carecer de recursos suficientes. Y significa que tienden a evitar establecer requisitos para las cosas. Por ejemplo, si eres un mantenedor en un proyecto, ¿has recibido capacitación en seguridad, verdad? Tal vez eso sea parte del cambio que podemos ayudar a impulsar en una determinada dirección, es ayudar a las fundaciones a obtener los recursos para poder aprovisionar mejor a los equipos de seguridad. Tal vez incluso con expertos en seguridad pagados en esos equipos que pueden buscar proactivamente la próxima vulnerabilidad de Log4j en lo profundo de su código. Hemos reunido una gran cantidad de fondos para hacer algunas cosas interesantes en este dominio, y pronto comenzarán a ver algunos anuncios.

 

Fuente: Venturebeat | somoslibres

¿Quién está en línea?

Hay 9204 invitados y ningún miembro en línea