Existen problemas de seguridad de código abierto: lidiar con ellos, informe urge

 medidas de protección necesarias para gestionar la implementación de software de código abierto

El software de código abierto se está volviendo mucho más común dentro de las organizaciones, trayendo un conjunto diferente de riesgos y desafíos percibidos en comparación con el software de código cerrado o propietario.

El El Foro de Seguridad de la Información (ISF) publicó hoy un informe para ayudar a los profesionales de seguridad a reconocer los beneficios y los desafíos percibidos del uso de software de código abierto.

"Implementación de software de código abierto: desafíos y recompensas", que IFS llama un documento informativo , se centra en la creación de un programa de medidas de protección para gestionar eficazmente el despliegue de OSS.

Uno de sus objetivos es detallar la diferencia entre los mitos y las realidades que rodean el uso de código abierto. Según ISF, esa comprensión es crítica para asegurar los componentes de código abierto en aplicaciones de código mixto.

El software de código abierto está emergiendo como una parte central de la infraestructura y las aplicaciones de TI. Según ISF, este estado se debe en gran medida a la creciente popularidad de las metodologías de desarrollo ágil y las prácticas DevOps. Con un número considerable de aplicaciones comerciales y personalizadas que incorporan OSS, no se puede ni se debe ignorar.

A medida que OSS se convierte en el pilar principal dentro del desarrollo de aplicaciones y la infraestructura, los profesionales de seguridad necesitarán comprender OSS y gestionar los desafíos asociados con su componentes. Las soluciones a estos desafíos de seguridad deben implementarse como parte de un programa de gestión de OSS, dirigido por una persona de alto rango nombrada para el cargo de Administrador de programas de OSS, insta a la organización.

La integración de todas estas medidas en un solo programa general permitirá un enfoque holístico y coordinado para gestionar los riesgos de OSS, dijo Paul Holland, analista de investigación principal de ISF. Esa es una necesidad esencial para garantizar que la seguridad permanezca intacta.

"Muchas organizaciones están adoptando metodologías ágiles y DevOps, lo que está impulsando una mayor adopción de OSS y, a su vez, la creación de nuevas aplicaciones de fuente mixta", dijo Holland.

Objetivos de largo alcance

La guía ISF sobre la implementación de software de código abierto reúne un estudio rápido para los trabajadores de TI y otros usuarios de código abierto en la empresa. Proporciona enfoques útiles sobre cómo las organizaciones pueden manejar eficazmente los desafíos de usar OSS y por qué necesitan hacerlo.

La guía también habla sobre cómo maximizar los beneficios y cosechar las recompensas del uso de software de código abierto. En cierto modo, esta guía práctica de ISF es un intento de cerrar la puerta del granero de software antes de que entren más caballos de malware.

El software de código cerrado ha sido un elemento básico de las aplicaciones y la infraestructura de TI de la organización. Pero muchos programas de software bien establecidos y populares son en realidad de código abierto. Por lo tanto, las organizaciones deben reconocer que OSS ya puede existir dentro de su propio entorno. A menudo se usa en combinación con software de código cerrado, creando lo que se denomina 'software de código mixto'.

El software de código mixto puede derivarse de cualquier número de combinaciones de componentes OSS. Las posibilidades incluyen software de código cerrado, código comprado y código interno. Luego, los desarrolladores pueden integrar estos componentes para crear una aplicación de software de fuente mixta personalizada.

Los riesgos de seguridad de usar OSS dentro de la infraestructura y aplicaciones de TI traen desafíos centrales que deben minimizarse, advierte la guía. Esa tarea se hace más compleja si las organizaciones tienen un conocimiento limitado de los componentes OSS en uso. Estos incluyen obligaciones complejas de licencia y propiedad intelectual, una escasez de habilidades relevantes de OSS y la ausencia de seguridad en las prácticas de DevOps.

Se necesita equilibrio

Se necesita un esfuerzo concertado para gestionar el uso de OSS de manera adecuada y efectiva. La creciente prevalencia de OSS necesita ser equilibrada, instó Holland. Para algunas organizaciones, el primer paso es darse cuenta de que los mitos que rodean a OSS son simplemente ilusiones.

Para otras organizaciones, el atractivo de OSS y software de código mixto ya es evidente. Esto les permite desarrollar nuevas aplicaciones de forma segura y aumentar la velocidad de comercialización de nuevas ideas, explicó.

OSS a menudo se considera inseguro y sin soporte. A medida que estas connotaciones negativas continúan manchando su reputación, algunas organizaciones lo prohíben oficialmente, aunque sin saberlo estén utilizando OSS.

Otros adoptan con entusiasmo OSS, aprovechando sus ventajas, como ayudar a un desarrollo flexible y rápido. OSS puede ser una influencia positiva en el desarrollo de software. Pero eso solo puede suceder si se usa y administra de manera responsable, según la última guía de la ISF.

