NIST SP 800-218 (SSDF):

Visión general

El NIST SP 800-218 v1.1 (febrero de 2022) define el Marco de Desarrollo Seguro de Software (Secure Software Development Framework, SSDF): un conjunto de prácticas basadas en resultados, no una lista de verificación prescriptiva, organizado en cuatro grupos: Preparar la organización, Proteger el software ( Software), Crear software bien protegido ( Software) y Responder a las vulnerabilidades. La Orden Ejecutiva 14028 y los memorandos de la OMB resultantes establecieron el cumplimiento del SSDF como condición previa para vender software al Gobierno federal.

Los productores deben firmar el formulario de certificación alojado en la CISA, y el director general o una persona autorizada por él certifica, según su leal saber y entender, que se cumplen dichas prácticas. El marco no incluye ningún sistema formal de certificación por terceros, por lo que la demostración del cumplimiento se basa en pruebas internas y en la propia certificación, en lugar de en un certificado de auditoría, lo que traslada a la organización la responsabilidad de conservar pruebas que sean válidas en caso de que la certificación fuera cuestionada.

Por qué es importante

La declaración es una autocertificación, pero constituye una declaración formal con relevancia jurídica: se espera que el firmante conserve pruebas suficientes para defenderla en caso de que sea impugnada, y una declaración falsa conlleva la exposición a responsabilidades en virtud de la Ley de Reclamaciones Falsas, lo que supone un riesgo considerablemente mayor que el de un incumplimiento habitual de la normativa.

PS.2 y PS.3, que protegen el código contra la manipulación y proporcionan un mecanismo para verificar la integridad de las versiones, son dos de las prácticas que requieren más documentación, y se corresponden directamente con las capacidades de firma de código y de trazabilidad de la compilación que muchos productores de « software » aún no han formalizado. El SSDF se ha convertido también en el vocabulario de referencia que utilizan los compradores ajenos al ámbito gubernamental en los cuestionarios de seguridad de los proveedores, por lo que las deficiencias en este ámbito se hacen cada vez más evidentes tanto en los ciclos de ventas comerciales como en los federales.

Cómo se aplica esto a la criptografía 

La norma NIST SP 800-218 (SSDF) aborda la criptografía a través de varias áreas de control interrelacionadas. Las áreas clave con implicaciones criptográficas directas son:

Preparación para la auditoría

Las evaluaciones y los exámenes, ya sean realizados por la propia organización, llevados a cabo por un organismo regulador o revisados por un evaluador independiente, se centran en las pruebas demostradas y no únicamente en las declaraciones de política. Áreas clave que suelen analizar los examinadores y evaluadores:

• Paquete de pruebas de certificación: ¿Puede la organización presentar las pruebas en las que se basa su certificación CISA, y no solo el formulario firmado?
• Protección de las claves de firma de código: ¿Están las claves de firma de código protegidas contra posibles vulneraciones, con el acceso restringido únicamente a los sistemas de compilación y al personal autorizado?
• Mecanismo de verificación de la integridad de las versiones: ¿Existe algún mecanismo operativo, y no solo una declaración de política, que permita al consumidor verificar que una versión coincide con lo que publicó el productor?
• Recopilar pruebas sobre el control de acceso al proceso de compilación: ¿Está restringido el acceso a la infraestructura de código fuente, compilación y lanzamiento, y se registra de forma que respalde la certificación PS.2?
• SBOM y firma de procedencia: ¿Se firman las listas de materiales ( Software ) y los certificados de procedencia, lo que permite una rápida verificación cuando se da a conocer una vulnerabilidad en un componente?
• Fundamentación de la declaración del consejero delegado o de la persona designada: ¿Respaldarían realmente las pruebas que figuran en el expediente dicha declaración si fuera objeto de impugnación, en lugar de darse por sentado que son suficientes?

LLEVA ESTO A LA DIRECCIÓN

Nuestro director general o una persona autorizada en su nombre firma personalmente un documento con validez jurídica cuando presentamos la declaración de la CISA, y esa firma solo es defendible en la medida en que lo sean las pruebas que la respaldan. Los puntos PS.2 y PS.3, que protegen nuestro código y demuestran la integridad de las versiones, son precisamente las prácticas para las que se crearon la firma de código y la gestión de claves; por lo tanto, no se trata de una nueva capacidad que haya que desarrollar, sino de pruebas que quizá ya tengamos casi todas, si somos capaces de presentarlas.

Esto ha dejado de ser un requisito exclusivo del sector público. Los compradores del sector privado, especialmente en los ámbitos financiero y sanitario, ya incluyen preguntas sobre la conformidad con el SSDF en los cuestionarios para proveedores, lo que significa que cualquier deficiencia en este ámbito nos supone una pérdida en ciclos de venta que no consideramos en absoluto relacionados con el ámbito federal. Aclarar nuestra estrategia en materia de firma de código y procedencia nos permite dar respuesta a ambos públicos.