El Problema de Auditoría en OT
Un auditor pregunta: "Muéstrame quién accedió al PLC-14 el 3 de marzo y qué comandos ejecutó."
En la mayoría de los entornos OT, esta pregunta no tiene respuesta. Estas son las razones:
- Cuentas compartidas: Los operadores inician sesión en los HMIs con una cuenta "operador" compartida. Tres turnos, doce personas, un único nombre de usuario.
- Acceso de proveedores por VPN: El proveedor se conecta a través de una VPN sitio a sitio. El registro del firewall muestra una conexión desde el rango de IP del proveedor. No indica qué persona se conectó ni qué hizo.
- Sin registro a nivel de comandos: Los historiadores SCADA registran valores de proceso. Syslog captura eventos de red. Ninguno registra los comandos específicos que un usuario envió a un PLC ni las pantallas que navegó en un HMI.
- Sin atribución de sesión: Incluso cuando existen registros, están vinculados a direcciones IP o cuentas compartidas, no a individuos autenticados.
Esta brecha no es teórica. Es la brecha concreta que los auditores de CMMC y NIS2 señalarán.
Lo que Exigen las Regulaciones
Requisitos de CMMC
AU.L2-3.3.1 (Eventos de Auditoría): Crear y conservar registros y logs de auditoría del sistema para habilitar la supervisión, el análisis, la investigación y la notificación de actividades ilegales o no autorizadas. Con el plazo de CMMC en octubre de 2026 que exige certificación de terceros, cumplir este control es urgente.
AU.L2-3.3.2 (Contenido de Auditoría): Garantizar que las acciones de cada usuario del sistema puedan rastrearse de forma unívoca hasta ese usuario.
AC.L2-3.1.7 (Funciones Privilegiadas): Impedir que usuarios sin privilegios ejecuten funciones privilegiadas y registrar la ejecución de dichas funciones en los logs de auditoría.
La palabra clave en 3.3.2 es individual. Las cuentas compartidas no satisfacen este control. El registro basado en direcciones IP tampoco lo satisface. Se requiere trazabilidad por usuario y por sesión.
Requisitos de NIS2
El Artículo 21 exige medidas de gestión de riesgos de ciberseguridad que incluyen la gestión de incidentes. Concretamente:
- Las organizaciones deben implementar medidas para la detección, respuesta y recuperación ante incidentes
- Las evidencias deben conservarse y estar disponibles para el análisis posterior a los incidentes
- Las medidas de seguridad en la cadena de suministro deben incluir la supervisión del acceso de terceros
Cuando una sesión de un proveedor a un PLC provoca una interrupción del proceso, NIS2 exige que se pueda reconstruir exactamente qué ocurrió, quién lo hizo y cuándo.
Cómo Funciona la Grabación de Sesiones
La grabación de sesiones en una arquitectura basada en proxy captura el contenido completo de cada conexión entre un usuario y un activo OT. El proxy intercepta la sesión, por lo que la grabación ocurre de forma transparente, sin necesidad de software en el endpoint.
La cadena de grabación:
- El usuario se autentica en el Access Gate con MFA. La identidad se verifica y queda vinculada a la sesión.
- Se evalúa la política. El sistema comprueba si este usuario está autorizado a acceder a este activo, en este momento y con este protocolo.
- Se establece la sesión. El proxy abre una conexión mediada hacia el dispositivo de destino.
- La sesión se graba íntegramente. Para sesiones RDP/VNC: captura de pantalla. Para sesiones SSH: comandos de terminal y salida. Para Modbus/OPC UA: comandos y respuestas a nivel de protocolo.
- La sesión se indexa. La grabación se almacena con metadatos: identidad del usuario, activo de destino, protocolo, hora de inicio, hora de fin y duración.
El resultado es un registro buscable y atribuible de cada interacción con cada activo OT.
Correspondencia entre la Grabación de Sesiones y los Controles de Cumplimiento
| Requisito de Cumplimiento | ID de Control | Qué Solicitan los Auditores | Cómo lo Proporciona la Grabación de Sesiones |
|---|---|---|---|
| Creación de eventos de auditoría | CMMC AU.L2-3.3.1 | Registros de todos los accesos a sistemas CUI | Cada sesión se registra con usuario, activo, protocolo y marca de tiempo |
| Trazabilidad individual | CMMC AU.L2-3.3.2 | Prueba de que las acciones se atribuyen a individuos | Usuarios autenticados con MFA vinculados a sesiones grabadas |
| Registro de funciones privilegiadas | CMMC AC.L2-3.1.7 | Registros de acciones de administración e ingeniería | Operaciones de escritura y cambios de configuración capturados a nivel de protocolo |
| Aplicación del mínimo privilegio | CMMC AC.L2-3.1.5 | Evidencia de restricciones de acceso | El motor de políticas restringe el acceso por usuario, activo y operación |
| Detección y respuesta a incidentes | NIS2 Artículo 21(b) | Procedimientos de gestión de incidentes con evidencias | Las sesiones grabadas proporcionan evidencia forense para la reconstrucción de incidentes |
| Conservación de evidencias | NIS2 Artículo 21 | Registros conservados para análisis posterior a incidentes | Grabaciones almacenadas con retención configurable y protección contra manipulación |
| Supervisión de la cadena de suministro | NIS2 Artículo 21(d) | Controles de acceso de proveedores y pista de auditoría | Las sesiones de terceros se graban con la misma fidelidad que las sesiones internas |
| Informes de gestión de riesgos | NIS2 Artículo 21(a) | Controles de seguridad demostrables | Los paneles de grabación de sesiones muestran patrones de acceso y aplicación de políticas |
Qué Captura la Grabación de Sesiones por Protocolo
Cada protocolo genera distintos tipos de datos de auditoría:
| Protocolo | Tipo de Sesión | Qué se Registra |
|---|---|---|
| RDP / VNC | Acceso a HMI, estaciones de trabajo de ingeniería | Captura de pantalla completa (vídeo), pulsaciones de teclas, actividad del portapapeles |
| SSH | Controladores basados en Linux, dispositivos de red | Comandos de terminal, salida, transferencias de archivos |
| Modbus TCP | Comunicación con PLC | Códigos de función (lectura vs. escritura), direcciones de registro, valores |
| OPC UA | SCADA a PLC, conexiones de historiador | Acceso a nodos, operaciones de lectura/escritura, actividad de navegación |
| HTTP/HTTPS | HMIs web, gestión de dispositivos | URLs, envíos de formularios, llamadas API |
Esta granularidad a nivel de protocolo es lo que diferencia la grabación de sesiones del registro de red. Un log de firewall indica que se produjo una conexión Modbus TCP. La grabación de sesiones indica que el Usuario X envió un comando Write Single Register (código de función 06) al registro 40001 con el valor 1, modificando el setpoint de una bomba.
Guía de Despliegue Práctico
El despliegue de la grabación de sesiones en un entorno OT no tiene que realizarse de una sola vez. Un enfoque por fases reduce el riesgo y genera confianza en la organización.
Fase 1: Acceso Remoto de Proveedores (Semanas 1-2)
Comience aquí. Las sesiones de proveedores son el objetivo de mayor riesgo y mayor visibilidad.
- Enrute todo el acceso remoto de proveedores a través del Access Gate
- Habilite la grabación de sesiones en todas las sesiones de proveedores
- Exija MFA en cada conexión de proveedor
- Establezca la política de retención (mínimo 90 días para CMMC, alineada con los requisitos de NIS2)
Por qué empezar aquí: Los proveedores acceden a activos críticos, frecuentemente con privilegios elevados y mediante credenciales compartidas. Esta es la brecha que los auditores buscan primero.
Fase 2: Acceso Interno de Ingeniería (Semanas 3-4)
Extienda la grabación a los ingenieros y operadores internos que acceden a PLCs y HMIs.
- Defina políticas de acceso por usuario (quién puede acceder a qué activos)
- Habilite la grabación en las sesiones de estaciones de trabajo de ingeniería
- Implemente políticas con conocimiento de protocolo (p. ej., permitir lectura, bloquear escritura durante horas de producción)
Fase 3: Cobertura Completa (Meses 2-3)
Amplíe la cobertura a todas las rutas de acceso OT.
- Grabe todas las sesiones a servidores SCADA e historiadores
- Integre los logs de sesiones con el SIEM para correlación
- Genere informes de cumplimiento que mapeen las sesiones con los requisitos de control
- Realice una auditoría simulada utilizando las sesiones grabadas como evidencia
Qué Esperar de los Auditores
Cuando un evaluador de CMMC o un auditor de NIS2 revise su entorno OT, solicitará:
- Registros de acceso que muestren quién accedió a qué sistemas y cuándo
- Evidencia de atribución individual (no cuentas compartidas)
- Prueba de aplicación del mínimo privilegio (usuarios restringidos a los activos autorizados)
- Evidencia de respuesta a incidentes (capacidad de reconstruir lo ocurrido durante un evento de seguridad)
La grabación de sesiones proporciona una fuente única y buscable de evidencia para los cuatro puntos. En lugar de combinar logs de firewall, logs de VPN, entradas del historiador SCADA y logs de eventos de Windows, se señala al auditor una sesión grabada con el nombre del usuario, el activo de destino y el contenido completo de la interacción.
Deje de tratar el acceso OT como un problema de red. Trátelo como un problema de identidad con evidencia a nivel de sesión. Para profundizar en por qué una arquitectura basada en proxy es la base adecuada para la grabación de sesiones en OT, comience por ahí. Eso es lo que esperan los auditores y lo que exigen los marcos de cumplimiento.
Para más recursos sobre CMMC, casos de uso e implementación, visite el centro de Cumplimiento CMMC para entornos On-Premise.
Para más recursos sobre NIS2, opciones de despliegue soberano y guías de cumplimiento, visite el centro de Cumplimiento NIS2 para OT On-Premise.
