Lista de materiales de software: Gestión de los riesgos de ciberseguridad del software

19 de setiembre, 2022 | Artículo

Por Tucker Bailey, Justin Greis, Matt Watters, y Josh Welle

A medida que las vulnerabilidades relacionadas con el software siguen aumentando, las empresas deben gestionar sus ciberriesgos de software para innovar más rápidamente y crear productos digitales más seguros.

Hasta hace poco, la mayoría de las empresas desconocían los "ingredientes" o el código que compone el software que impulsa sus productos y el software empresarial. Esto es un problema porque el uso de código de terceros está aumentando, y el consumo de software de código abierto (OSS, siglas en inglés de Open Source Software) se acelerará en los próximos años.

Las empresas recurren al OSS porque reduce los costes y aumenta el ritmo de desarrollo del software. Al incorporar en capas el código que ya ha construido otra persona, los desarrolladores pueden reducir su tiempo de comercialización y acelerar los conjuntos de características más buscados por sus socios comerciales. El problema es que el código del repositorio de OSS puede llevar incrustado malware, errores u otras vulnerabilidades que el desarrollador desconoce. Sin un sólido proceso de verificación del código en el repositorio de OSS del que extraen sus desarrolladores, las empresas seguirán sin ser conscientes de las amenazas que acechan a sus productos.

Para seguir el ritmo de la evolución de la dinámica de la seguridad, las empresas necesitan nuevos programas y técnicas de gestión para comprender el origen y la seguridad del código que sustenta sus productos digitales y sus operaciones comerciales. Sin este sistema, las empresas seguirán siendo vulnerables a la inserción involuntaria de programas maliciosos que podrían causar incidentes de ciberseguridad o dañar aplicaciones críticas. Aunque algunas ciberamenazas pueden evitarse mediante el desarrollo interno de código personalizado, ese proceso requiere de muchos recursos y tiempo. Además, el uso de OSS tiene ventajas, como poder desarrollar rápidamente en la nube o aumentar la productividad de los desarrolladores. En realidad, la mayoría de las aplicaciones se construyen utilizando una combinación de código personalizado y componentes de código abierto. Es entonces cuando un delicado acto de equilibrio recae en los directores de tecnología (CTO, chief technology officers), directores de información (CIO, chief information officers) y directores de seguridad de la información (CISO, chief information security officers), que son sensibles a los riesgos inherentes al OSS.

Un programa de lista de materiales de software (SBOM, software bill of materials) puede ayudar a las empresas a protegerse a sí mismas y a sus clientes mediante la creación de un sistema que examina todo el código entrante antes de que pueda ser adoptado por los desarrolladores.

Qué es una SBOM y por qué es útil

Una SBOM es como la etiqueta nutricional de una caja de cereales: enumera los ingredientes del interior, destacando el contenido que puede ser perjudicial para algunos, como el gluten y el maní. En concreto, una SBOM es un inventario formal, legible por máquina, de los componentes de software y sus dependencias (que resultan de la combinación de varios componentes de OSS, código de terceros y código desarrollado internamente), la información técnica sobre esos componentes y las relaciones jerárquicas del código (Anexo 1).

Anexo 1

Una SBOM ayuda a los desarrolladores a conocer el origen del "código detrás del código" para que puedan determinar si es seguro. También les ayuda a entender y mitigar las vulnerabilidades conocidas en el código, ahorrando tiempo y costes. Las SBOM también ayudan a los departamentos legales y de cumplimiento a identificar el historial de licencias y los casos de uso permitidos para una sección de código de terceros, lo que reduce cualquier posible uso indebido. Además, las SBOM ayudan a los equipos de seguridad y forenses a identificar el impacto en el software tras el descubrimiento de vulnerabilidades y exposiciones comunes (CVE, common vulnerabilities and exposures) recientemente identificadas, lo que mejora la capacidad de respuesta y reparación de las organizaciones.

Por qué es necesario un programa de SBOM