El apoyo es esencial

La guía recomienda apoyar al administrador del programa OSS de la organización con los fondos y recursos necesarios para desarrollar un programa y equipo viables. Mientras que en algunos casos, las herramientas existentes para software de código cerrado se pueden extender para asegurar y administrar OSS.

Otros casos de integración requieren que el equipo del programa obtenga herramientas adicionales para mejorar aún más la seguridad de OSS. El equipo también debe monitorear las fuentes de inteligencia de amenazas para las menciones de los componentes de OSS que la organización está utilizando, de acuerdo con la guía ISF.

"Resistir el cambio a OSS podría limitar la capacidad de una organización para progresar y evolucionar. Si se aprovecha de manera efectiva, OSS puede potencialmente ser un acelerador para el negocio ", dijo Holland. "Fomentar un programa de gestión de OSS es, por lo tanto, vital para asegurar y administrar OSS, permitiendo que la organización lo use de manera segura".

Se requiere preparación

La combinación de la dinámica de código abierto con prácticas establecidas en torno a la gestión de software de código cerrado proporcionará un programa de gestión de software coherente y completo. El resultado proporcionará la mejor oportunidad para el éxito, agregó Holland.

Muchos proveedores de software de código cerrado tradicionalmente están adoptando los principios OSS. Eso significa que OSS llegó para quedarse, declaró la ISF.

La flexibilidad del software de código abierto y mixto podría conducir a una disminución del software de código cerrado. A su vez, eso podría causar un cambio fundamental en la gestión de software, licencias y seguridad.

Arregle lo que está roto

"Implementar software de código abierto: desafíos y recompensas" presenta una serie de desafíos y soluciones propuestas para una serie de situaciones de TI típicas. La información cita problemas específicos que involucran el uso de componentes de código abierto.

Un desafío presentado involucra cómo algunas organizaciones usan aplicaciones de software que tienen código de código abierto inadvertidamente incluido en la infraestructura de TI. O la organización carece de una vista completa de todos los componentes de OSS implementados en su entorno.

La situación implica tener componentes de código abierto implementados de manera incontrolada y potencialmente en un estado inseguro con vulnerabilidades obsoletas, sin parches y propensos a vulnerabilidades. Sin un conocimiento adecuado de dónde y cómo se usa OSS, la organización corre el riesgo de permitir vulnerabilidades en su infraestructura de las cuales el personal de TI no es consciente y, por lo tanto, no puede abordar de manera proactiva.

La guía señala que esto ejemplifica lo que llevó a la violación de Equifax en septiembre de 2017 . En ese caso, los actores maliciosos explotaron una versión desactualizada de Apache Struts, un marco de aplicación web OSS para aplicaciones Java. El personal de TI no sabía que este componente de la plataforma OSS existía en el entorno corporativo. Por lo tanto, no se había incluido en los procesos y cronogramas de administración de parches de la compañía.

Arreglos en proceso

La guía de la ISF explica una solución para ese desafío roto. Sugiere que las organizaciones creen y mantengan un inventario preciso y actualizado de todos los componentes de OSS dentro de su entorno corporativo. Es posible que se requiera una fase de descubrimiento inicial si aún no existe un inventario o si la organización contempla la posibilidad de que OSS esté en uso sin ser formalmente reconocido o documentado.

La información catalogada debe incluir la replicación de detalles sobre software de fuente cerrada, fuente de OSS (por ejemplo, proveedor, desarrollador externo, repositorio de OSS o proyecto de desarrollo interno), versiones implementadas de componentes de OSS, dependencias de software, proveedores de soporte y ubicaciones de actualizaciones seguras disponibles para descargar.

Se puede crear compilar dicho inventario a mano. Una opción alternativa es implementar una herramienta de descubrimiento automatizada que escanea y monitorea la infraestructura para crear una base de datos de software y las versiones en uso.

Ausencia de seguridad en las prácticas de DevOps

Otro desafío crítico en la guía ISF utiliza el ejemplo de desarrolladores ágiles y DevOps que favorecen la implementación rápida de aplicaciones sobre la seguridad del código. Las soluciones sugeridas marcan el ritmo de lo que debería ser una mejor práctica para la codificación de aplicaciones.

La guía ISF sugiere que los desarrolladores internos deben conocer y capacitarse en prácticas de codificación segura relacionadas con OSS y algunos de los desafíos que OSS presenta al hacer que las aplicaciones de origen mixto sean seguras por diseño. Las responsabilidades de codificación segura de los desarrolladores deben describirse en un ciclo de vida de desarrollo seguro (SDL) específico para OSS.

