En abril de 2023, CISA publicó una nueva guía conjunta para la seguridad del software llamada Cambiando el equilibrio del riesgo de ciberseguridad: seguridad por diseño y principios predeterminados. La Guía se compuso con la cooperación de 9 agencias diferentes, incluida la NSA, el Centro Australiano de Seguridad Cibernética (ACSC) y la Oficina Federal de Seguridad de la Información (BSI) de Alemania, entre otras. El hecho de que múltiples agencias de todo el mundo hayan cooperado en la preparación de una guía de ciberseguridad debería ser un fuerte testimonio de la importancia que tiene el tema de la ciberseguridad en todo el mundo en este momento.
Jen Easterly, directora de CISA, compartió sus pensamientos sobre el tema de la ciberseguridad en un discurso reciente que pronunció ante los estudiantes y profesores de la Universidad Carnegie Mellon en Pittsburgh. Según el director de CISA, estos principios rectores deberían ayudar a guiar la industria mundial del software en los próximos años:
- La carga de la seguridad nunca debe recaer únicamente en el cliente. Los fabricantes de software deberían asumir la responsabilidad de sus productos y códigos.
- Los fabricantes de tecnología deberían adoptar una transparencia radical como compromiso de responsabilidad por sus productos.
- Los fabricantes de tecnología deberían centrarse en crear productos seguros, desarrollando productos que sean seguros por diseño y por defecto.
La guía CISA toma estos principios básicos y los amplía, incluyendo una lista completa de sugerencias prácticas que los fabricantes de software pueden seguir para llevar productos más seguros al mercado.
Es interesante notar que muchas de las sugerencias explícitas se basan en Marco SSDF del NIST pero redactado de una manera más práctica y menos voluntaria.
Una de las sugerencias de la guía, que se relaciona directamente con la transparencia radical, es que los fabricantes de software incluyan la producción de un SBOM en su SDLC para proporcionar visibilidad de los componentes de su software.
Pero, ¿es realmente suficiente crear un SBOM e incluso publicarlo? ¿Qué puede hacer realmente un productor o consumidor de software con un archivo SBOM JSON o XML?
En este artículo, analizaremos los usos que un SBOM puede brindarle a un productor de software hoy en día, la información que se puede agregar a un SBOM para enriquecerlo y la inteligencia de negocios que se puede obtener al examinar dichos documentos enriquecidos. Echaremos un vistazo rápido al aspecto de cumplimiento del uso de un SBOM y dónde reside su responsabilidad como productor de software, agregador de software o mantenedor de código abierto. Cerraremos hablando sobre la gestión de riesgos y cómo los principios de CISA de seguridad por diseño y seguridad por defecto se combinan con el cumplimiento normativo de ciberseguridad y una gestión de riesgos informada.
No todos los SBOM fueron creados iguales
Hay muchas herramientas disponibles hoy en día para la creación de SBOM, desde soluciones de código abierto hasta soluciones patentadas; una persona o empresa que desee incluir la creación de SBOM en su SOP podría hacerlo fácilmente. Se podría elegir entre los diferentes estándares de salud el que mejor se adapte a sus necesidades, pero aun así podría enfrentarse a demasiadas herramientas para tomar una decisión informada. Entonces, ¿qué más podrías buscar a la hora de decidirte por el producto adecuado? generación SBOM herramienta para ti?
Primero, verifique qué información se incluye u omite en la creación del SBOM. Una lista de materiales que incluya herramientas y códigos que formaron parte del proceso de desarrollo pero que no forman parte del producto real probablemente contendría mucha información redundante que es muy difícil de "limpiar" del archivo resultante para permitirle conservar sólo la información más relevante. Del mismo modo, las herramientas o el código que no se incluyen o se omiten intencionalmente faltarían notoriamente cuando se desee buscar vulnerabilidades, por ejemplo.
La lista de ingredientes y dependencias del software, en sí misma, carece de sentido. Tiene muy pocos propósitos más allá de lo que usted puede elegir hacer con él. El uso más frecuente de los SBOM en la actualidad es escanear los componentes del software para obtener una lista de vulnerabilidades que podrían afectar su producto.
Es importante recordar que alrededor del 95 % de las vulnerabilidades que descubre no son explotables en su producto. El truco consiste en encontrar ese 5% esquivo, elaborar un plan de trabajo y empezar a abordar estas vulnerabilidades explotables. ¿Cómo saber qué es explotable y qué no? Ésa es la gran pregunta que mantiene despiertos al personal de seguridad e ingeniería. Una sugerencia actual es emplear una solución llamada VEJAR – un intercambio de explotación de vulnerabilidades, una forma de aviso de seguridad cuyo objetivo es comunicar la explotabilidad de componentes con vulnerabilidades conocidas en el contexto del producto en el que se utilizan. Todavía deja gran parte del trabajo de examinar el pajar de información sobre vulnerabilidades y encontrar la aguja de las vulnerabilidades explotables, principalmente en manos del equipo de ingeniería. Después de todo, ¿quién conocería mejor su producto que las personas que lo codificaron?
Sin embargo, hay otras cosas que puede hacer, especialmente cuando se trata de vulnerabilidades heredadas que provienen de imágenes principales de su imagen acoplable o de dependencias muy atrás en su cadena de dependencia. Usando herramientas de código abierto como imagen parental puedes descubrir qué vulnerabilidades vienen con la imagen principal y cuáles fueron el resultado directo de tu código. Esto debería eliminar un grupo potencialmente grande de vulnerabilidades y facilitar el trabajo de selección. Usar varios avisos sobre diferentes vulnerabilidades también es una buena idea, ya que una vez que haya determinado que una vulnerabilidad no es explotable, tiene sentido informar a otros miembros de su equipo o a sus usuarios para que no siga comprobando la misma vulnerabilidad en cada versión. de su producto donde ni siquiera modificó el módulo donde se encontró. También es recomendable seguir sus dependencias de código abierto y de terceros para que una vez que encuentren y corrijan vulnerabilidades explotables pueda actualizar ese código en su producto para hacer Asegúrese de que también esté protegido de ese problema potencial en particular.
¿Qué más se puede agregar a un SBOM?
Como se indicó anteriormente, uno de los usos más comunes de los SBOM en la actualidad es como lista de verificación para el escaneo de vulnerabilidades. Utilizando varias bases de datos disponibles gratuitamente, como NVD (National Vulnerability Database), puede escanear una lista de componentes, similar a la proporcionada por un SBOM, y ver qué vulnerabilidades contiene. Una vez que tenga una lista de vulnerabilidades, puede ordenarla por gravedad, verificar si alguna tiene correcciones existentes, etc.
Otra capa de información que es útil tener sobre sus componentes es su licencia. Muchos componentes de código abierto vienen con una licencia que no es compatible con el uso comercial. Es importante asegurarse de que todos sus componentes de código abierto, incluso aquellos que no incluyó usted mismo pero sí fueron incluidos por algún otro componente, sean compatibles con lo que esté intentando hacer en términos de su licencia.
Una última sugerencia es seguir los medidores de "estado" de seguridad de código abierto para sus dependencias, como el Cuadro de mando OpenSSF. Tener una medida objetiva relativamente simple del estado de ciberseguridad de las bibliotecas de código abierto podría ser de gran ayuda para decidir qué bibliotecas incluir u omitir en su producto. Estas puntuaciones combinadas con la gravedad de las vulnerabilidades son una buena manera de ayudar a ordenar las vulnerabilidades en las que desea trabajar primero.
La gestión de riesgos como ejercicio de inteligencia empresarial
Existen múltiples los riesgos de seguridad para cualquier productor de software en estos días. Entre malware, criptomineros, ladrones de contraseñas y ransomware, es una maravilla que los fabricantes se sientan seguros al lanzar cualquier cosa al mercado. Nadie puede manejar todo a la vez, por lo que las empresas crean modelos de amenazas e intentan gestionar su riesgo de acuerdo con lo que consideran sus eslabones más débiles. El primer paso más sencillo es asegurarse de que su código y proceso de desarrollo cumplan con las regulaciones y mejores prácticas pertinentes. SSDF de Nist y OpenSSF SLSA son un buen punto de partida, así como los requisitos de EE. UU. para cosas como un SBOM. Seguir las regulaciones y las mejores prácticas podría al menos prometer una seguridad relativa frente a litigios bajo el Puerto seguro programa. Pero eso es sólo el comienzo.
La guía CISA anima a los fabricantes a abordar la construcción de sus productos teniendo en cuenta primero la seguridad. Cierta seguridad "adicional" una vez finalizado el producto no puede mitigar algunas debilidades fundamentales que forman parte de la arquitectura del producto. Según la guía, los productos seguros por diseño son aquellos en los que la seguridad de los clientes es un objetivo empresarial fundamental, no sólo una característica técnica. También se anima a los fabricantes a adoptar transparencia radical y responsabilidad. Eso significa, entre otras cosas, garantizar que los avisos de vulnerabilidad y la vulnerabilidad y exposición comunes asociadas (CVE) los registros son completos y precisos. También significa que se anima a compartir los componentes del código, sus dependencias y vulnerabilidades como una forma de mostrar a los usuarios y clientes que el fabricante es al menos consciente de los posibles problemas del producto.
De acuerdo con Wikipedia, Inteligencia de Negocio (BI) comprende las estrategias y tecnologías utilizadas por las empresas para el análisis de los datos y gestión de la información empresarial. Como puede imaginar, recopilar un SBOM para cada compilación, así como el informe de vulnerabilidad, la información de la licencia y los avisos que desglosan qué vulnerabilidades son y no explotables, es mucha información. La cantidad de puntos de información aumenta cuando se tiene en cuenta la vida útil de un producto de software típico y el hecho de que desea tener esta información para cualquier código o herramienta de terceros que esté utilizando, así como para los paquetes de código abierto que esté incluyendo. directa o transitoriamente. Para que todo tenga sentido de una manera que sea utilizable por los poderes de seguridad de la organización (probablemente el CISO y las personas bajo su mando), se necesita un sistema, una única plataforma de "panel de cristal". que le permite organizar toda esa información, buscarla de manera efectiva y presentarla en informes útiles cuando sea necesario. Para dar sólo un ejemplo de lo crítica que podría ser una plataforma de BI para una plataforma de ciberseguridad, imaginemos la Log4J drama del año pasado. ¿No sería fantástico buscar en todos sus productos, incluidas dependencias y herramientas de terceros, esta "nueva" amenaza con unas pocas teclas? ¿Qué tal si verificamos la presencia de un CVE nuevo y amenazante que acaba de aparecer? O preparar un informe sobre cómo el número total de vulnerabilidades de su empresa está disminuyendo progresivamente con el tiempo (o al menos no aumentando). Ese es el tipo de información útil de "panorama general" que sólo un sistema de BI sobre una plataforma de recopilación enriquecida con SBOM de ciberseguridad puede ofrecer.
Solo una vez que tenga toda la información relevante podrá evaluar realmente su riesgo, tanto en su código actual, en sus dependencias y al elegir incluir u omitir alguna herramienta o código de terceros de su producto. Cuando se ejecuta continuamente, también puede utilizar esta evaluación de riesgos para controlar las compilaciones y detener su producción o entrega si se descubre alguna actividad sospechosa.
Mirando hacia el futuro
La tecnología sigue avanzando todo el tiempo. Si alguna vez los proyectos de código monolítico ubicados en servidores ubicados en la oficina de la organización eran la norma, hoy en día la arquitectura de microservicios multinube y los LLM lideran el camino. Los SBOM deben seguir avanzando para poder admitir cualquier arquitectura o infraestructura compleja que utilice el software para mantener su relevancia y utilidad. CycloneDX de OWASP, por ejemplo, ya está trabajando para incluir Transparencia de aprendizaje automático en su formato SBOM. El mismo formato también garantiza incluir capacidades VEX y una API para compartir SBOM al planificar el futuro. Predigo que cada vez más plataformas como la creada por Escriba se creará para la acumulación y el intercambio de información relacionada con la seguridad, incluidos los SBOM, tanto por razones regulatorias como por el beneficio y el valor que dicha información enriquecida tiene para las organizaciones que la utilizan adecuadamente.
La plataforma de Scribe está a punto de lanzar una nueva herramienta de BI como parte de la plataforma de seguridad existente con todas las capacidades que sugerí y más. te animo a darle una oportunidad, vea la utilidad de dicha información acumulada a lo largo del tiempo y vea para qué puede utilizarla. Independientemente de si decide incorporar la plataforma Scribe en su SDLC o no, la carrera por un ecosistema más seguro y un SBOM más completo y útil está lejos de terminar. Es mejor subirse al carro de la transparencia ahora en lugar de que la regulación o la presión del mercado te impongan una transparencia radical.
Este contenido es presentado por Scribe Security, un proveedor líder de soluciones de seguridad de la cadena de suministro de software de extremo a extremo, que ofrece seguridad de última generación para artefactos de código y procesos de desarrollo y entrega de código en todas las cadenas de suministro de software. Más información.
Artículos relacionados con