Durante los últimos cinco años, el desarrollo de OSS aumentó de aproximadamente el 35 por ciento a cerca del 75 por ciento de la base de código auditada de las organizaciones. Como ejemplo, en 2021, según OpenUK, nueve de cada diez empresas con sede en el Reino Unido declararon utilizar OSS. Las organizaciones utilizan OSS porque ayuda a ahorrar costes, a la flexibilidad de los desarrolladores y a la velocidad de codificación.

El uso de OSS crea la oportunidad de una mayor colaboración entre los desarrolladores y permite a los codificadores avanzar rápidamente, ya que las bibliotecas de código contienen cantidades ilimitadas de funcionalidades y recursos de herramientas preconstruidas. Disponer de componentes de software bajo demanda permite a los desarrolladores aprovechar el trabajo de otros desarrolladores. Los componentes son accesibles y están disponibles desde cualquier lugar, y estos elementos son independientes de los fabricantes individuales, lo que los hace atractivos para las empresas de nueva creación y los actores tecnológicos emergentes, o esencialmente para cualquiera que quiera construir software rápidamente.

Aunque el beneficio de incorporar código de terceros es evidente, el OSS contribuye al riesgo organizativo. El OSS no está regulado ni supervisado por una autoridad central y está disponible públicamente. Puede contener posibles vulnerabilidades, código desactualizado y explotaciones cibernéticas, que pueden exponer a las organizaciones a ciberataques. La mayoría de las organizaciones buscan comprender mejor y reducir sus riesgos cibernéticos y tecnológicos, pero las organizaciones reconocen que desarrollar y mantener un código seguro es una piedra angular vital de cualquier estrategia de ciberseguridad.

Las organizaciones ya no se preguntan si se verán afectadas por un ciberataque, sino que se preguntan cuándo, cómo y cuál será el impacto después de que se produzca el ciberataque. En 2014, el 62% de las organizaciones declararon haber sufrido un ciberataque. En 2021, esa cifra aumentó al 86%. El coste de los ciberataques también está creciendo rápidamente. En 2015, el impacto mundial de la ciberdelincuencia se estimó en $3 billones, según el Informe de Investigaciones de Violaciones de Datos de Verizon. En 2021, esa cifra aumentó a aproximadamente $6 billones y se espera que aumente a cerca de $10 billones en 2025. De los miles de ciberataques diarios, las vulnerabilidades de la cadena de suministro son cada vez más la causa.

Dadas las ventajas del OSS, así como sus riesgos inherentes, las empresas encuentran cada vez más difícil gestionar sus cadenas de suministro de software. Por ejemplo, en diciembre de 2020, la explotación del malware Sunburst demostró tener orígenes en la cadena de suministro. El incidente afectó a unos 33.000 usuarios, de los cuales 18.000 tenían el producto infectado con el código malicioso.

Las SBOM permiten a las empresas conservar las ventajas del OSS al tiempo que gestionan los riesgos. Ayudan a las empresas a evitar problemas, como en el caso de Sunburst, donde una empresa que tenía capacidad de SBOM pudo determinar que era vulnerable al código contaminado en dos horas. Otros afectados fueron menos afortunados, como una empresa de energía que determinó que tenía el software defectuoso dos meses y medio después. Durante esos dos meses y medio, la empresa fue vulnerable a más ataques y a riesgos empresarial.

Los ciberdelincuentes y otros agentes malintencionados suelen emplear varios métodos para lanzar ataques a la cadena de suministro de software, a menudo dirigidos al código abierto o al código común de terceros. Para ello, en 2018, los investigadores descubrieron 12 bibliotecas maliciosas de Python subidas al índice oficial de paquetes de Python (PyPI). En conjunto, incidentes como el caso del malware Sunburst y el compromiso del Índice de Paquetes Python han impulsado a las empresas a considerar el desarrollo rápido de SBOM (véase la barra lateral, "El gobierno federal quiere proteger a la nación del código malicioso").

Cómo mitigan los riesgos los programas de SBOM con una mayor transparencia del código

