Por: Glenda Suárez Cabrera, CISA, CISSP, CISM, Director IT Quality, Risk, Compliance (QRC) & Security at Pitcher
Tradicionalmente, los proveedores de software han implementado procedimientos de gestión del Ciclo de Vida del Desarrollo de Software (SDLC en inglés Software Development Lifecycle) para garantizar un enfoque estructurado y coherente en las prácticas de desarrollo de software, asegurando que todas las etapas del proceso: planificación, diseño, construcción, lanzamiento, mantenimiento, soporte etc., se ejecuten de manera controlada. Si bien estos procedimientos se han implementado para lograr productos funcionales de alta calidad, no necesariamente abordan el elemento de seguridad.
Los pasos para «asegurar el producto» suelen añadirse como un complemento al proceso SDLC, y en muchas organizaciones, la seguridad se trata como un “lujo” o un último paso en el proceso de validación del producto. No obstante, esta falta de atención a la seguridad no durará mucho tiempo. Las prácticas de seguridad por diseño y las características de seguridad integradas en el producto se están convirtiendo, con mayor frecuencia, en requisitos no negociables para los grandes clientes corporativos de productos de software.
Desarrollar un gran software con seguridad desde el diseño
Implementar un proceso de Ciclo de Vida de Desarrollo de Software Seguro (SSDLC) no es tan sencillo. El primer paso es preguntar a nuestra organización si estamos listos para tener dicho proceso en marcha, no solo para desarrollar un gran software, sino para hacerlo con principios de seguridad por diseño en mente. El compromiso del liderazgo con la seguridad es fundamental aquí. Cuando hay compromiso desde la alta dirección, la seguridad deja de ser un «lujo» y se convierte en una declaración de gestión, un principio de la empresa, un valor compartido por el equipo, un objetivo tangible, una prioridad durante la refinación y planificación, un conjunto obligatorio de pasos y verificaciones a lo largo del SDLC, un KPI/KRI en los informes de gestión, etc. Cuando esto sucede, la seguridad deja de ser una tarea adicional y se integra en el ADN de nuestros equipos. Comenzamos a entregar productos en línea con los compromisos que hemos asumido, pasando de justificar nuestra robustez, confiabilidad, sostenibilidad y transparencia, a demostrarla.
En febrero de 2022, el NIST publicó el Marco de Desarrollo de Software Seguro (SSDF) Versión 1.1, que describe recomendaciones para integrar la seguridad en todas las etapas del proceso SDLC. En este marco, el NIST propone prácticas organizadas en cuatro grupos:
- Preparar la organización (PO): Las organizaciones deben asegurarse de que su personal, procesos y tecnología estén preparados para realizar el desarrollo de software seguro a nivel organizativo.
- Proteger el software (PS): Las organizaciones deben proteger todos los componentes de su software contra manipulaciones y accesos no autorizados.
- Producir software bien asegurado (PW): Las organizaciones deben producir software bien asegurado con mínimas vulnerabilidades de seguridad en sus versiones.
- Responder a vulnerabilidades (RV): Las organizaciones deben identificar vulnerabilidades residuales en sus versiones de software y responder adecuadamente.
Los cuatro grupos de prácticas proporcionan principios de alto nivel y ejemplos conceptuales para satisfacer los criterios de lo que debe ser un producto de software seguro. En cada una de estas prácticas, el NIST también aborda cómo debemos gestionar los riesgos de seguridad introducidos por los componentes de software de terceros (aproximadamente el 20% de todo el marco).
El uso de componentes de terceros, ya sea de software comercializado o de código abierto (OSS), sigue creciendo, ya que la comunidad de desarrollo de software observa que el desarrollo orientado a componentes ahorra tiempo y mejora la calidad del software personalizado. Las investigaciones muestran que el 76% del código base total utilizado suele ser código OSS, lo que significa que el peso del OSS en la composición de nuestro software es bastante significativo. Sin embargo, los componentes OSS y de terceros, en general, siguen siendo subestimados, o simplemente seguimos bajo la suposición de que si son ampliamente distribuidos y utilizados, deben ser seguros. Por lo tanto, ha habido una falsa sensación de seguridad en lo que respecta a los riesgos de componentes de terceros. La investigación de seguridad de la cadena de suministro de ISACA de 2022 muestra que, para las empresas encuestadas:
- Casi 1 de cada 5 evaluaciones de terceros no incluye evaluaciones de ciberseguridad y privacidad.
- El 39% no ha desarrollado planes de respuesta a incidentes con proveedores en caso de un evento de ciberseguridad.
- El 49% dice que no realiza escaneos de vulnerabilidades ni pruebas de penetración en la cadena de suministro.
- El 61% dice que sus evaluaciones de riesgo no incluyen evaluaciones de riesgo de la cadena de suministro específicamente para dispositivos que usan inteligencia artificial (IA).
Sin embargo, debido a los recientes ataques a la cadena de suministro de software, las empresas están tratando de obtener más visibilidad sobre sus dependencias en la cadena de suministro y entender los riesgos que introducen en su entorno. En la siguiente sección, me gustaría ampliar el marco del NIST y arrojar luz sobre las prácticas que los fabricantes de software, los vendedores y los clientes pueden aplicar para gestionar eficazmente los riesgos de los componentes de terceros como parte del proceso SSDLC:
Realizar un estudio de propósito, viabilidad y mantenibilidad antes de introducir un componente de terceros: Al igual que al adquirir un proveedor de herramientas o servicios profesionales, la importancia del proceso de adquisición de un componente de software de terceros no debe subestimarse. Por esta razón, es importante tener algunas reglas básicas para seleccionar e implementar el componente adecuado:
- Definir propósito: Evaluar varios componentes para determinar cuál satisface mejor la funcionalidad requerida. Documentar los pros y contras de al menos tres componentes preferidos.
- Determinar viabilidad: Evaluar el costo de desarrollar su propia funcionalidad frente a utilizar un componente de terceros, tanto a corto como a largo plazo. Evaluar la viabilidad y el costo de los esfuerzos de integración, y los recursos para mantenerlo.
- Analizar mantenibilidad: A menudo pasado por alto, debido a los plazos ajustados para entregar un producto a corto plazo, la mantenibilidad del componente debe ser un factor decisivo para decidir si debe usarse. Las preguntas simples a abordar incluyen: ¿Existe suficiente documentación y soporte sobre el componente? ¿Hay una hoja de ruta del producto? ¿Se actualiza el componente regularmente? ¿Podemos mantenernos al día con todas las actualizaciones? ¿Somos capaces de evitar componentes heredados?
Los componentes de software de terceros también deben someterse a una evaluación de riesgos de terceros: Las evaluaciones de Impacto en el Negocio (BIA) y las Evaluaciones de Riesgo de Terceros (TPRA) se han adoptado ampliamente como la metodología preferida para comprender los riesgos de los proveedores y rechazar o aceptar proveedores dependiendo de si se ajustan a nuestra postura de apetito por el riesgo. Los proveedores de herramientas y servicios son los más comúnmente sometidos a estos ejercicios, mientras que los componentes de terceros de nuestros propios productos de software a menudo son exentos. Ya sea una aplicación para la entrega de correos electrónicos, una solución para traducciones o un chatbot impulsado por IA, todos los componentes similares a aplicaciones deben evaluarse según los criterios relacionados con la seguridad y la privacidad para la selección de proveedores. Dichos criterios pueden incluir nuestros requisitos de encriptación, el programa de gestión de parches y divulgación de vulnerabilidades de terceros, las capacidades de respuesta a incidentes de seguridad del producto, la revisión de informes SOC 2, la Declaración de Aplicabilidad (SOA) de ISO 27001 y la revisión de la política de protección de datos, entre otros elementos críticos que la organización considera importantes. Un TPRA que resulte en riesgos o hallazgos debe utilizarse para decidir si se aprueba el uso de un componente y para revisarlo y hacerle seguimiento periódicamente.
Utilizar el Análisis de Composición de Software (SCA) y SBOM para fortalecer la seguridad: Al igual que nos interesa conocer los ingredientes de los productos alimenticios que consumimos, tener interés en los ingredientes que componen nuestros productos de software puede brindarnos información valiosa sobre la seguridad, el cumplimiento y la mantenibilidad de estos. Aprovechar soluciones automatizadas como el Análisis de Composición de Software (SCA) para analizar la lista de materiales de Software (SBOM) puede ser un buen comienzo para tener más control sobre nuestros productos de software y gestionar proactivamente los riesgos de la cadena de suministro. Dependiendo del formato, ya sea SPDX, CycloneDX o SWID, los SBOM pueden proporcionarnos la procedencia de los datos de los componentes de nuestros productos, como el nombre del fabricante, la versión del paquete, la información de licencia, las vulnerabilidades, las relaciones entre paquetes, los servicios, las dependencias y mucho más. Tal información de procedencia puede ayudarnos a identificar conflictos de licencia y problemas de cumplimiento, vulnerabilidades de seguridad, VEX (Intercambio de Explotabilidad de Vulnerabilidades), la integridad de los archivos y potencialmente identificar componentes de «alto riesgo», como software abandonado (sin actualizar en dos años o más), paquetes vacíos (sin archivos fuente) y código binario nativo (código ejecutable no asociado normalmente con el tipo de paquete, que puede ser utilizado como vector de ataque). Como resultado de dicho análisis, podemos decidir qué componentes deben ser sancionados (en lista negra) y cuáles son aprobados (en lista blanca).
El uso de SBOM en nuestros procedimientos de gestión de riesgos de terceros y como un elemento subyacente del proceso SSDLC impulsa la transparencia entre la comunidad de desarrolladores, los fabricantes de software, los proveedores y los clientes. Nos coloca un paso por delante de las amenazas de día cero y los ataques a la cadena de suministro, mientras que al mismo tiempo nos ayuda a entregar software de mejor calidad y más sostenible.
Otras consideraciones importantes
En el proceso de asegurar nuestros productos contra ataques a la cadena de suministro, la implementación de políticas SSDLC y procedimientos de Gestión de Riesgos de Terceros por sí solos no serán suficientes sin la designación formal de Propietarios de Productos (POs). Ya sea que la propiedad recaiga a nivel de producto agregado o de componente, es esencial que alguien dentro de la organización se haga responsable de la gestión del ciclo de vida seguro de extremo a extremo del producto y sus componentes.
Además, se debe mantener un inventario actualizado de todos los productos y componentes subyacentes, con una categorización de riesgo designada (por ejemplo, alto, medio, bajo riesgo). Inventariar lo que tenemos, y especialmente lo que aprobamos o no aprobamos, es esencial para obtener visibilidad sobre el panorama de riesgos de nuestro producto, su complejidad y el impacto en el negocio si algo sale mal.
Finalmente, como dice el refrán: «Confía, pero verifica». Un proceso nunca puede etiquetarse como efectivo si no realizamos una revisión independiente para verificar que funciona como se espera y que los riesgos están identificados y controlados. Como mínimo, los productos de alto riesgo deben auditarse en función de las prácticas esperadas del ciclo de vida de desarrollo seguro y debe prestarse atención a su composición y dependencias de terceros.
Entender lo que hay debajo de la superficie
Aprender a tratar la seguridad como un elemento clave en el diseño, la construcción y la implementación de nuestros productos de software es un viaje que requiere conciencia y compromiso, pero comprender el impacto que tienen los componentes de terceros en lograr el nivel deseado de seguridad del producto es un paso más que no todos están preparados para dar. Si realmente te importa la calidad de los productos que estás ofreciendo, entonces verifica y cuestiona lo que hay debajo de la superficie, las relaciones y dependencias en múltiples niveles. Al final, el producto final siempre será la agregación de todos sus componentes, formas de trabajo, verificaciones y procedimientos involucrados durante su ciclo de vida, y solo podremos asegurar el producto una vez que logremos una visibilidad completa de las debilidades y oportunidades de mejora en todas estas partes.