Eso, a su vez, debe estar estrechamente relacionado con la metodología SDL para software de código cerrado. Los plazos y los plazos para escribir el código deben tener en cuenta la incorporación de la seguridad en la fase de diseño.

Cómo funcionan las cosas

Si una organización ejecuta un software de código abierto y utiliza un modelo de TI central, debe haber operadores, o alguien, responsable de las operaciones de TI en general. Esa persona es responsable del mantenimiento del parche y de garantizar que se realicen las actualizaciones, según Wei Lien Dang, cofundador y director de estrategia en StackRox .

"Esto también podría ser manejado por alguien en el equipo de desarrollo o DevOps. Si bien el software de código abierto es a menudo una opción de bajo costo, eso no significa que no esté exento de gastos generales. Esto viene en forma de experiencia y / o capacitación para garantizar que el código OSS esté parcheado y protegido ", dijo a LinuxInsider.

Esta es una de las razones por las cuales las organizaciones optan por software comercial o un servicio administrado en la nube. En esos casos, es responsabilidad del software o del proveedor de la nube hacer que los parches estén disponibles. Agregó que usted obtiene el beneficio adicional de un nivel de soporte y mantenimiento subcontratados.

El trabajador de TI promedio puede no saber cómo parchear el código OSS. Pero no es raro que la persona que tomó la decisión de aprovechar OSS dentro de una organización sea la responsable de mantenerlo, explicó Dang.

"Pero el desafío es que el mantenimiento de este software se convierte en conocimiento tribal. Entonces, si esa persona se va, las otras personas en el equipo de TI necesitan averiguar qué hacer ", sugirió.

Deberes variados

Los deberes de los trabajadores de TI varían mucho de una organización a otra. Pero una gran cantidad de organizaciones tienen muy pocos recursos de TI que se centran en parchar, según Thomas Hatch, CTO y cofundador de SaltStack .

"Los profesionales de TI modernos dedican mucho más tiempo a administrar API y UI de nivel. Deben tratar con un gran grupo de sistemas y servicios y no están tan centrados en el sistema y la gestión de OSS como lo estaban hace 10 años ", dijo a LinuxInsider.

La seguridad continua de los componentes de software abiertos es un problema, acordó Hatch.

"La capacidad de sacar grandes cantidades de software libre, no probado, no validado y no necesariamente protegido de la plataforma ha creado una responsabilidad profundamente arraigada en áreas que hacen un uso intensivo del software de código abierto, " él dijo.

Capacitación para todos

Si estamos hablando del personal de TI central o de alguien con un rol de E / S, entonces sí, cree Dang. Cualquiera que sea responsable de la parte del entorno en la que se usa OSS debe tener este conocimiento.

Si está utilizando código abierto, asume la responsabilidad de rastrear parches y divulgaciones de seguridad. Argumenta que esa debería ser responsabilidad del responsable de la toma de decisiones que decidió utilizar OSS.

"Deberían asumir la responsabilidad de operar esa parte de la pila y el entorno en el que se ejecuta el OSS. También deberían ser responsables de trabajando con su equipo para implementar un proceso para mantener parches o de lo contrario corren el riesgo de perder el conocimiento crítico si dejan la organización ", dijo Dang.

¿Todos los OSS usan al culpable?

Los beneficios provienen del uso de software de código abierto, pero las organizaciones deben tener cuidado de comprender cómo lidiar con las vulnerabilidades y los problemas de licencia que podrían crear exposiciones, advirtió Dang.

Los desarrolladores de software se centran en crear y enviar software. Existen prácticas de desarrollo de software, independientemente de la metodología. Aquellos que toman prestado del código abierto deben tener en cuenta la seguridad del producto, instó Dang.

"No es exclusivo de DevOps. Si pasa por alto el proceso de parcheo de OSS, puede poner fácilmente en riesgo su organización", dijo. [19659003] Hay dos consideraciones centrales cuando se usa OSS en el desarrollo de software. Una es que tiene las herramientas adecuadas para garantizar la protección. La otra es que tiene los procesos correctos para administrar parches.

Debe tener una forma de descubrir vulnerabilidades, problemas de licencia y otros riesgos asociados con el uso de OSS. La metodología, Agile, DevOps, o de otro modo, no debería marcar la diferencia.

"Si elige usar OSS, debe comprender los riesgos de seguridad y las implicaciones de hacerlo y estar preparado para enfrentarlo de manera adecuada", dijo Dang

Disponibilidad

"Implementación de software de código abierto: desafíos y recompensas" está disponible como descarga en PDF aquí .

Este documento informativo es gratuito para los miembros de la ISF. Los no miembros pueden descargar el documento después de completar un formulario de consulta de membresía.


Leave a Reply

Your email address will not be published. Required fields are marked *

CLip art of Flip Day 2 CLip art of Flip Day 1 CLip art of Flip Day 1