La mayoría de las organizaciones tienen aplicaciones formadas por diferentes subcomponentes y piezas, algunas tomadas de bibliotecas de OSS, otras compradas a terceros y otras creadas y personalizadas por los desarrolladores. Cada fuente tiene diferentes limitaciones asociadas. Por ejemplo, el OSS y el software de terceros tienen licencias que cambian con el tiempo o pueden tener limitaciones de uso. Un sistema típico de SBOM estudia, identifica y caracteriza estos elementos de codificación (Anexo 2).

Anexo 2

Las organizaciones que se esfuerzan por comprender las vulnerabilidades de su código se exponen a riesgos financieros o de seguridad. A continuación se presentan varios beneficios que una organización puede experimentar al crear un programa SBOM:

 

·        Identificación y mitigación de vulnerabilidades. Los sistemas SBOM hacen un inventario de los subcomponentes del código y permiten a los analistas identificar el código con vulnerabilidades conocidas. Cuando se anuncia una vulnerabilidad crítica, los analistas de seguridad hacen referencia a los artefactos de la SBOM y determinan si hay un impacto en el código. Esto ayuda al personal de respuesta a incidentes a identificar dónde existen vulnerabilidades y a priorizar las mitigaciones. También proporciona a los líderes la capacidad de responder con rapidez y confianza cuando tratan con miembros del consejo de administración, clientes, inversores y reguladores.

·        Gestión de licencias de software. Los programas SBOM ayudan a las organizaciones a gestionar sus licencias de software y OSS de terceros, que pueden ser bastante complejas y cambiar con el tiempo. Esto garantiza que los desarrolladores puedan determinar de forma coherente los casos de uso permitidos para el OSS y el software de terceros, protegiendo en última instancia a las organizaciones del riesgo financiero derivado del uso inapropiado o no autorizado del software de terceros. También ayuda a los equipos de cumplimiento a responder a las reclamaciones o auditorías de licencias.

·        Mejora del ciclo de vida del desarrollo de software (SDLC, software development life cycle). Los programas SBOM pueden ayudar a las organizaciones a mejorar su SDLC. La generación de una SBOM en momentos preestablecidos durante el SDLC puede identificar problemas como vulnerabilidades conocidas o problemas de licencia. Los equipos mitigan estos problemas con antelación, reduciendo los costes y evitando los retrasos. Los programas SBOM permiten a las organizaciones ser más eficientes y acelerar la forma de construir, implantar y ejecutar el software.

Por ejemplo, a medida que se construye el código, los desarrolladores crean una SBOM inicial, que enumera las dependencias inherentes al software. Durante las pruebas y el empaquetado, se identifican las vulnerabilidades y las dependencias adicionales y se actualiza la SBOM a medida que se implanta el código. A medida que surgen vulnerabilidades durante las operaciones, el programa SBOM alertará a los desarrolladores cuando sea necesario aplicar un parche. Tras la aplicación del parche, el SBOM se actualiza de nuevo.

Cómo desarrollar un programa SBOM: Invertir, crear, integrar y diseñar

Teniendo en cuenta los beneficios y los retos asociados al desarrollo de OSS, está claro que los programas de SBOM son parte integral de una codificación más segura y de una empresa resistente. Para ello, las organizaciones pueden centrarse en cuatro prácticas clave a la hora de establecer programas de SBOM:

 

1.     Invertir en las capacidades de SBOM aprovechando las herramientas de análisis de la composición del software (SCA, software composition analysis) existentes. Muchas organizaciones cuentan con capacidades de SCA. Dependiendo de la solidez de las capacidades, los equipos pueden utilizarlas como base para construir un programa de SBOM. La administración puede utilizar los recursos de forma eficiente determinando qué herramientas del SBOM pueden comprarse o desarrollarse internamente. Los responsables de los productos deben encontrar un proveedor de confianza y crear un programa que utilice herramientas que se ajusten a los procesos del SDLC, incluida la integración fluida y automatizada con una canalización de integración continua e implantación continua (CI/CD, continuous integration/continuous deployment). Las capacidades automatizadas de la SBOM pueden desarrollarse internamente o comprarse a un proveedor externo.

