Los proveedores de software deben comprender las implicaciones que una brecha en el software de código abierto podría tener en su propio producto o servicio
En diciembre de 2021, por ejemplo, se descubrió una vulnerabilidad en Log4j , una biblioteca de registro de código abierto utilizada ampliamente por aplicaciones y servicios en Internet. No abordar esta vulnerabilidad habría dado carta blanca a los ciberdelincuentes para piratear sistemas, robar contraseñas e inicios de sesión, robar datos e inyectar software malicioso en las redes. Log4j es utilizado por millones de computadoras que ejecutan servicios en línea y esta vulnerabilidad causó problemas a organizaciones, gobiernos e individuos por igual. Esta vulnerabilidad particular parecía requerir muy poca experiencia para explotar, lo que hizo que algunos la clasificaran como una de las más graves en años.
No es sorprendente que el gobierno de EE. UU. haya organizado recientemente una reunióncon empresas como Oracle, Apple, Facebook, Google, IBM y Microsoft, entre otras, con miras a mejorar la ciberseguridad en el software de código abierto. Y no fue solo la gran tecnología la que asistió a la reunión de la Casa Blanca: los departamentos de Defensa, Comercio, Energía y Seguridad Nacional de EE. UU. también estuvieron allí para brindar su opinión. El enfoque principal de la reunión fue discutir formas de hacer que el software de código abierto sea más seguro por diseño, y también asegurarse de que cualquier infracción se identifique más rápidamente y se trate con firmeza una vez detectada. Mejorar los tiempos de respuesta para distribuir e implementar correcciones es vital si las organizaciones quieren garantizar que el software comercial esté adecuadamente protegido cuando se integra o trabaja con software de código abierto comprometido.
¿Están holgazaneando los proveedores?
El descubrimiento de cualquier vulnerabilidad en el software de código abierto comúnmente instalado debería impulsar a los proveedores a analizar y crear soluciones para cada uno de sus productos: cuantos más productos haya en la cartera de un proveedor, más tiempo debería tomar este proceso. Es lógico, por lo tanto, que muchos equipos de seguridad de TI elijan el enfoque de seguridad de base amplia que está disponible a través del soporte de software de terceros porque estas soluciones no son específicas del software o del proveedor. Más importante aún, estas correcciones generalmente están listas antes de que se puedan desarrollar los parches de cualquier proveedor.
Como ejemplo, Oracle tardó en abordar las consecuencias creadas por Log4jerror: no proporcionaron rápidamente una solución integral. El error fue divulgado públicamente por la Fundación Apache el viernes 10 de diciembre de 2021. Hubo alertas globales sobre la gravedad del error emitidas por gobiernos de todo el mundo. El período de 24 a 48 horas que sigue a la revelación de cualquier vulnerabilidad es crítico; es cuando los equipos de seguridad deben apresurarse para encontrar una solución. Parecería que Oracle llegó tarde a la fiesta con respecto a la entrega de una solución completa. Persistió la exageración habitual de los medios con respecto a los posibles efectos en las organizaciones y los productos. Utilizando el enfoque de seguridad de base amplia favorecido por el soporte de software de terceros, muchas organizaciones pudieron determinar rápidamente qué productos no se vieron afectados o pudieron abstenerse de usar los marcos afectados.
Los clientes esperan respuestas y soluciones
El error Log4j causó problemas con un archivo de clase Java utilizado para registrar problemas del sistema. Muchas organizaciones proporcionaron a los clientes los pasos necesarios para eliminar la clase Java vulnerable para que no se utilizara en sus sistemas. Oracle, por otro lado, solo pudo emitir un aviso general seguido de una serie de parches, dejando a los clientes en la estacada durante otra semana después de la revelación inicial de la Fundación Apache.
En casos como estos, especialmente cuando se trata de un error potencialmente dañino, los grandes proveedores deben brindar claridad a sus clientes, quienes, naturalmente, estarán preocupados. Debe ser lo suficientemente ágil para ser consciente del problema en primer lugar, realizar una investigación y publicar una respuesta/solución rápidamente: esto es lo que quieren los clientes. No quieren ni esperan tener que pasar por un desconcertante proceso de parcheo para un conjunto de varios productos. Su equipo de respuesta al cliente debe estar listo y esperando con respuestas y posibles soluciones.
Mientras tanto, las discusiones entre los sectores público y privado continúan al más alto nivel con respecto a cualquier amenaza potencial de código abierto. La Casa Blanca claramente se ha tomado esto muy en serio, por lo que es crucial que todos los proveedores de software hagan lo mismo y puedan responder rápidamente si alguno de sus programas se ve afectado por un error de estilo Log4j. Un buen primer paso sería integrar completamente a los proveedores en estas discusiones en curso.
Historias relacionadas :
Meta Open Source : ya estaría transfiriendo Jest a la Fundación OpenJS
Appwrite : ha lanzado un fondo dirigido al desarrollo de software de código abierto
¿Porqué la economía es variable para el código abierto?
¿Existe la posibilidad de aplicar licencias de código abierto a los datos?
Elon Musk : anuncio que el algoritmo de código abierto no lograría resolver los problemas de Twitter
¿Cuáles sería los riesgos emergentes del código abierto?
Mastodon : considerado como una alternativa de código abierto a Twitter
¿Cuáles sería las 3 tendencias en código abierto empresarial?
Elon Musk : mencionó que el algoritmo de Twitter debería ser de código abierto
¿Qué beneficios brinda la tecnología de código abierto para la lucha contra el cambio climático?
¿Cuáles sería las reglas básicas para la gestión de software de código abierto?
¿Porqué las empresas luchan por el software de código abierto?
NetApp : adquiere Instaclustr con la finalidad de ofrecer base de datos de código abierto
NUnit : ya está utilizando herramientas de código abierto para probar el código .NET
Alluxio : acreditado por innovación tecnológica en código abierto y Big Data
Comcast : ahora está difunde su código para impulsar la seguridad de código abierto
El software de código abierto malicioso ingresa al conflicto bélico en Rusia
El software de código abierto en peligro por las luchas contra el hacktivismo en Ucrania
Inteligencia de código abierto : deja rastros digitales en la guerra de Ucrania
¿Cuál sería la finalidad de la 'protestware' para sabotear el código abierto
Relaciona publicidad falsa para llamar software de código abierto
Pinta 2.0 : está disponible con una actualización y más
Pinta 1.7.1 : software de edición de imágenes y dibujo de código abierto
Krita 5.0 : ahora disponible con nuevas versión y más
Tux Paint 0.9.27 : aplicación de dibujito de código abierto para niños y más
Las 7 mejores herramientas de Linux para artistas digitales
[Fuente]: securityboulevard.com
TheDigitalArtist.( 6 de junio de 2022).7999 images. Modificado por Carlos Zambrado Recuperadoan pixabay.com