Esta es el primer blog de una serie de tres artículos sobre el papel de la identidad en CMMC 2.0.
En resumen: Una pregunta fundamental que sustenta toda política de acceso: ¿Eres realmente quien dices ser?
Esta publicación profundiza en la familia de controles de identificación y autenticación (IA). Demostraremos por qué una verificación de identidad sólida es un requisito indispensable para un control de acceso más seguro y mostraremos cómo Okta le ayuda a cumplir con estos requisitos en cada nivel de madurez de CMMC 2.0.
Descripción general: la autenticación es la base del control de acceso.
La familia de controles de identificación y autenticación (IA) es el guardián digital de su organización. Su propósito es garantizar que cada usuario, dispositivo o proceso sea legítimo y esté verificado antes de que pueda siquiera intentar acceder a un recurso. Sus políticas de control de acceso (AC) cuidadosamente elaboradas carecen de sentido si cuestiona la certeza de la identidad de quien realiza la solicitud.
Por eso, la metodología de puntuación CMMC 2.0 hace tanto hincapié en los controles de IA. Un auditor debe tener certeza y pruebas de la identidad antes de poder confiar en las medidas de seguridad que ha implementado.
Con Okta, las organizaciones pueden abordar de inmediato una parte importante de estos requisitos de alto valor. Dentro de la familia IA, Okta te ayuda a cumplir con tres controles que valen 5 puntos— los “elementos clave” que son esenciales para aprobar tu auditoría.
Analicemos un control de seguridad de la información clave en cada nivel de CMMC.
CMMC nivel 1: la capa fundamental
El nivel 1 se centra en la "higiene cibernética básica" y es obligatorio para los proveedores de servicios que manejan información de contratos federales (FCI, por sus siglas en inglés). Garantiza que tenga lo esencial a mano.
Control de nivel 1 clave: IA.L1-3.5.1
Requisito CMMC | Control correlacionado NIST SP 800-53 |
|---|---|
IA.L1-3.5.1: Identificar y autenticar a los usuarios, procesos o dispositivos del sistema de información. | IA-2: Identificación y autenticación (usuarios de la organización): El sistema de información identifica y autentica de forma unívoca a los usuarios de la organización (o a los procesos que actúan en nombre de los usuarios de la organización). |
Este control requiere que se asigne una identidad única a cada usuario y que se eliminen las cuentas compartidas.
Cómo Okta satisface el control:
El Okta Universal Directory y el inicio de sesión único (SSO) son las herramientas perfectas para cumplir con este requisito de CMMC. Okta actúa como la fuente de verdad central para todas las identidades de los usuarios, garantizando que cada persona tenga una única cuenta. Al federar tus aplicaciones con Okta SSO, ayudas a garantizar que se utilice una identidad única para cada inicio de sesión, lo que convierte las cuentas compartidas en cosa del pasado.
- Escenario real: Un pequeño proveedor de DIB inicia sesión en el portal de un proveedor de servicios principal para acceder a FCI, como los cronogramas de entrega. En lugar de utilizar una cuenta compartida shipping@supplier.com, la empresa utiliza Okta para proporcionar a cada empleado una cuenta de usuario única. Cuando un empleado accede al portal, se autentica con Okta utilizando sus credenciales personales, lo que garantiza que cada acción esté directamente vinculada a él, y cumple con la trazabilidad básica requerida para el nivel 1.
IA.L1-3.5.1 Recomendaciones de diseño:
Para implementar este control, configure Okta como su proveedor central de identidades conectándolo a una fuente de verdad, como su sistema de recursos humanos, o creando perfiles de usuario directamente en el Okta Universal Directory. Para cada una de sus aplicaciones, configure una integración de SSO mediante SAML u OIDC. Es fundamental asegurarse de que la aplicación esté configurada para permitir inicios de sesión únicamente a través de Okta, lo que impide que los usuarios creen cuentas locales separadas con un nombre de usuario y una contraseña. Esto impone el uso de una identidad única y gestionada para todos los accesos.
IA.L1-3.5.1 Evidencia de cumplimiento:
Para demostrar el cumplimiento ante un evaluador, deberá mostrarle su Okta Universal Directory para probar que cada empleado tiene un perfil de usuario único. A continuación, deberá acceder a la página de configuración de una aplicación clave (por ejemplo, Microsoft 365) y visualizar la configuración de SSO, observando que está federada con Okta. Finalmente, se consultaría el Okta System Log, se filtraría por el inicio de sesión reciente de un usuario específico y se mostraría el registro de eventos detallado, lo que demostraría que cada acción se puede rastrear hasta un actor.id único.
CMMC nivel 2: el guardián de la información controlada no clasificada (CUI Gatekeeper)
El nivel 2 está destinado a los proveedores de servicios que manejan información no clasificada controlada (CUI, por sus siglas en inglés), que es más sensible. Este nivel se ajusta a la norma NIST SP 800-171 y requiere una seguridad mucho más robusta.
Control clave de nivel 2: IA.L2-3.5.3
Requisito CMMC | Control correlacionado NIST SP 800-53 |
|---|---|
IA.L2-3.5.3: Utilice la autenticación multifactor para el acceso local y a la red. | IA-2(1): Acceso a la red a cuentas privilegiadas y no privilegiadas: El sistema de información implementa la autenticación multifactor para el acceso a la red a cuentas privilegiadas y no privilegiadas. |
Este control de seguridad de 5 puntos, conocido como "la piedra angular", exige que una contraseña por sí sola no sea suficiente. Debe implementar un segundo factor de verificación (MFA) para proteger contra el robo de contraseñas.
Cómo Okta satisface el control:
Okta Adaptive MFA es la herramienta perfecta para este requisito de CMMC. Como proveedor de identidad centralizado, Okta puede aplicar una autenticación multifactor (MFA) sólida para cada intento de acceso a cualquier aplicación que maneje información controlada no clasificada (CUI). Se pueden configurar políticas para que requieran la autenticación multifactor (MFA) para todos los usuarios y que estas se adapten en función del riesgo, por ejemplo, exigiendo un factor de autenticación más robusto cuando un usuario se conecta desde una red no segura.
- Escenario real: Un ingeniero aeroespacial que trabaja desde casa necesita acceder a una aplicación CAD basada en la nube que contiene información controlada no clasificada (CUI). Para iniciar sesión, primero deben introducir su contraseña. A continuación, Okta les pide que aprueben una notificación push en su teléfono inteligente registrado. Solo después de aprobar este segundo factor se les concede acceso a los archivos de diseño confidenciales. Un atacante que intentara obtener su contraseña mediante phishing se detendría en el desafío de autenticación multifactor (MFA).
IA.L2-3.5.3 Recomendaciones de diseño:
En la consola de administración de Okta, cree una política de "inscripción de autenticadores" que requiera que todos los usuarios se inscriban en al menos un factor de MFA. A continuación, cree una "Política de inicio de sesión" y aplíquela a todas las aplicaciones que manejan información controlada no clasificada (CUI). Configure las reglas dentro de esta política para "requerir autenticación multifactor" para cada inicio de sesión. Una buena práctica consiste en establecer la regla de que, si un usuario se encuentra en una red no confiable, siempre se le solicitará MFA. Para reforzar aún más la seguridad, requiera un factor resistente al phishing para todos los accesos a estas aplicaciones críticas.
Evidencia de cumplimiento IA.L2-3.5.3:
Para un evaluador, primero se mostraría la política de inicio de sesión que se creó, indicando la regla que aplica explícitamente la autenticación multifactor (MFA) en cada inicio de sesión en una aplicación que contenga información controlada no clasificada (CUI). A continuación, realizaría una demostración en vivo: intentaría iniciar sesión en esa aplicación como usuario de prueba y mostraría al evaluador la solicitud de autenticación multifactor (MFA) que aparece en un dispositivo registrado. Por último, muéstrales el evento de éxito de "Autenticación multifactor" correspondiente a ese usuario en el Okta System Log.
CMMC Nivel 3: la defensa experta
El nivel 3 está destinado a las Organizations que participan en los programas de máxima prioridad del Departamento de Guerra. Requiere todos los controles de nivel 2, además de los controles mejorados de NIST SP 800-172, para protegerse contra las amenazas persistentes avanzadas (APTs).
Control clave de nivel 3: IA.L3-3.5.4e
Requisito CMMC | Control correlacionado NIST SP 800-53 |
|---|---|
IA.L3-3.5.4e: Utilice la autenticación multifactor resistente al phishing para todos los accesos, tanto privilegiados como no privilegiados. | IA-2(8): resistente al phishing / resistente a la repetición: el sistema de información utiliza mecanismos de autenticación que son resistentes al phishing y a la repetición. |
Este control avanzado exige el uso de la autenticación multifactor (MFA) resistente al phishing para contrarrestar los ataques sofisticados que pueden eludir los tipos de MFA más débiles.
Cómo Okta satisface el control:
Okta cuenta con algunos de los autenticadores más resistentes al phishing del sector, herramientas que cumplen con este requisito de nivel experto de CMMC. Entre ellas se incluyen llaves de seguridad de hardware compatibles con FIDO2/WebAuthn, como YubiKeys, y soluciones sin contraseña como Okta FastPass, que aprovecha la biometría de la plataforma, como Windows Hello o Face ID/Touch ID de Apple. Las políticas de Okta se pueden configurar para que requieran exclusivamente estos factores resistentes al phishing para cualquier usuario que acceda al entorno CUI de alto valor.
- Escenario real: Un analista de ciberseguridad de una empresa de defensa de primer nivel gestiona sistemas que contienen información controlada no clasificada (CUI) altamente sensible. Para acceder a la consola de administración, deben autenticarse a través de Okta. Tras introducir su contraseña, se les solicita que toquen la YubiKey insertada en su estación de trabajo. La clave realiza un proceso criptográfico de desafío-respuesta exclusivo para cada usuario y el servicio de Okta, lo que demuestra su identidad con el máximo nivel de seguridad e imposibilita que un adversario sofisticado intercepte sus credenciales.
IA.L3-3.5.4e Recomendaciones de diseño:
En la política de "Inscripción de autenticadores" de Okta, asegúrese de que los autenticadores FIDO2/WebAuthn estén habilitados. A continuación, cree o edite su política de inicio de sesión para aplicaciones CUI. En lugar de un requisito general de autenticación multifactor (MFA), cree una regla que exija explícitamente un autenticador con "resistencia al phishing" como propiedad obligatoria. Esta norma obligará al uso de factores como YubiKey u Okta FastPass, aprovechando la biometría integrada del dispositivo, y no permitirá factores menos seguros como SMS o preguntas de seguridad para acceder a estas aplicaciones de alta sensibilidad.
IA.L3-3.5.4e Evidencia de cumplimiento:
Para demostrar esto a un evaluador, deberá mostrarle la regla de política de inicio de sesión que configuró y que requiere específicamente autenticadores resistentes al phishing. A continuación, realice una demostración de inicio de sesión en vivo. En primer lugar, intente iniciar sesión utilizando un factor que no sea resistente al phishing (como una notificación push) y demuestre que se le deniega el acceso. A continuación, repita el inicio de sesión utilizando una YubiKey o Okta FastPass con Windows Hello y verifique que el acceso se haya concedido correctamente. Esto proporciona una prueba irrefutable de la aplicación.
Continúa tu camino hacia la certificación CMMC sobre una base sólida.
Al combinar un control de acceso robusto con una identificación y autenticación resistentes, se crea una defensa formidable para la información controlada no clasificada (CUI) y una base sólida para la auditoría CMMC. Centralizar su estrategia en una plataforma de identidad moderna garantiza que las personas adecuadas y solo las personas adecuadas tengan acceso a los recursos adecuados.
No se pierda nuestra próxima publicación de esta serie, donde exploraremos el dominio de auditoría y responsabilidad (AU) para mostrarle cómo puede demostrar que sus controles de seguridad funcionan según lo previsto.
Para Más información sobre cómo Okta puede ayudar a su organización a cumplir con los requisitos de CMMC, descargue nuestra Guía de detección de CMMC en https://www.okta.com/resources/datasheet-okta-cmmc-discovery-guide/ o contáctenos en okta.com/contact-sales/.
Si bien este artículo trata ciertos conceptos legales, no constituye asesoramiento legal y no debe interpretarse como tal. Se proporciona únicamente con fines informativos. Para obtener asesoramiento legal sobre las necesidades de cumplimiento normativo de su organización, consulte el departamento legal de la organización. Okta no hace declaraciones ni ofrece garantías u otras seguridades con respecto al contenido de este artículo. Puede encontrar la información sobre las garantías contractuales de Okta a sus clientes en okta.com/agreements.
