La cadena de suministro global de software siempre está bajo amenaza de ciberdelincuentes que amenazan con robar información confidencial o propiedad intelectual y comprometer la integridad del sistema. Estos problemas pueden afectar a las empresas comerciales, así como a la capacidad del gobierno para prestar servicios al público de forma segura y confiable.
La Oficina de Gestión y Presupuesto de los Estados Unidos (OMB) publicó en julio de 2022 un memorando sobre el asunto, que cubrimos aquí en detalle. En septiembre de 2022, se publicó un nuevo memorando, esta vez centrado en la seguridad e integridad de la cadena de suministro de software, subrayando el importante papel de los SBOM. Presenta una lista de requisitos precisos y, por primera vez, comparte un cronograma vinculante real para implementar cambios.
El memorando contiene dos puntos principales relacionados con la Orden Ejecutiva (EO) 14028, Mejora de la ciberseguridad de la nación:
- La EO ordena al Instituto Nacional de Estándares y Tecnología (NIST) que comparta orientación para desarrollar prácticas destinadas a aumentar la seguridad de la cadena de suministro de software. Para ayudar a lograr esto, NIST publicó dos documentos: el Marco de desarrollo de software seguro (SSDF), ESP 800-218y Guía de seguridad de la cadena de suministro de software. En conjunto, se denominan Guía NIST y describen un conjunto de prácticas que constituyen la base para la creación de software seguro.
- La EO también ordena a la Oficina de Gestión y Presupuesto que comience a exigir a las agencias que se ajusten a la Guía del NIST y cualquier otra actualización.
La autocertificación es un requisito previo, pero ¿lo es todo?
Los productores de software ahora están obligados a proporcionar a las agencias una autocertificación antes de comenzar a utilizar su software. En realidad, existen tres categorías que requieren autocertificación: compras de software nuevo, actualizaciones de versiones importantes y renovaciones de software. El objetivo es equipar a las agencias con productos de software seguros y resistentes que las protejan contra amenazas como las que Vientos solares experimentado, que comprometió a varias agencias.
Empecemos por lo básico: ¿Qué es exactamente la autocertificación?
La autocertificación es un documento que funciona como una declaración de conformidad y que certifica que el productor de software cumple con las prácticas de las Directrices del NIST. La idea es que las agencias obtengan una autocertificación para cada producto o servicio de software de terceros que cumpla con los requisitos del memorando. Esto incluye renovaciones de software y actualizaciones de versiones importantes.
Otro punto importante del memorando es que las agencias alienten a las empresas de software a incluir productos. Esto les permitiría proporcionar la misma certificación a todas las agencias de compras.
La agencia puede conservar el documento de autocertificación a menos que la empresa de software lo publique públicamente y ofrezca un enlace a la publicación dentro de su propuesta.
Nota: Si bien todos los demás memorandos o directrices hasta la fecha afirman que la autocertificación es suficiente para empezar, éste establece la confianza y la transparencia como objetivos clave. Se centra específicamente en la cadena de suministro de software, no solo en la ciberseguridad o el SSDF (incluso si son parte de ella).
¿Qué sucede si la empresa de software no puede proporcionar una autocertificación en el formato estándar?
Es posible que un productor de software no pueda dar fe de una o más prácticas de la Guía del NIST identificadas en el formulario de autocertificación estándar. En este caso, la agencia que solicita el software exigirá a la empresa:
- Identificar aquellas prácticas de las que no pueden dar fe
- Documentar todas las prácticas en uso para mitigar esos riesgos.
- Desarrollar un plan de acción e hitos (POA&M)
Naturalmente, la agencia debe asegurarse de que la documentación no se publique públicamente (ni por parte del proveedor ni por la propia agencia).
Supongamos que el proveedor proporciona toda la documentación y es satisfactoria para la agencia. En este caso, este último podrá utilizar los productos o servicios de software a pesar de que el productor no haya realizado una declaración completa.
¿Qué debe incluir una autocertificación aceptable?
Un documento de autocertificación debe incluir los siguientes requisitos mínimos:
- El nombre de la empresa de software.
- Una descripción de los productos de software a los que se refiere la declaración (idealmente, este punto describe la empresa de software o el nivel de línea de productos, incluidos todos los productos no clasificados ofrecidos a las agencias)
- Una declaración que confirme que el proveedor opera de acuerdo con prácticas y tareas de desarrollo seguras (detalladas en el formulario de autocertificación)
Este tipo de autocertificación es el nivel mínimo requerido. Aún así, si las agencias desean adquirir software sin él (por ejemplo, debido a su criticidad), pueden llevar a cabo determinaciones basadas en riesgos con la ayuda de una evaluación de terceros (definida en M-21-30).
Aún así, la directiva alienta a las agencias a utilizar un formulario estándar de autocertificación. El Consejo Federal de Regulación de Adquisiciones (FAR) propondrá normas sobre el uso de dicho formulario de autocertificación estándar y uniforme.
Autocertificación para software de código abierto
Supongamos que la agencia desea adquirir software de código abierto o un producto de software que incluya componentes de código abierto. En ese caso, puede recurrir a una evaluación de terceros proporcionada por una organización evaluadora de terceros certificada por FedRAMP (3PAO) o una aprobada por la propia agencia.
Dicha evaluación es aceptable en lugar de la autocertificación del proveedor, siempre y cuando la 3PAO utilice la Guía del NIST como base.
Los SBOM se están convirtiendo en un estándar de la industria. ¿Estás listo para ello?
Si bien la autocertificación es el nivel mínimo requerido, es posible que las agencias no la necesiten si el producto o servicio que buscan obtener es fundamental y no pueden proporcionar una autocertificación en un formulario estándar.
Lo importante es que el memorándum alienta a las agencias a obtener artefactos de proveedores que demuestren su conformidad con las prácticas seguras de desarrollo de software. Una de esas prácticas incluye tener un SBOM.
¿Qué es un SBOM y cómo funciona?
SBOM se refiere a una Lista de materiales de software, un inventario de todos los componentes y dependencias que forman parte del desarrollo y entrega de un producto de software.
Una agencia puede requerir una SBOM como parte de los requisitos de la licitación, dependiendo de la importancia del software para la agencia.
El memorando incluye las siguientes directrices para la adquisición y el uso de SBOM por parte de las agencias:
- La agencia puede conservar el SBOM a menos que el productor de software lo publique y comparta un enlace con la agencia.
- Los SBOM deben generarse utilizando uno de los formatos de datos definidos en el informe de la NTIA “Los elementos mínimos para una lista de materiales de software (SBOM)” o una guía sucesora publicada por la Agencia de Seguridad Cibernética e Infraestructura.
- Al considerar los SBOM, las agencias deben tener en cuenta la reciprocidad de los SBOM y otros artefactos de los productores de software mantenidos por otras agencias. Esto se basa en la aplicabilidad y vigencia directa del artefacto.
- La agencia puede requerir artefactos distintos de SBOM si es necesario, por ejemplo, aquellos relacionados con herramientas y procesos automatizados para validar la integridad del código fuente o realizar comprobaciones de vulnerabilidades.
- La agencia también puede exigir que la empresa de software muestre pruebas de que participa en un Programa de divulgación de vulnerabilidades.
El memorando también sugiere que las agencias informen a los proveedores sobre estos requisitos lo antes posible en el proceso de adquisición. Para cumplir con la Orden y la guía del NIST, las agencias deben planificar adecuadamente e incluir todos los requisitos en su proceso de evaluación de software. Tenga en cuenta que esto también debe estar en línea con el cronograma especificado en el memorando (esto se tratará en la siguiente sección).
Las agencias deben especificar los requisitos en la Solicitud de Propuesta (RFP) o en otros documentos de licitación. La idea aquí es que la agencia se asegure de que el proveedor implemente y utilice prácticas seguras de desarrollo de software en línea con la orientación del NIST durante todo el ciclo de vida del desarrollo de software.
SBOM es claramente una de las mejores prácticas de la industria en el camino hacia un uso generalizado, particularmente para mitigar riesgos de la cadena de suministro de software.
Para ayudar a las empresas a generar confianza en sus productos de software, recientemente lanzamos una plataforma fácil de usar que ayuda a generar SBOM y compartirlos dentro y entre organizaciones. Darle una oportunidad de forma gratuita para ver lo fácil que puede ser generar, gestionar y compartir SBOM.
Ya no es sólo una recomendación; ahora hay un cronograma obligatorio a seguir
Las agencias deben cumplir con los requisitos del memorando de acuerdo con este cronograma:
- Las agencias tienen 90 días hacer un inventario de todo su software de terceros, incluido un inventario separado para el "software crítico".
- En un radio de 120 días, necesitan crear "un proceso consistente para comunicar los requisitos relevantes en este memorando a los proveedores y garantizar que las cartas de certificación no publicadas públicamente por los proveedores de software se recopilen en un sistema de agencia central".
- También tienen 270 días para recopilar cartas de certificación que no se hayan publicado públicamente para "software crítico". En el plazo de un año, las agencias deberían haber recopilado las cartas de todo el software de terceros.
- Finalmente, dentro 180 días de la fecha del memorando (14 de septiembre de 2022), los CIO de la agencia deben haber evaluado las necesidades de capacitación y desarrollar planes de capacitación para revisar y validar los documentos y artefactos de certificación.
Las agencias pueden solicitar una extensión al menos 30 días antes de cualquier fecha límite relevante establecida en el memorando, junto con un plan para cumplir con los requisitos pendientes. También es posible solicitar una exención, pero sólo en circunstancias excepcionales y por un período de tiempo limitado.
Resum
La OMB compartirá instrucciones específicas para presentar solicitudes de exenciones o extensiones dentro de los 90 días a partir de la fecha del memorando (hasta mediados de diciembre de 2022). Además, en consulta con CISA y la Administración de Servicios Generales, determinará los requisitos para un “repositorio centralizado de certificaciones y artefactos de software” con los mecanismos adecuados para la protección y el intercambio entre agencias.
Un lugar central de este tipo podría convertirse algún día en una ubicación central para una variedad de pruebas y certificaciones de seguridad más allá del formulario de autocertificación o SBOM. Colocar toda la evidencia en un lugar único y compartible ayuda a las organizaciones a lidiar con problemas compartidos, como nuevos exploits emergentes o CVE.
De esto es exactamente de lo que se trata Scribe. Echa un vistazo a esta página para obtener más información sobre nuestra plataforma integral para generar, administrar y compartir SBOM dentro y entre organizaciones.
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
