Seguridad

Un estudio encuentra que el 100 % de las aplicaciones comerciales contienen fallas de seguridad

Varias aplicaciones comerciales populares en categorías que van desde navegadores hasta aplicaciones de mensajería y reuniones contenían componentes de código abierto con vulnerabilidades de seguridad, según una nueva investigación publicada el miércoles.

El estudio realizado por Osterman Research para GrammaTech también encontró que de los productos comerciales más populares de navegación, correo electrónico, intercambio de archivos, reuniones en línea y mensajería probados, el 85 por ciento contenía al menos una vulnerabilidad crítica.

“Las aplicaciones comerciales de software estándar a menudo incluyen componentes de código abierto, muchos de los cuales contienen una variedad de vulnerabilidades conocidas que pueden ser explotadas por malware, pero los proveedores a menudo no revelan su presencia”, dijo Michael Sampson, analista senior de Osterman, en un comunicado. declaración.

“Esta falta de visibilidad de las aplicaciones implementadas y por implementar es esencialmente una bomba de tiempo que aumenta el riesgo de seguridad de una empresa, la superficie de ataque y el potencial de compromiso por parte de los ciberdelincuentes”, agregó.

Las reuniones en línea y los clientes de correo electrónico, que contenían la ponderación promedio más alta de vulnerabilidades, fueron las categorías más expuestas que estudiaron los investigadores.

“Muchas de estas aplicaciones de reuniones en línea se eliminaron rápidamente debido a la pandemia. Es por eso que las aplicaciones de reuniones en línea tienen más componentes de código abierto y más vulnerabilidades”, explicó Christian Simko, director de marketing de productos de GrammaTech, una empresa de pruebas de seguridad de aplicaciones con sede en Bethesda, Maryland.

Agregó que las aplicaciones de correo electrónico y mensajería pueden contener muchas fallas porque dependen de Open SSL, un protocolo de comunicación de código abierto.

«Open SSL es muy frecuente y es un componente de código abierto muy vulnerable», dijo a TechNewsWorld.

Según Osterman, Open SSL representó el 9,6 por ciento de las vulnerabilidades de código abierto encontradas en todas las aplicaciones.

Se necesita un mejor monitoreo

Saryu Nayyar, CEO de Gurucul, una empresa de inteligencia de amenazas en El Segundo, California, sostuvo que el software de código abierto es tan seguro o incluso más seguro que la mayoría del software comercial.

“El enfoque de crowdsourcing para las contribuciones de software generalmente identifica y corrige las vulnerabilidades rápidamente”, dijo a TechNewsWorld.

“Sin embargo, para las organizaciones que usan bibliotecas de código abierto u otro software, les corresponde monitorear el uso de código abierto en su software y parchear o reemplazar el software de código abierto que tiene una vulnerabilidad”, dijo.

“Francamente, muchas organizaciones no se molestan en mantener una lista detallada de su uso del código abierto y no siguen los foros de mensajes de sus bibliotecas de código abierto”, continuó. “Eso los deja vulnerables a los ataques de exploits conocidos debido a la versión que están usando”.

“Las organizaciones revisarán minuciosamente su código personalizado, pero no son tan rigurosos con el código abierto y el código comercial”, agregó Andy Meyer, CMO de GrammaTech.

Explicó que los fabricantes de software comercial están utilizando componentes de código abierto y de terceros para cumplir con las restricciones de tiempo y costo a las que pueden estar sujetos.

“El hecho de que estén usando estos componentes sin probarlos ellos mismos habla del problema de la velocidad y la necesidad de acelerar los ciclos de lanzamiento”, dijo a TechNewsWorld. “Están bajo presión para hacerlo”.

Todo código abierto no es igual

El riesgo que los componentes de código abierto representan para las aplicaciones tiene menos que ver con el componente en sí que con la cadena de suministro que lo respalda, afirmó Tsvi Korren, CTO de campo en Aqua Security, una empresa de seguridad de contenedores con sede en Ramat Gan, Israel.

“Todo se reduce al grado de gobernanza y supervisión, del que a menudo carecen los proyectos de código abierto”, dijo a TechNewsWorld.

