¿Cómo puede ayudar el modelo Zero Trust en el marco de la CMMC y el cumplimiento del NIST 800-171?

¿Qué es CMMC (Cybersecurity Maturity Model Certification)?

El programa CMMC, Certificación del Modelo de Madurez de Ciberseguridad, fue promovido por el Departamento de Defensa de Estados Unidos para medir y verificar el nivel de implementación de procesos y prácticas en el área de ciberseguridad en sus proveedores.

El fin último del CMMC, a través de sus niveles de madurez (ver más abajo) es servir como mecanismo de verificación para que los proveedores de Defensa, de la Base Industrial de Defensa (DIB; Defense Industrial Base) implementen procesos y prácticas de ciberseguridad para proteger dos tipos de información:

• La Información No Clasificada Controlada (CUI; Confidential Unclassified Information), a la que hace referencia el NIST 800-171, es aquella que requiere protección o controles de difusión de conformidad con las leyes y políticas gubernamentales, pero que no está clasificada. En definitiva, es información sensible, relevante para los intereses de Estados Unidos, pero no estrictamente regulada por el Gobierno Federal.

El Gobierno de EEUU mantiene un Registro CUI con categorías y subcategorías de este tipo de información:

• La Información de Contratos Federales (FCI; Federal Contract Information) es información no pública, que es proporcionada o generada por el gobierno en relación con un contrato para desarrollar o entregar un producto o servicio al gobierno.

En la siguiente imagen se muestra la relación entre FCI, CUI e Información Pública:

A alto nivel, este modelo es una colección de procesos y prácticas de otros estándares y normativas como NIST, FAR, y DFARS entre otros. En el siguiente gráfico se muestra un resumen de la cobertura de CMM respecto a otras estándares incluyendo el NIST 800-171.

¿A quién aplica y por qué es importante?

Esta certificación aplica tanto a los contratistas principales (“prime Contractors”) del Departamento de Defensa como a los subcontratistas de estos. Entró en vigencia en Noviembre de 2020 y a partir del año 2026 se exigirá algún nivel de certificación para todos los contratos a partir del año 2026.

El coste del cibercrimen a nivel global supera el trillón de dólares, y ha crecido un 50% desde el año 2018, lo que constituye más del 1% del PIB generando unas pérdidas globales de 600 billones de dólares. El 75% de las de las pérdidas tienen que ver con el robo de propiedad intelectual y crimen financiero.

Se estima que el coste del cibercrimen siga creciendo, y según otros análisis, llegará a los $10.5 trillones de dólares anuales para 2025.

En Mayo de 2021 el presidente de Estados Unidos, Joe Biden, firmó una orden ejecutiva para mejorar la ciberseguridad estadounidense tras el ataque informático perpetrado contra el oleoducto Colonial, el más importante del país y que se vio obligado a cerrar para proteger los sistemas operativos. Esta orden ejecutiva supone el establecimiento de estándares de ciberseguridad de referencia para todo software que adquiera el Gobierno cara a mejorar la seguridad en toda la cadena de suministro. Entre otras cuestiones, la orden exige el despliegue del uso de cifrado por parte del Gobierno en un periodo de tiempo muy ajustado (6-9 meses).

Es por ello que CMMC y el cumplimiento de estándares de ciberseguridad irán cogiendo cada vez más peso en los próximos años para todos los proveedores del Gobierno de EEUU.

El modelo CMMC y sus 5 niveles

CMMC y su relación con NIST 800-171

Uno de los estándares en los que se basa CMMC es el 800-171 creado por NIST para ayudar a proteger fundamentalmente la Información No Clasificada Controlada (CUI) en organizaciones no federales o gubernamentales. El NIST 800-171 se desarrolló después del FISMA (Federal Information Security Management Act) que dio lugar a diferentes guías de seguridad y estándares.

Pasar una auditoría de CMMC no implica que una organización cumple o es “compliance” con NIST 800-171. CMMC sólo se centra en los controles relacionados con Información No Clasificada Controlada (CUI), pero el NIST 800-171, además de los 110 controles CUI, incluye 63 controles de tipo NFO (Non-Federal Organization).