2.     Crear un programa de SBOM con un equipo interfuncional. Los programas SBOM implican a múltiples partes de la organización, cada una con una función diferente. Es importante poner en marcha un programa de SBOM con un equipo interfuncional. Este equipo debe incluir personal de diversos ámbitos -desarrolladores, seguridad de la información, adquisiciones, legal, riesgos, privacidad y cumplimiento, porque los programas de SBOM tocan múltiples partes de la organización. Cada equipo participante debe tener representación en los niveles de toma de decisiones, y sus necesidades deben tomarse en cuenta a lo largo del proceso (Anexo 3).

3.     Integrar la SBOM en el Los beneficios de la seguridad y la eficiencia del SDLC ayudan a generar una mayor aceptación por parte de los desarrolladores. Los programas SBOM proporcionan beneficios a los desarrolladores al identificar las vulnerabilidades y los problemas de licencia en las primeras etapas del proceso. Las organizaciones pueden beneficiarse más cuando examinan sus procesos de desarrollo e integran la generación y revisión de SBOM en múltiples puntos del ciclo de vida del desarrollo. La creación de capacidades automatizadas de generación y revisión de la SBOM reduce la carga de trabajo y alienta a los desarrolladores a adoptar nuevas formas de trabajo.

4.     Diseño de la gobernanza de la SBOM. Los programas de SBOM requieren una colaboración y comunicación interfuncional y pueden requerir una estructura adicional para incentivar la adopción, el cumplimiento y la cooperación. Las organizaciones que tienen una cultura descentralizada o no jerárquica pueden tener dificultades para que los desarrolladores cumplan con los requisitos de la SBOM. Los beneficios de la seguridad y la eficiencia del SDLC ayudan a generar una mayor participación de los desarrolladores. Además, las organizaciones pueden considerar una estructura de gobierno que asigne funciones y responsabilidades para las tareas relacionadas con la SBOM.

Anexo 3

Lanzamiento de un programa SBOM

Las empresas corren a utilizar código de terceros, incluido el OSS, lo que significa que la creación de un programa de SBOM debe seguir el mismo camino para evitar los retos que se plantean a muchos en el mundo empresarial actual. Además de este artículo, en los foros de desarrolladores de la Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA, Cybersecurity and Infrastructure Security Agency) y del Instituto Nacional de Normas y Tecnología (NIST, National Institute of Standards and Technology) se puede encontrar orientación sobre la creación de un programa. La normativa SBOM afecta principalmente a las empresas que prestan servicios al gobierno, como las del sector aeroespacial y de defensa, pero puede ser una guía útil para todas las empresas que quieran mitigar los mismos problemas. Los sectores altamente regulados, como los servicios públicos y financieros, suelen tener la misma obligación de supervisar el uso del software de OSS.

De cara al futuro, las organizaciones que examinen y evalúen de forma proactiva el código que entra en su ecosistema a través de un sólido programa SBOM estarán mejor preparadas para las inminentes normativas gubernamentales sobre la cadena de suministro de software y mantendrán su infraestructura de TI y a sus clientes más seguros. Programas robustos de SBOM permiten a las organizaciones construir un código seguro de manera rentable y eficiente frente a las crecientes ciberamenazas. El momento de actuar es ahora.

SOBRE EL/LOS AUTOR/ES

Tucker Bailey es socio de la oficina de McKinsey en Washington, DC; Justin Greis es socio de la oficina de Chicago; y Matt Watters es miembro asociado de la oficina de Nueva Jersey, donde Josh Welle es consultor.

Los autores desean agradecer a Jim Boehm, Dennis Dias, Michael Glynn, Alex Keegan, Charlie Lewis, Lucy Shenton y Daniel Wallance sus aportaciones a este artículo.