El 14 de septiembre de 2022, la Casa Blanca publicó el Memorándum M-22-18, que exige que los departamentos y agencias ejecutivas del gobierno de EE. UU. se aseguren de que todas las empresas que les proporcionan software y servicios estén suficientemente protegidas contra ataques cibernéticos.
“La Orden Ejecutiva 14028, Mejorar la ciberseguridad de la nación, fue lanzado en mayo de 2021”, dice Theresa Payton, miembro de la junta de asesores de Conceal y ex directora de información de la Casa Blanca. “El memorando más reciente de septiembre de 2022, M-22-18, garantiza que las agencias federales sigan la guía del Instituto Nacional de Estándares y Tecnología (NIST) resultante de EO 14028”.
La necesidad de seguridad en la cadena de suministro de software pasó a primer plano en diciembre de 2020, cuando decenas de agencias federales de EE. UU. se vieron comprometidas después de que se insertara un código malicioso en la plataforma de supervisión del rendimiento de TI Orion. Esto comenzó en septiembre de 2019, cuando actores del estado-nación sospechosos pero no confirmados violaron la seguridad de la empresa de desarrollo de software SolarWinds.
Cinco meses después, los atacantes insertaron un código malicioso, conocido como Sunburst, en Orion. El mes siguiente, Sunburst se implementó como parte de las actualizaciones periódicas de Orion, creando una puerta trasera en decenas de miles de organizaciones y departamentos gubernamentales, como el Departamento de Seguridad Nacional, que pudieron explotar.
El hackeo de SolarWinds demostró que incluso una sólida postura de seguridad puede verse comprometida por el eslabón más débil. Entonces, para protegerse contra futuros ataques a la cadena de suministro, la Casa Blanca ha dado el paso de ordenar que todos los proveedores de software del gobierno central y las agencias federales deben estar protegidos contra ataques cibernéticos.
Alcance y escala
Como tal, todos los desarrolladores y proveedores del gobierno de EE. UU. deberán asegurarse de que su arquitectura de software se adhiera a las normas del NIST. Marco de desarrollo de software seguro y Guía de seguridad de software en cadenas de suministro, así como guía anticipada de la Agencia de Seguridad de Infraestructura y Ciberseguridad (CISA).
El Memorándum M-22-18 y las órdenes ejecutivas asociadas se aplicarán a las empresas nuevas y existentes que proporcionen software al gobierno de EE. UU., independientemente de si el software se instala localmente o a través de la nube. En el caso de un proveedor que ya tiene un contrato con el gobierno de los EE. UU., estos requisitos de seguridad entrarán en vigencia una vez que se haya lanzado una actualización significativa para el software o el servicio que brinda.
Debido al uso a gran escala del software por parte del gobierno de los EE. UU. en todos sus departamentos y agencias, se espera que la orden ejecutiva se aplique a una proporción significativa de proveedores de software.
Una posible área gris es que el memorando establece que solo se aplicará al software utilizado en la prestación de servicios críticos. Sin embargo, el memorándum no define lo que se consideran “servicios críticos”. Por ejemplo, no está claro si un servicio crítico es algo que se relaciona con un departamento del gobierno o solo algo que es crítico para la función general del gobierno de los EE. UU.
Además, no está claro si se aplica solo al software que respaldará directamente los servicios críticos o si también se aplica al software utilizado para respaldar la entrega de servicios críticos.
“Será interesante ver dónde aterriza la definición de ‘software crítico’”, dice Paul Watts, un distinguido analista del Information Security Forum. “La orden alienta a CISA y NIST a trabajar juntos para acordar esta determinación”.
Auto-certificación
El núcleo del memorando es el requisito de que las empresas deberán realizar una autocertificación, lo que significa realizar una evaluación de riesgos, revisar sus políticas de seguridad y tomar medidas razonables para mitigar la amenaza de verse comprometida. Luego, las empresas deberán enviar un formulario de autocertificación, demostrando que cumplen con los requisitos mínimos de seguridad necesarios para ser un proveedor de software para el gobierno de los EE. UU.
Sin embargo, aún no se ha determinado la naturaleza exacta de los requisitos de seguridad detallados en estos formularios de autocertificación. “Sospechamos que una vez que CISA publique su formulario de autocertificación, surgirán más preguntas”, dice Curtis Yanko, arquitecto principal de soluciones de GrammaTech. “Anticiparíamos la conformidad de las pruebas de seguridad de las aplicaciones y proporcionaríamos una lista de materiales del software [SBOM] serán solicitudes típicas.”
Actualmente no está claro qué pasos se tomarían si los proveedores existentes no pueden proporcionar la autocertificación y cuáles serían las repercusiones para sus contratos con el gobierno de EE. UU.
Se espera que el SBOM, un inventario de todos los componentes constituyentes y las dependencias de software involucradas en el desarrollo de una aplicación, forme una parte significativa del proceso de autocertificación requerido. “La regla de la vieja escuela de tener un SBOM, que incluye mostrar un inventario de la compilación del código, es una buena práctica”, dice Payton. “Si desea una ventaja competitiva, asegúrese de que sus SBOM se entiendan fácilmente y se ‘crucen’ con los requisitos de las órdenes ejecutivas”.
El memorándum no diferencia entre proveedores extranjeros (Reino Unido, UE y el resto del mundo) y nacionales (EE. UU.); se espera que todos cumplan con los mismos requisitos. Los controles de exportación son, por lo tanto, un elemento clave que deberá tenerse en cuenta para cualquier organización fuera de los EE. UU. que desee proporcionar software. Esto es especialmente cierto si el software está diseñado para uso militar o si puede ser un software de uso dual.
Las empresas deberán verificar la legislación de control de exportaciones relevante antes de comprometerse con la autocertificación.
Otra posible preocupación será si el formulario de autocertificación obliga a las organizaciones a compartir información comercialmente confidencial.
“Mi principal área de preocupación será si alguno de los requisitos definidos coloca a los proveedores extranjeros en una posición en la que están obligados a compartir en exceso en un estado extranjero”, dice Watts. “Las empresas pueden verse obligadas a exponer niveles de detalle que comprometan su propiedad intelectual y/o derechos de patente”.
Responsabilidades del consumidor vs corporativas
Otro aspecto que aún no se cubre por completo es cómo las empresas pueden asegurarse de que su software se haya instalado de forma segura. Con demasiada frecuencia, las personas son el eslabón más débil de un sistema.
Considere, por ejemplo, cuando las personas conectan dispositivos IoT a una red con la configuración de fábrica, incluidas las contraseñas predeterminadas. Hay trampas similares con la instalación de software especializado, como herramientas de control de acceso y administración de red. Estos requieren personas con experiencia para llevar a cabo la instalación, para garantizar que la seguridad no se vea comprometida.
Este riesgo planteado por el aspecto humano podría mitigarse en cierta medida mediante instrucciones o reglas claras que exijan una instalación segura. Un ejemplo de esto podría ser exigir cambios de contraseña para software restringido, como exigir que las contraseñas tengan una longitud mínima, con símbolos y números, y bloquear las contraseñas más comunes. Los proveedores también pueden ofrecer un servicio de instalación como un paquete adicional, asegurando así que el software se habilite de forma adecuada y segura.
“Siempre existe la posibilidad de que los consumidores utilicen o configuren incorrectamente el software, de modo que la eficacia de la seguridad del software se vea comprometida”, dice Watts. “Espero que los requisitos dejen en claro las responsabilidades del proveedor frente a las responsabilidades del consumidor”.
Evolucionar la seguridad para hacer frente a las crecientes amenazas
A medida que surjan nuevas amenazas, se espera que los requisitos establecidos en el memorando y las órdenes ejecutivas asociadas se amplíen y evolucionen para contrarrestar nuevas vulnerabilidades. Se prevé que los requisitos se revisarán anualmente. Sin embargo, existe la preocupación de que esto no sea lo suficientemente frecuente, dado el rápido ritmo de las amenazas emergentes dentro de la esfera de la seguridad.
“Cabe señalar que la autocertificación se considera ‘Hacer lo mínimo para cumplir’”, dice Payton. “Anticipo que, con el tiempo, la autocertificación será uno de los muchos pasos para proporcionar software al gobierno de EE. UU.”
Dado el impacto generalizado que tendrá el Memorándum M-22-18, especialmente con el software y los servicios que se usan ampliamente, podría allanar el camino para un posible programa al estilo Energy Star para identificar productos que tienen un cierto nivel de seguridad incorporado. .
“Soy un fanático de la idea de crear un tipo de etiquetado Energy Star”, dice Watts. “Dado lo dinámicos y volátiles que pueden ser los ciclos de lanzamiento de software, será necesario que haya una referencia clara y concisa a las versiones exactas del software a las que se aplica la etiqueta, y cierta solidez en torno a la duración de la validez de dicha etiqueta”.
El Memorándum M-22-18 establece que la seguridad, que cumpla con requisitos mínimos específicos, ahora deberá ser demostrada por cualquier empresa que desee proporcionar software o servicios digitales al gobierno de los EE. UU.
El intercambio de detalles de seguridad confidenciales podría ser un obstáculo para los proveedores extranjeros, porque se requerirá cuidado para garantizar que se cumpla con la legislación de control de exportaciones. Del mismo modo, las empresas deberán asegurarse de no compartir información comercialmente confidencial.
Por supuesto, las empresas responsables ya contarán con sólidos procedimientos de seguridad y calidad para protegerse a sí mismas y a sus clientes. En este caso, se espera que sea necesario demostrar el cumplimiento relacionando los procedimientos existentes con los requisitos que se detallarán en los próximos documentos de orientación de CISA y NIST.