A diferencia de NIST SP 800-171, el modelo CMMC consta de cinco niveles. El modelo es acumulativo por lo que cada nivel consta de prácticas y procesos, así como los especificados en los niveles inferiores. El modelo CMMC incluye prácticas de ciberseguridad adicionales además de los requisitos de seguridad especificados en NIST SP 800-171.

Además de evaluar la implementación de las prácticas de ciberseguridad de una empresa, el CMMC también evalúa los procesos de madurez de la empresa.

CMMC Nivel 3 incluye los 110 requisitos de seguridad especificados en NIST SP 800-171. El modelo CMMC también incorpora prácticas y procesos adicionales de otros estándares, referencias y / o fuentes como NIST SP 800-53, Aerospace Industries Association(AIA) National Aerospace Standard (NAS) 9933 «CriticalSecurity Controls for Effective Capability in Cyber Defense», y el Modelo de Gestión de Resiliencia (RMM) del Equipo de Respuesta a Emergencias Informáticas (CERT).

En la siguiente tabla se incluyen estándares o frameworks en los que se basa CMMC:

CMMC Componentes del CMMC: Dominios, Capacidades, Prácticas y Procesos

El modelo CMMC está organizado en procesos y buenas prácticas de seguridad dentro de un subconjunto de dominios. Los elementos del modelo son:

• 17 Dominios compuestos de Prácticas, organizadas a su vez en Capacidades.
• 43 Capacidades o colecciones de Prácticas de Ciberseguridad.
• 171 Prácticas de Ciberseguridad
• 5 Procesos que se evalúan para los Niveles de Madurez 1 a 5
• 5 Niveles de Certificación correspondientes a los 5 Niveles de Madurez.

Cada nivel tiene un conjunto de Procesos y Prácticas y un objetivo para cada uno de ellos en relación con los Dominios aplicables en ese nivel. Por ejemplo, lograr el nivel 3 significa que una organización ha logrado el objetivo de tener Procesos que estén Gestionados y Prácticas de un Buen Nivel de Ciberseguridad.

En la siguiente tabla se muestra un resumen de los Niveles en relación con la Madurez en el Proceso y las Prácticas:

En la siguiente figura se muestra para cada nivel las prácticas requeridas de NIST 800-171 y otros estándares y reglamentaciones:

En resumen, la relación de prácticas por Nivel es la siguiente:

En la siguiente gráfica se muestra la relación entre los dominios, y prácticas de cada dominio que hacen referencia a cada nivel.

Focos u Objetivo de los Procesos de Madurez en base al Tipo de Información

El modelo CMMC proporciona los medios para mejorar el alineamiento de las prácticas de ciberseguridad y los procesos de madurez con el tipo y sensibilidad de la información a proteger y los tipos de amenazas. Los niveles pueden ser también caracterizados en este sentido por su foco:

• Nivel 1: Salvaguardar Informacion de Contratos Federales (FCI).
• Nivel 2: Servir de paso de transición para proteger CUI.
• LNivel 3: Proteger Información No Clasificada Controlada (CUI).
• Nivel 4-5: Proteger CUI y reducir riesgos de Amenazas Persistentes Avanzadas (APTs; Advanced Persistent Threats).

El modelo Zero-Trust y CMMC

El modelo de seguridad Zero-Trust asume que un atacante está presente en la red de la organización y que un entorno o red propiedad de la organización no es diferente, o no es más confiable, que cualquiera que no sea propiedad de la organización.

El objetivo del modelo es evitar el acceso no autorizado a los datos haciendo que el control de acceso sea lo más granular posible. Es decir, los sujetos autorizados y aprobados (combinación de usuario, aplicación, servicio y dispositivo) pueden acceder a los datos con exclusión de todos los demás sujetos (es decir, atacantes).

Las agencias Federales del gobierno de EEUU han promovido que las organizaciones adopten un modelo de seguridad basado en los principios de Zero-Trust desde hace más de una década.

Se ha instado desde el Gobierno de EEUU a las agencias federales a pasar a un modelo de seguridad basada en principios Zero-Trust durante más de una década, desarrollando capacidades y políticas como por ejemplo la Ley Federal de Modernización de la Seguridad de la Información (FISMA).

Los principios del modelo Zero Trust son:

• Asegurar que los datos son accedidos de forma segura con independencia de su ubicación. Toda conexión a los datos es no confiable hasta que no se demuestre lo contrario, independientemente desde dónde se haga.
• Adoptar la estrategia del “modelo de acceso de menor privilegio” y forzar controles de acceso estrictos. Se debe dar acceso a una persona sólo los recursos que necesita para realizar su trabajo e impedir el acceso al resto.
• Inspeccionar y registrar todo. Se debe inspeccionar la actividad no sólo en el acceso a la red sino también en el interior, intentando identificar comportamientos anómalos.

Este es un modelo de seguridad centrado en los datos, donde la seguridad de los datos está en el corazón del mismo. Hay que tener en cuenta que el objetivo último de la seguridad no es proteger la red, ni no los sistemas, ni dispositivos, sino proteger lo más valioso que son los datos sensibles.

CMMC hace especial hincapié en que las organizaciones implementen procesos y prácticas de ciberseguridad para proteger dos tipos de información como se decía más arriba: Datos relativos Información No Clasificada Controlada (CUI) y datos relativos a Información de Contratos Federales (FCI; Federal Contract Information).

En el CMMC o NIST 800-171 no se habla explícitamente de Zero Trust, pero por ejemplo en la parte de Gestión de Configuración (CM; Configuration Management) se pide a las organizaciones que se utilice el principio de acceso de menor privilegio.

En julio de 2021, la Administración de EEUU publicó un memorando dirigido a crear nuevas prácticas de ciberseguridad para la infraestructura crítica, como el sector de la electricidad, el gas natural y el sector de agua. Estas nuevas prácticas se basarán en estándares del NIST, incluida la Publicación 800-207, «Arquitectura Zero Trust (ZTA)» y según algunas fuentes, se está trabajando en un memo sobre CMMC y la Arquitectura Zero Trust para el DIB (Defense Indutrial Base).

El enfoque de Seguridad Centrada en los Datos de SealPath en el contexto del CMMC

Un enfoque de seguridad centrada en los datos se basa en securizar el contenido más valioso de la organización de forma que pueda estar protegido frente a una posible salida no autorizada de la red, nube o frente a una fuga de datos.

Podemos conocer donde está la información sensible de la organización, y el nivel de clasificación, pero de poco valdrá, si no ponemos medidas para proteger esta información allí donde viaje.

SealPath, con un enfoque de seguridad centrada en los datos, permite que la documentación y ficheros de la organización viajen protegidos de forma persistente. La protección acompaña al documento a cualquier lugar y es posible controlar:

• Quién accede al documento (identidad).
• Con qué permisos como ver, editar, imprimir, etc. (nivel de acceso).
• Hasta cuándo (temporalidad del acceso).
• Desde qué subredes e IPs (lugar del acceso).

SealPath está alineado con una estrategia de seguridad basada en el modelo Zero Trust, de forma que se da acceso a los usuarios sólo a la información que necesitan, cuándo se necesita y con los permisos mínimos de acceso que requieren.

SealPath facilita la implantación de diferentes prácticas de seguridad de CMMC. A continuación, presentamos una tabla organizada por dominios, y capacidades en los que SealPath, con su enfoque de seguridad centrada en los datos, puede ayudar. También se indica el Nivel de CMMC a la que hace referencia la práctica en cuestión.

Es importante destacar que una solución de software por sí sola no permite el cumplimiento de un estándar como el NIST 800-171 o a conseguir el certificado de una auditoría de CMMC, sino que esto se consigue en base a la implantación de diferentes procesos, prácticas y herramientas.

En los siguientes apartados, organizados por dominios, se detalla en qué capacidades y prácticas puede ayudar la solución de seguridad centrada en los datos de SealPath al cumplimiento de estas.

Se incluye también una referencia al requisito de NIST 800-171 relacionado con la práctica. Se muestran únicamente aquellas prácticas donde SealPath puede ayudar a su cumplimiento (recuadradas en azul).

Aunque se muestra el detalle indicando cómo pueda ayudar SealPath, en la siguiente tabla se incluye un resumen del mapeo de prácticas, con su referencia al requisito NIST 800-171 donde puede ayudar SealPath.

Access Control (AC)

¿Cómo ayuda SealPath al cumplimiento de estas prácticas?

