La cadena de suministro de software es un complejo ecosistema que conecta las fases de desarrollo, distribución y despliegue del software.
Debido a esta complejidad, se ha convertido en uno de los principales objetivos de los ciberataques. Como hemos visto en muchos casos, los actores maliciosos pueden aprovechar las vulnerabilidades en cualquier punto de la cadena para inyectar malware, robar datos confidenciales o interrumpir infraestructuras críticas.
Por ejemplo, el a?o pasado el proveedor de voz sobre IP (VoIP) 3CX reveló que una versión de su software 3CX Desktop se distribuyó a miles de clientes con códigos maliciosos. El infame ataque a SolarWinds es otro incidente en la cadena de suministro de software que dejó vulnerables durante meses a varios gobiernos estadounidenses.
Microsoft, por su parte, está siendo atacada por piratas informáticos que violan el código fuente de la empresa.
En respuesta a esta creciente amenaza, la Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA) presentó la semana pasada un nuevo formulario de certificación para proveedores de software.
El formulario obliga a los fabricantes de software que colaboran con el Gobierno Federal de EE.UU. a confirmar su adhesión a prácticas de desarrollo seguras.
No se trata de un mero requisito, sino de un movimiento estratégico para abordar de forma preventiva las posibles vulnerabilidades en la fase de desarrollo de los productos informáticos.
Sin embargo, la iniciativa ha suscitado reacciones encontradas en el sector: algunos la consideran un paso adelante necesario, mientras que otros expresan su preocupación por los posibles obstáculos.
Puntos clave
- Los ataques a la cadena de suministro de software son una amenaza de ciberseguridad cada vez mayor para las agencias del gobierno de EE.UU.
- La CISA ha introducido un formulario de atestación obligatorio que exige a los proveedores de software que venden al gobierno de EE.UU. que confirmen su adhesión a las directrices de desarrollo seguro.
- El formulario pretende aumentar la visibilidad de la postura de seguridad de los proveedores de software, impulsar la responsabilidad ejecutiva y estandarizar las evaluaciones de seguridad en todo el ecosistema del software.
- Entre los retos potenciales se encuentran la falta de madurez en materia de seguridad de algunos proveedores, la omisión en el formulario de determinadas prácticas clave y la necesidad de protecciones que vayan más allá del mero certificado.
- Los expertos recomiendan acciones como la separación de los entornos de producción y desarrollo, el uso de prácticas de codificación seguras, la activación de la AMF/encriptación, la supervisión continua y la adopción de una cultura general de seguridad del software.
- Aunque es un paso positivo, el formulario representa prácticas fundacionales: los proveedores deben mirar hacia dentro para identificar lagunas y fomentar una verdadera cultura de seguridad del software más allá de marcar casillas de cumplimiento.
Qué significa el formulario de declaración
El nuevo formulario de certificación exige que los fabricantes de software que venden a organismos federales de EE.UU. certifiquen que cumplen unos requisitos mínimos de desarrollo seguro basados en el Marco de Desarrollo Seguro de Software (SSDF) del NIST. Esta declaración es obligatoria para que el gobierno siga utilizando su software.
El requisito se aplica a una amplia gama de software desarrollado o modificado significativamente después del 14 de septiembre de 2022, incluyendo firmware, sistemas operativos, aplicaciones, software basado en la nube y otros servicios de aplicación.
Sin embargo, exime al software desarrollado por las agencias federales, al software de código abierto obtenido directamente por las agencias, a los componentes incorporados a los productos finales de software y al software obtenido libremente y disponible públicamente.
Según la CISA, el repositorio para la presentación en línea del formulario estará disponible a finales de este mes.
El formulario de atestación ofrece tres ventajas clave
En primer lugar, aumenta la transparencia y proporciona estructura en torno a la prueba de conformidad de los proveedores, afirma Javed Hasan, director general y cofundador de Lineaje.
“El formulario proporciona un enfoque estructurado para que los proveedores de software den fe de la seguridad de sus productos y cumplan la Orden Ejecutiva 14028 de EE.UU.”.
“Muestra la importancia que la CISA ha dado al uso de listas de materiales de software (SBOM) para garantizar una cadena de suministro de software más segura. También se alinea con las directrices del NIST y proporciona una autocertificación fiable que puede verificarse de forma independiente.”
La normalización es otro aspecto clave que llama la atención en el formulario de atestación. Tradicionalmente, las evaluaciones de seguridad se han realizado de forma ad hoc, empleando cada comprador su propio conjunto de criterios. Esta falta de uniformidad creaba confusión e ineficacia tanto para los proveedores como para los compradores.
El formulario de certificación CISA establece un lenguaje común para las evaluaciones de seguridad, lo que permite a los proveedores preparar una única certificación que puede presentarse a varios compradores. Esta normalización reduce la redundancia y agiliza el proceso de evaluación de la seguridad para todas las partes interesadas.
La tercera ventaja clave es que los directores generales tendrán que participar lo más activamente posible en garantizar la seguridad del software, en lugar de observar desde la distancia.
Al explicar esta novedad, Neatsun Ziv, cofundador y director general de OX Security, dijo a Techopedia:
“El papel del director general en este paradigma va más allá de la supervisión. Exige un compromiso activo con sus equipos para fomentar un entorno en el que la seguridad no sea una ocurrencia tardía, sino un elemento fundamental del desarrollo de software.
“Esto implica no sólo comprender, sino defender las prácticas establecidas por la CISA, desde garantizar entornos de desarrollo seguros hasta mantener controles estrictos sobre los componentes de software y su procedencia”.
Posibles obstáculos en el camino hacia la seguridad y la conformidad
Aunque los beneficios potenciales del formulario de certificación de la CISA son innegables, los expertos plantean dudas sobre su aplicación. Chris Hughes, asesor jefe de seguridad de Endor Labs y miembro de Innovación Cibernética de CISA, se?aló a Techopedia que el formulario representa algunas prácticas fundamentales de desarrollo seguro, pero faltan algunas piezas clave en el rompecabezas.
Se?aló que el mayor reto lo tienen los proveedores de software que no conocen bien las prácticas de desarrollo de software seguro ni los marcos de seguridad como el SSDF del NIST, el SAMM de OWASP o el BSIMM.
dijo Hughes:
“Los mayores retos para cumplir los requisitos serán para los proveedores que no hayan implantado prácticas de desarrollo de software seguro ni aprovechado marcos como el SSDF del NIST, el SAMM de OWASP o el BSIMM.
“Tendrán que evaluar sus prácticas de desarrollo actuales, identificar las deficiencias e implantar planes para rectificarlas.
” Esto, por supuesto, requiere tiempo y recursos, a los que las startups más peque?as y las organizaciones inmaduras tienen un acceso finito, sobre todo frente a las demandas que compiten por la velocidad de comercialización, los ingresos, el rendimiento para los inversores, la velocidad de las funciones, etc.
“Esto podría hacer que algunos proveedores abandonaran o evitaran el mercado federal debido al mayor nivel de madurez requerido y al acceso potencialmente limitado a soluciones de software comercial innovadoras para el gobierno federal”.
Otra preocupación importante, sugiere Hughes, es que el formulario haya pasado por alto algunas prácticas clave necesarias para impulsar una cadena de suministro de software segura.
“Parece que se han descuidado algunas prácticas clave, como la necesidad de modelar las amenazas para permitir sistemas seguros por dise?o. También carece de cualquier mención a la seguridad de la memoria, que irónicamente también ha sido un mensaje central de CISA en otras vías”.
Shawn Loveland, Director de Operaciones de Resecurity, también coincide con el argumento de las “piezas que faltan”.
“El formulario no cubre todas las ciberamenazas. Por ejemplo, no se abordan directamente las amenazas internas de personas de la organización con acceso a sistemas sensibles.
“Además, los ataques a la cadena de suministro que aprovechan vulnerabilidades en componentes de terceros requieren una atención aparte. Por último, las tecnologías emergentes, como la computación cuántica y la IA, presentan nuevos retos que pueden superar las prácticas de seguridad establecidas en el formulario.”
Cómo pueden cumplir el requisito los proveedores de software
Cada nueva normativa supone un obstáculo reglamentario para las empresas. Dado que está en juego la colaboración con el gobierno federal de EE.UU., las empresas tendrán que prepararse para cumplir los requisitos establecidos en el formulario de certificación.
Hablando con Techopedia sobre el camino a seguir por los proveedores de software, el Dr. Harry Wang, vicepresidente de Asociaciones Estratégicas de Sonar, recomienda que las organizaciones empiecen por tener distintos entornos para los desarrollos y los productos.
El Dr. Wang dijo
“Entornos de producción y desarrollo separados, mejor calidad del código, autenticación reforzada de múltiples factores, encriptación y, lo que es más importante, supervisión/pruebas continuas del código: todas estas son formas en que las empresas pueden garantizar una mejor seguridad en su software.”
Dado que el formulario de certificación describe claramente las prácticas de seguridad específicas que se evaluarán, Wang se?aló algunas buenas prácticas que, en su opinión, orientarían a los proveedores de software hacia estas prácticas seguras.
“Adoptando un entorno de producción más seguro, lenguajes de programación a prueba de memoria, principios de Código Limpio y un análisis continuo de la calidad del código para reducir la deuda tecnológica, los desarrolladores pueden evitar incidentes de seguridad, reducir la exposición al riesgo y mejorar la disponibilidad de sus aplicaciones.
“Esto es cada vez más importante, ya que esperamos que el volumen de código producido aumente con el uso y la innovación de los asistentes de código de IA“.
Para Loveland, mantener la seguridad del software es algo más que cumplir las exigencias de CISA mediante un formulario de atestación.
“Los fabricantes de software deben reconocer que se requiere algo más que el cumplimiento del formulario dado para proteger sus productos, infraestructuras y clientes de las ciberamenazas. Deben integrar este formulario en sus mejores prácticas para proteger sus sistemas contra ataques intencionados y no intencionados.”
Conclusión
El formulario de certificación de la CISA es un primer paso crucial para garantizar la seguridad de los procesos de desarrollo de software, así como para proteger a las Agencias Federales de EE.UU. de los ataques a la cadena de suministro.
Las estipulaciones del formulario incorporan prácticas esenciales para el desarrollo seguro de software que los proveedores que pretendan comercializar software para el Gobierno Federal deben estar preparados para cumplir si desean jugar en el ecosistema regulado federalmente.
Corresponde a los proveedores de software mirar hacia dentro, determinar cuáles son sus carencias en cuanto a buenas prácticas de seguridad e imbuirse de una cultura de seguridad que aumente sus posibilidades de cumplir los requisitos establecidos en el formulario.