En septiembre de 2022, la Oficina de Gestión y Presupuesto de los Estados Unidos (OMB) emitió un nota histórica con respecto a los pasos necesarios para asegurar su cadena de suministro de software en un grado aceptable por el gobierno federal de EE. UU. Cualquier empresa que desee hacer negocios con el gobierno y cualquier agencia federal que produzca software debe cumplir con los requisitos y el cronograma establecidos en el Nota M-22-18.
M-22-18 se centró en la seguridad e integridad de la cadena de suministro de software, prestando especial atención al papel de SBOM. Incluía una lista de requisitos y un cronograma para implementar los pasos necesarios para el cumplimiento.
El memorando estableció dos documentos principales elaborados por el NIST: el marco de desarrollo de software seguro (SSDF), ESP 800-218y Guía de seguridad de la cadena de suministro de software como guía del NIST sobre el desarrollo de software seguro. El memorando también describe la responsabilidad de los productores de software de dar fe de su cumplimiento de las directrices del NIST antes de que las agencias federales puedan utilizar sus productos. Esta autocertificación deberá adoptar la forma de una “forma común” de autocertificación firmada. Tres categorías de software requieren este formulario de autocertificación: compras de software nuevo, actualizaciones de versiones importantes y renovaciones de software.
M-22-18 requirió que CISA estableciera este “formulario común” estándar de autocertificación dentro de los 120 días a partir de la fecha de ese memorando (14 de septiembre de 2022). Esos 120 días han pasado en enero de 2023 pero el formulario aún está en formulario de borrador a pesar de que el período de comentarios cerró el 26 de junio de 2023. Fue entonces aproximadamente cuando el Memorándum de la OMB ordenó originalmente a las agencias que comenzaran a recopilar certificaciones para software crítico.
Con base en algunos de los comentarios recibidos para ese formulario de certificación común, la OMB consideró oportuno publicar una enmienda al M-22-18 el 9 de junio de 2023. Esta enmienda se titula M-23-16. El nuevo memorando amplía el cronograma publicado el M-22-18 para que las agencias recopilen certificaciones de los productores de software. Las agencias ahora están obligadas a recopilar la autocertificación “forma común” de los productores de software para software “crítico” a más tardar tres meses después de que la OMB apruebe el formulario de autocertificación común CISA. Todos los demás productores de software tienen seis meses después de que la OMB apruebe el formulario de autocertificación.
Desde esto Aunque el formulario estándar de autocertificación parece estar tomando protagonismo, examinemos con un poco más de detalle lo que contiene. También veremos quién debe firmarlo exactamente y qué significaría dicha firma.
Formulario común de autocertificación de software seguro
Siguiendo la cadena de regulación desde la EO 14028 hasta los documentos de orientación del NIST y los memorandos de la OMB, está claro que el gobierno pretende proteger a todos, tanto las agencias federales como las empresas del sector privado, de vulnerabilidades de la cadena de suministro de software e intrusiones. Dado que el sector privado no ha hecho lo suficiente al respecto (en opinión del gobierno), el gobierno se ha propuesto crear nuevas regulaciones que todos (que venden al gobierno federal) deben seguir.
Por supuesto, incluso si no vende al gobierno federal (todavía), le conviene seguir estas reglas y certificar que está "seguro", ya que dichas empresas serán un socio comercial más atractivo. ¿Quién querría hacer negocios con una empresa que no puede confirmar que está haciendo todo lo posible para proteger su producto y a sus usuarios?
Dado que ya establecimos que la guía del NIST es la base para la nueva regulación y mejores prácticas, no sorprende que las mismas sugerencias que aparecen, por ejemplo, en el SSDF aparecer también en el formulario de autocertificación.
Aquí hay un breve ejemplo del borrador del documento:
Tomado del borrador del formulario común de autocertificación de software seguro
Podemos ver el requisito a la izquierda seguido de la sección EO relacionada y luego de las prácticas y tareas del SSDF. Esta es una lista bastante completa de requisitos (una página y media) que no necesariamente quedará completamente clara si el lector no está en el negocio de la ciberseguridad y/o DevOps o DevSecOps.
El documento requiere que el firmante de la empresa dé fe PERSONALMENTE de que todos los requisitos descritos en el formulario se mantienen consistentemente y que la empresa notificará a las agencias afectadas si algún elemento de la lista ya no es válido.
El documento no especifica quién en la empresa debe firmar el documento, pero como este formulario es el requisito para que la empresa haga negocios con el gobierno federal y sus agencias, es lógico que el director ejecutivo sea la persona que debe asumir la responsabilidad. aquí. El CEO probablemente no lo firmará a ciegas y pedirá a su CTO y CISO que verifiquen (posiblemente por escrito) que la empresa sigue todas estas pautas y requisitos.
Dado que no existe un producto o modo de operación establecido para recopilar y dar fe de todos estos requisitos, en cierto sentido, cada empresa firmante necesita "reinventar la rueda" y esperar que no suceda nada malo.
Si sucede algo malo, entonces el gobierno federal perseguirá al firmante para demostrar que puede respaldar todos los requisitos de los formularios.
¿Qué pasa si no firmo?
En primer lugar, todo este asunto de la certificación actualmente solo es relevante si su software está siendo utilizado por una agencia federal, si tiene la intención de vender su software al gobierno federal o si su software está siendo utilizado por un proveedor cuyo software está en uso. o está destinado a ser vendido al gobierno federal.
Tenga en cuenta que dije "actualmente", ya que todo indica que el cumplimiento del SSDF, ya sea como una autocertificación o en alguna otra forma verificable, se convertirá en una nueva "mejor práctica" en el campo de la producción de software.
Entonces, suponiendo que su empresa esté dentro del grupo mencionado anteriormente y no encuentre la manera de firmar este documento con la conciencia tranquila, aún no está todo perdido. Siempre que pueda explicar dónde está la deficiencia de la certificación y ofrecer una respuesta satisfactoria. Plan de Acción e Hitos (POA&M) la agencia federal en cuestión aún puede comprar/usar su producto y solicitar una extensión para su software en su nombre ante la OMB.
La mala noticia es que, con o sin un plan POA&M, eventualmente necesitará proporcionar un formulario de certificación completo, lo que significa que debe poder verificar ante un tribunal federal que su empresa siguió todos los pasos requeridos en el formulario y que su El proceso de desarrollo de software es al menos tan seguro como los requisitos del formulario.
El único software que actualmente está exento de esta forma de certificación es el software desarrollado por agencias federales y el software disponible gratuitamente, también conocido como software de código abierto. Por supuesto, la mayoría seguridad de la cadena de suministro de software Los agujeros se pueden rastrear de alguna manera hasta algún paquete de código abierto en su código, pero existe un problema real al tratar de obligar a los desarrolladores y mantenedores de código abierto, que trabajan de forma gratuita, a proporcionar una garantía legalmente vinculante para su software. Debería corresponder a cualquiera que utilice software de código abierto verificar su seguridad, tanto en general como en lo que respecta al software en el que está integrado en particular.
El peor de los casos
Toda esta conciencia sobre la seguridad de la cadena de suministro de software comenzó después del famoso Vientos solares corte. Sin entrar en demasiados detalles, en el momento del ataque, más de 18,000 clientes de la empresa se vieron afectados, incluidas 9 agencias federales.
Sólo ahora, años después, estamos empezando a ver algunos de los resultados legales de este incidente. El segundo, Comisión de Valores de EE.UU, va tras la empresa en su conjunto, así como después de varios ejecutivos de nivel C. Esto puede verse como un ejemplo de las intenciones del gobierno en caso de que un incidente de este tipo o uno similar le ocurriera a un productor de software que dio fe de sus prácticas de desarrollo seguras y, sin embargo, fue víctima de un ataque.
En el caso de SolarWinds, la empresa respalda plenamente a cualquier empleado que sea objeto de dicha acción legal. Conociendo el sistema legal estadounidense, es probable que estos casos lleven años y cuesten mucho dinero. Las multas no están descartadas y podrían alcanzar sumas millonarias según una estimación del daños sufridos.
Puede imaginarse que no todas las empresas, especialmente las pequeñas y medianas, protegen tan firmemente a sus empleados como lo es SolarWinds. El problema es que si el acusado es el director ejecutivo de la empresa, existe una posibilidad real de que la confianza del mercado en la empresa y su producto se vea gravemente afectada. Enfrentarse a la SEC sin el respaldo de una gran empresa con mucho dinero podría arruinar a un director ejecutivo desprevenido y a su empresa. Por supuesto, la intención es lograr que la gente tome en serio su responsabilidad de asegurar el desarrollo, pero el miedo puede hacer que la gente se decante por el lado de la autopreservación. Eso significa que las personas preferirían ocultar los incidentes de seguridad cibernética si creen que no pueden ganar un posible caso ante la SEC o si les preocupa que el costo y la mala publicidad de dicho caso sean tan graves que sea mejor ocultarlos independientemente del resultado del caso judicial.
¿Cómo puedo firmar?
La guía SSDF del NIST está llena de sugerencias y mejores prácticas, pero tiene pocos aspectos prácticos. Dado que cada empresa es única, es bastante difícil presentar un producto o sistema que funcione para todos. En este caso, el sector privado está interviniendo para llenar el vacío, creando un ecosistema que le ayudará a cumplir con los requisitos.
Por ejemplo, Scribe construyó una plataforma basado en el concepto de crear atestados, firmarlos y ofrecer la posibilidad de verificarlos. Pronto publicaremos un documento hecho a la medida Formulario de autocertificación CISA, demostrando cómo la solución Scribe puede ayudarle en cada sección de los requisitos. Manténganse al tanto.
Probando La plataforma de Scribe es gratuita. Le animo a que lo pruebe y vea cómo puede adaptar la plataforma a sus requisitos y, al mismo tiempo, firmar el formulario de autocertificación de CISA con la conciencia tranquila.
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