• AC.1.001 / AC.2.002 – SealPath puede limitar y controlar quién accede a ficheros sensibles. Sólo los usuarios autorizados pueden acceder y con los permisos asignados por el dueño del fichero (sólo ver, editar, imprimir, etc.).
• AC.2.005 – SealPath proporciona avisos de seguridad sobre los ficheros protegidos indicando la política de protección, descripción, marcas de agua dinámicas, etc.
• AC.2.006 – La información viaja protegida, independientemente si se encuentra en un dispositivo portátil o sistema de almacenamiento externo. Los accesos serán controlados y limitados igualmente dependiendo de los permisos asignados al usuario.
• AC.2.007 – Sólo se deja acceder a los usuarios a lo que deben acceder y no más. Se aplica en principio de menor privilegio que viene delimitado por la política de protección del fichero.
• AC.2.008 – No es necesario disponer de cuentas privilegiadas para acceder a la información sensible protegida. Además, ciertos usuarios pueden acceder a los datos sin que los propios usuarios administradores tengan acceso a los mismos.
• AC.2.009- SealPath dispone de política de máximo número de intentos con posibilidad de bloqueo a la información en caso de superar un número determinado.
• AC.2.016 – Todo el ciclo de vida de la CUI se controla en base a los permisos delimitados en la política, y sólo es posible acceder a la información si se dispone de la autorización correspondiente.
• AC.3.017 – SealPath permite una separación de deberes de forma que se diferencia entre administradores que puede acceder a la gestión de la infraestructura, de responsables de datos que controlan las políticas o usuarios que pueden acceder a la información sensible.
• AC.3.019 – Es posible bloquear las sesiones de acceso a la documentación en sensible forzando un reseteo de credenciales o simplemente eliminando a los usuarios de las políticas de acceso a la documentación o de la propia documentación en sí.
• AC.3.022 – La información permanece cifrada tanto en PCs, dispositivos móviles, plataformas de nube. El control de acceso a la información y la protección de ficheros viaja con los documentos.

AUDIT & ACCOUNTABILITY (AU)

¿Cómo ayuda SealPath al cumplimiento de estas prácticas?

• AU.2.041 – SealPath monitoriza el acceso a los documentos sensibles protegidos de forma que se pueda auditar quién accede, cuándo, desde qué IPs, y los permisos con los que accede.
• AU.2.042 – SealPath mantiene los logs de monitorización en una base de datos, pudiéndose retener el tiempo ampliando simplemente el espacio. Por otro lado, los logs pueden enviarse a un SIEM para poder mantenerlos también en este sistema.
• AU.2.043 – Los logs están sincronizados con la hora del reloj del sistema. Todas las entradas de log incluyen la fecha y hora.
• AU.2.044 – El administrador tiene acceso a los logs de monitorización de accesos a documentos protegidos que puede revisar y correlar con logs de otros sistemas.
• AU.3.045 / AU.3.046 – Tanto quien protege la información como el administrador pueden tener acceso a quién ha abierto un documento, fecha y hora, etc. También a alertas de intentos de acceso bloqueados, intentos de login fallidos, desprotecciones de documentos, etc.
• AU.3.049 / AU.3.50 – Sólo un usuario que ha protegido un documento, tiene acceso a la información de monitorización de ese documento. El administrador es la única persona que adicionalmente puede acceder a estos logs. Estos logs no son modificables y se almacenan en bbdd a la cual, en un despliegue on-premise, sólo el administrador de bbdd tiene acceso a los mismos.
• AU.3.051 – Los logs llevan timestamps y pueden ser correlados con eventos ocurridos en otros sistemas. Se puede diferenciar entre el tipo de alerta: Intento de acceso a un documento sin permisos, desprotecciones de documentos, invitaciones a usuarios, etc.
• AU.3.052 – Los eventos o logs son postprocesados y mostrados al administrador en forma de gráficas de resumen de actividad. Por otro lado, la información pueden enviarse a un SIEM para ser analizados de forma conjunta con otros eventos. Desde el SIEM es posible generar informes específicos y enviarlos a una o varias personas.

AWARENESS & TRAINING (AT)

¿Cómo ayuda SealPath al cumplimiento de estas prácticas?

