Cómo un proveedor de identidad IL4 presta servicios con éxito a entornos IL5

Al adoptar la nube y los nuevos estándares, el Departamento de Defensa (DoD) puede mejorar sus sistemas de información y guiar la modernización de la ciberseguridad, como se requiere en el Pilar 1 de la Estrategia Nacional de Ciberseguridad, Sección 3 de la Orden Ejecutiva (EO) 14028, Mejora de la Ciberseguridad de la Nación, y la Sección 1 del Memorándum de Seguridad Nacional sobre Mejora de la Ciberseguridad de los Sistemas de Seguridad Nacional, del Departamento de Defensa y de la Comunidad de Inteligencia (NSM8). 

Sin embargo, el objetivo del Departamento de contar con una infraestructura moderna e inteligente sobre amenazas para el combatiente no se logra de forma aislada. La campaña para proteger los servicios en la nube es una responsabilidad compartida entre los propietarios de misiones del Departamento de Defensa (DoD) y los proveedores de servicios en la nube (CSP). La Guía de requisitos de seguridad en la nube (CC SRG) de la Agencia de Sistemas de Información de Defensa (DISA) documenta estas pautas y proporciona un marco para implementar servicios en la nube disponibles comercialmente.

Los niveles de impacto (IL) constituyen la base de este marco. Cada IL se alinea con un nivel específico de confidencialidad y riesgo de la información y con un subconjunto de los controles de seguridad de la instrucción 1253 del Comité de Sistemas de Seguridad Nacional (CNSSI). Estos IL también establecen los requisitos de conectividad, algunos de los cuales incluyen puntos de acceso a la nube (CAP). Los CAP proporcionan una conexión para que las soluciones en la nube se conecten a la NIPRNet a través de una pila de seguridad de la DISA o de servicio. La DISA creó un proceso de marco de gestión de riesgos (RMF) para la evaluación y autorización de las ofertas de servicios en la nube (CSO), diseñado específicamente para el Departamento de Defensa (DoD), y que existe en paralelo al Programa federal de gestión de riesgos y autorizaciones (FedRAMP).

Entender en qué nivel debe operar un CSO determinado es sencillo. Todo lo que necesita es entender la misión y los datos que está procesando. Aquí hay algunos ejemplos:
 

El recorrido de Okta en el DoD

Durante el año pasado, Okta trabajó arduamente con la DISA para extender nuestra oferta de identidad como servicio (IDaaS) al Departamento de Defensa (DoD) y a sus socios de misión en un entorno exclusivo, sin restricciones de aprobación de programas piloto. Pudimos completar esta iniciativa, que culminó en una nueva autorización provisional (PA) condicional para Okta for US Military. Parte de este hito implica el reconocimiento del funcionario de autorización (AO) de la DISA a IDaaS de Okta como un servicio de gestión de identidad y acceso para entornos IL5.

¿Cómo se puede usar un IDaaS IL4 para la gestión de acceso a un sistema IL5? Para responder a esa pregunta, necesitamos volver a los controles y a los datos.

Comencemos con los datos. IDaaS es una plataforma de gestión de identidades y accesos (IAM) basada en la nube que proporciona un punto de gestión central para acceder a otros sistemas y aplicaciones, pero no “procesa” datos en el sentido tradicional. ¿Qué tipo de datos querría almacenar en un directorio de usuarios? Sería difícil encontrar la necesidad de almacenar datos de seguridad nacional, información de identificación personal confidencial (SPII) o información médica protegida (PHI) como atributo de cuenta. Uno de los principios del modelo de Zero Trust es dar por sentado que el adversario ya tiene acceso a su entorno. Así, almacenar información protegida en una cuenta facilitaría el trabajo del actor. Si observamos IDaaS como una función habilitadora para un sistema general (o una familia de sistemas), es fácil ver que debemos evitar almacenar datos protegidos en un directorio. Por ejemplo, si necesita un identificador único para el personal, considere usar el identificador de personal de intercambio electrónico de datos (EDIPI) y no los números de Seguro Social (SSN).

El segundo factor es el modelo de herencia de controles. IDaaS proporciona controles heredables basados en su funcionalidad como parte de una arquitectura general del sistema. El plan de seguridad del sistema (SSP) de Okta y los controles heredables se convierten en una referencia invaluable para cualquier persona que diseñe un modelo de herencia. Dado que IDaaS no almacena ningún dato de CUI, la mayor parte de los controles adicionales bajo IL5 debe aprovecharse con los sistemas que almacenan los datos de CUI. Okta puede ayudar a cumplir con estos requisitos adicionales como parte de un enfoque híbrido. Con esto en mente, solo aquellos controles en los que Okta impacta directamente se marcan como heredables. Por ejemplo, Okta proporciona cifrado FIPS 140-2 a los datos almacenados en su propio almacén de datos, pero no a los datos en su sistema de mantenimiento de guerra.

El factor final son las inversiones adicionales de Okta en alojar el entorno en un dominio .mil (militar) y restringir su uso únicamente a las entidades aprobadas por el Departamento de Defensa (DoD), un paso importante en nuestro compromiso continuo con el DoD. Estos componentes arquitectónicos (datos, controles y exclusividad) son los factores lógicos que permitieron a la DISA otorgar a Okta para el Ejército de los Estados Unidos una PA condicional en IL4 y permitir el uso de IDaaS para entornos IL5. Esta situación única ejemplifica el futuro de Okta como líder en la migración a la nube del Departamento de Defensa y en las iniciativas de Zero Trust.

Para obtener más información sobre esta iniciativa y las aplicaciones IL5 con las que nos integramos, descargue nuestro documento técnico sobre Implementación de la identidad moderna para la seguridad nacional o comuníquese con nosotros a federal@okta.com.