“Necesitamos diferenciar entre los proyectos patrocinados y mantenidos por organizaciones (compañías de software o sin fines de lucro) y aquellos que fueron iniciados y aún son mantenidos por individuos o grupos no organizados”, continuó.

“La última categoría presenta el mayor riesgo para las aplicaciones porque estos proyectos no pueden invertir en pruebas de seguridad, no brindan acuerdos de nivel de servicio para reparaciones y pueden ser un objetivo potencial para los atacantes que intentan ‘contribuir’ con código malicioso y hacer es parte del proyecto”, dijo.

Dado que las organizaciones no tienen control sobre los cambios realizados en los componentes de código abierto, deben saber cuándo se realizan cambios en ellos, aconsejó Shawn Smith, director de infraestructura de nVisium, un proveedor de seguridad de aplicaciones con sede en Herndon, Virginia.

“El uso de dependencias que son de código abierto está perfectamente bien siempre que esté auditando adecuadamente la fuente en busca de problemas, además de realizar auditorías continuas cada vez que actualice esa dependencia en su plataforma”, dijo a TechNewsWorld.

“Muchas organizaciones dotarán de personal a sus propios equipos internos para centrarse en solucionar los problemas de seguridad informados en relación con sus componentes de código abierto”, agregó Kevin Dunne, presidente de Pathlock, un proveedor de orquestación de acceso unificado en Flemington, Nueva Jersey.

“El beneficio de los componentes de código abierto es que los equipos pueden crear sus propios parches internamente para solucionar los problemas que les preocupan, pero tiene un costo”, dijo a TechNewsWorld.

Lista de materiales del software

Una clave para reducir el riesgo de usar componentes de código abierto en el software es agregar transparencia al proceso de revisión.

“Resolver el problema comienza con la visibilidad”, observó Dan Nurmi, CTO de Anchore, una empresa de seguridad de contenedores en Santa Bárbara, California.

“Las organizaciones necesitan comprender la imagen completa del código abierto”, dijo a TechNewsWorld.

Una forma de obtener esa imagen es a través de una lista de materiales de software (SBOM), que enumera todos los componentes y dependencias en una aplicación.

“La lista de materiales del software puede ayudar con la transparencia y la visibilidad de todo el panorama de terceros y cuartos, y puede ayudarlo a comprender mejor lo que implica el uso de una herramienta específica”, Demi Ben-Ari, cofundadora y CTO de Panoramays, de Tel. Aviv, Israel, que automatiza, acelera y escala los procesos de seguridad de terceros, dijo a TechNewsWorld.

“Tener una lista de los componentes siempre es útil para que las organizaciones y sus equipos monitoreen las vulnerabilidades publicadas y recientemente descubiertas”, agregó Purandar Das, director ejecutivo y cofundador de Sotero, una empresa de protección de datos en Burlington, Massachusetts.

“También facilita la identificación de los parches que deben aplicarse”, dijo a TechNewsWorld.

Nurmi explicó que la creación de listas de materiales de software es una práctica común en la industria, pero no se ha formalizado”.

“No hay mucha orientación sobre qué tipo de información es relevante cuando se trata de compartir información entre organizaciones”, dijo.

Korren señaló que una buena lista de materiales de software debe indicar los componentes exactos utilizados en el software.

“La transparencia es mejor que ocultar estos componentes, pero revelarlos no reduce el riesgo en el software”, observó.

“Lo que puede hacer una lista de materiales es presionar a los proveedores y usuarios para que presten atención a los riesgos de seguridad y la gobernanza en los componentes de código abierto”, dijo.

“Los usuarios del software podrían encontrar más fácilmente qué vulnerabilidades existen en estos componentes y trabajar para mitigarlas”, explicó.

“La divulgación también indicará si el proveedor se mantiene al día con los lanzamientos de los componentes de código abierto”, continuó.

“Pero todo eso requiere trabajo”, agregó, “y la tendencia en este momento es ignorar el problema para que el software pueda continuar moviéndose a través de la tubería”.

LEER  Los dispositivos IoT no compatibles son problemas cibernéticos esperando a que sucedan

Publicaciones relacionadas

Deja una respuesta

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

Botón volver arriba