• AT. 3.058 – Una de las partes fundamentales en el proceso de implantación de SealPath es hacer conscientes a los usuarios de la necesidad de proteger y gestionar de forma adecuada la información sensible de la organización. En este artículo se explican los pasos del despliegue donde uno de los fundamentales es el de “educar y comunicar”.

CONFIGURATION MANAGEMENT (CM)

¿Cómo ayuda SealPath al cumplimiento de estas prácticas?

• CM.2.062 – Siguiendo el modelo Zero Trust, SealPath se basa en la premisa de dar únicamente acceso a los usuarios a lo que necesitan y sólo a lo que necesitan.
• CM. 3.068 – Es posible restringir o revocar el uso a documentos protegidos incluso aunque ya se hayan compartido y estén fuera de la red de la organización.

ID & AUTHENTICATION (IA)

¿Cómo ayuda SealPath al cumplimiento de estas prácticas?

• IA.1.076 / IA.1.077 – SealPath consiste en una combinación de gestión de identidad (comprobando quién accede a la información), gestión de permisos (dejando sólo los permisos necesarios) y cifrado (en reposo, tránsito y uso). En todo momento se identifica al usuario que está accediendo o intenta acceder a la CUI.
• IA.2.078 / IA.2.079 / IA.2.080 / IA.2.081 / IA.2.082 – SealPath permite gestionar diferentes niveles de fuerza para las contraseñas, incluyendo captchas tras un primer intento erróneo, limitando el número permitido de accesos falidos o forzando el cambio de credenciales. Existe integración con AD para establecer este tipo de políticas y en caso de almacenarse en base de datos se almacenan cifrados.
• IA.3.083 / IA.3.084 – SealPath permite la utilización de autenticación multi-factor y empleo de mecanismos de autenticación avanzados, de forma integrada con AD Federation Services.
• IA.3.085 / IA.3.086 – Es posible bloquear o deshabilitar tanto temporalmente como de forma definitiva identificadores de usuario de forma que no puedan acceder a la documentación protegida. Por otro lado, existe la posibilidad de bloquear el acceso a a usuarios tras un periodo de inactividad de forma integrada con AD.

INCIDENT RESPONSE (IR)

¿Cómo ayuda SealPath al cumplimiento de estas prácticas?

• IR.2.093 / IR.3.098 – Se registran eventos de intentos de acceso bloqueados a ficheros, desprotecciones masivas de documentación, accesos a ficheros con un registro de fechas IPs, etc. Estos eventos están disponibles para quien protege la documentación y para el equipo de seguridad. También pueden reportarse eventos a través de un SIEM para que, dependiendo del nivel de alerta, se prioricen acciones de respuesta.

MAINTENANCE (MA)

¿Cómo ayuda SealPath al cumplimiento de estas prácticas?

• MA.3.115 – SealPath no destruye o elimina la información de equipos o dispositivos que se retiren. Sin embargo, la información permanece cifrada, con control de acceso pudiéndose revocar el acceso a la misma a determinadas IPs, usuarios, etc. Esta revocación supone una destrucción “virtual” de la información ya que ésta queda inaccesible esté donde esté.

MEDIA PROTECTION (MP)

¿Cómo ayuda SealPath al cumplimiento de estas prácticas?

• MP.1.118 – Como se ha descrito en el requisito MA.3.115, SealPath no destruye o elimina la información de tipo FCI o CUIde dispositivos que se retiren. Sin embargo, la información permanece cifrada, con control de acceso pudiéndose revocar el acceso a la misma a determinadas IPs, usuarios, etc. Esta revocación supone una destrucción “virtual” de la información ya que ésta queda inaccesible esté donde esté.
• MP.2.119 / MP.2.120 / MP.3.124 – La documentación en formato digital de tipo CUI, permanece protegida y bajo control en reposo, tránsito y uso. Se puede limitar quién accede, con qué permisos, hasta cuándo es posible acceder, etc. Esto se realiza de forma independientemente si está almacenada en un dispositivo removible como en un disco duro. También cuando estos dispositivos estén fuera de áreas físicas controladas por la organización.

PERSONNEL SECURITY (PS)

¿Cómo ayuda SealPath al cumplimiento de estas prácticas?

• PS.2.128 – Cuando una persona de la organización abandona la misma o pasa de un equipo a otro, es posible transferir los permisos que tiene sobre determinada información CUI a otras personas o simplemente restringirle el acceso. Este control se puede hacer también de forma sincronizada con AD de forma que cuando un usuario es deshabilitado o eliminado de AD pierde acceso a la documentación.

RECOVERY (RE)

¿Cómo ayuda SealPath al cumplimiento de estas prácticas?

• RE.2.138 – La información permanece protegida no sólo en los equipos de los usuarios o servidores de ficheros sino en las copias de seguridad o backup. El administrador puede elegir desproteger la documentación de los backups si lo considera necesario, pero se guarda un registro de auditoría de las acciones realizadas por el administrador.

RISK MANAGEMENT (RM)

¿Cómo ayuda SealPath al cumplimiento de estas prácticas?

• RM.2.141 / RM.2.143 – La información de auditoría y seguimiento de acciones sobre lo documentos, alertas, etc. permite analizar de forma periódica si se están siguiendo las políticas de seguridad marcadas por la organización o si es necesario realizar modificaciones a las políticas. Es posible remediar posibles deficiencias encontradas modificando políticas de seguridad, creando nuevas, etc. Dentro de los pasos de despliegue de una solución centrada en lo datos como SealPath, se recomienda “refinar y evolucionar” las políticas de seguridad tal y como se comenta en este artículo.

SECURITY ASSESSMENT (CA)

¿Cómo ayuda SealPath al cumplimiento de estas prácticas?

• CA.2.158 / CA.3.161 – Los controles de seguridad establecidos en SealPath pueden revisarse de forma periódica para determinar si están siendo efectivos o deben modificarse. Por otro lado, se puede realizar una monitorización de alertas de forma continua para verificar su efectividad o realizar modificaciones en base a las deficiencias o alertas detectadas.

SYSTEMS & COMMUNICATIONS PROTECTION (SC)

¿Cómo ayuda SealPath al cumplimiento de estas prácticas?

• SC.1.175 – SealPath permite proteger adjuntos o cuerpos de mensaje enviados dentro y fuera de la organización. También documentación que se intercambia con usuarios internos o externos por cualquier medio (sistemas de compartición Cloud, herramientas de colaboración, etc.). Esta documentación, emails y adjuntos puede ser monitorizada, y controlarse permisos de acceso y revocación además de viajar cifrada.
• SC.3.177 / SC.3.185 / SC.3.187 – SealPath emplea sistemas criptográficos validados por FIPS, incluyendo la posibilidad de gestionar las claves utilizando un HSM. La protección viaja cifrada y protegida en reposo, tránsito y uso para evitar que no pueden acceder personas no autorizadas.
• SC.3.181 – Se separan las funcionalidades de gestión de infraestructura y gestión de políticas por parte del administrador de las funcionalidades de usuario. Que un usuario tenga acceso a determinada información sensible no implica que un administrador tenga también acceso a la misma.
• SC.3.182 / SC.3.188 / SC.3.191 – La documentación viaja protegida y bajo control por lo que sólo los usuarios autorizados podrán acceder y con los permisos asignados independientemente de dónde se transfiera la documentación. Esto incluye a dispositivos móviles a los que se envíe o donde se almacene la documentación sensible. También permite proteger la confidencialidad en el acceso a la CUI en reposo, esté esta donde éste.
• SC.3.190 – Las comunicaciones para el control de los permisos de accesos se realizan a través de protocolos seguros HTTPS utilizando un STS (Security Token Service). El protocolo empleado para entregar tokens de seguridad está basado en WS-Trust, una especificación de servicio Web construida sobre WS-Security.

Resumen

Una solución de protección centrada en los datos como SealPath ayuda a mantener la información protegida y bajo control en cualquier. Siguiendo los principios de Zero Trust, permite tener un acceso granular a la documentación Confidencial No Clasificada (CUI) así como a información confidencial clasificada. Sólo se deja acceder a los usuarios a aquello que necesitan y sólo a lo que necesitan y permite tener una monitorización de comportamientos de acceso sospechoso a la información crítica de la organización.

¿Desea conocer con más detalle cómo SealPath puede ayudarle en su proceso de certificación CMMC, NIST 800-171 o a implantar un modelo de seguridad Zero-Trust? Contacta con nosotros.