Ciberseguridad OT: Del Modelo Purdue a la Norma IEC 62443

Una evaluación OT debe producir decisiones y evidencias, no sólo un diagrama. Usa Purdue como modelo de comunicación para ubicar activos empresariales, de operaciones, supervisión, control y proceso. No lo trates como arquitectura universal, marco de cumplimiento ni prueba de seguridad. Nube, unidades paquete, sistemas de seguridad y conexiones externas rara vez encajan en una sola jerarquía.

Esta lista es defensiva y no invasiva. Revisa registros, configuraciones, diagramas y logs con operaciones. No escanees controladores, pruebes servicios ni cambies producción. Registra lo desconocido como hallazgo.

1. Define el alcance y reúne el inventario

• Identifica proceso, límite del sitio, responsable, fecha de evaluación y restricciones operativas.
• Concilia el inventario de PLC, HMI, estaciones de ingeniería, historiadores, sistemas de seguridad, equipos de red, servidores, dispositivos de acceso remoto y servicios externos.
• Para cada activo, registra propietario, ubicación, función, fabricante/modelo, firmware o SO, criticidad, soporte, identificadores de red, dependencias y fuente autorizada.
• Incluye equipos temporales, portátiles, de contratistas y conectados intermitentemente. Marca cada campo desconocido para seguimiento.

La evidencia puede incluir registro de activos, configuración de switches, soporte y firma del responsable. La observación pasiva autorizada puede complementar esos registros; la ausencia en una herramienta no demuestra que un activo no exista.

2. Mapea zonas y conductos

Ubica activos en un diagrama de flujos y agrúpalos por función, consecuencia, confianza y requisito operativo. Etiqueta niveles Purdue sólo si ayudan. Define cada conducto con origen, destino, servicio, dirección, propósito, responsable y revisión.

• Separa los límites empresariales, de operaciones, control, seguridad funcional y sistemas paquete según el riesgo.
• Confirma que exista aplicación de políticas en el límite; una etiqueta VLAN por sí sola no es un control de seguridad.
• Elimina o deniega rutas entre zonas no documentadas mediante control de cambios y después de evaluar el impacto en el proceso.
• Documenta excepciones de tráfico heredado o específico, controles compensatorios y vencimiento.

3. Evalúa la DMZ industrial

Una IDMZ puede mediar intercambios IT/OT. No es obligatoria ni vuelve seguro un flujo inseguro.

• Termina en la IDMZ jump hosts, proxies, actualizaciones, réplicas o transferencia de archivos cuando sea viable.
• Comprueba que las sesiones empresariales no atraviesen transparentemente hacia zonas de control y que los activos de control no inicien acceso irrestricto a Internet.
• Compara reglas de firewall con el registro de conductos; captura responsable, justificación, última revisión y vencimiento.
• Verifica administración separada, bastionado, backup, monitoreo y parches para la IDMZ.

4. Controla el acceso remoto

• Inventaría cada ruta remota humana y de máquina, incluidos dispositivos de proveedores y enlaces celulares.
• Exige cuentas nominativas, MFA cuando exista soporte técnico, aprobación, mínimo privilegio y acceso limitado en el tiempo.
• Enruta sesiones interactivas mediante jump hosts gestionados; evita exposición directa de PLC, HMI, RDP, SSH o protocolos industriales a Internet público.
• Registra autenticación y actividad de sesión, deshabilita cuentas inactivas y define revocación de emergencia.
• Para sistemas sin MFA o autenticación moderna, documenta la excepción y aplica aislamiento, acceso supervisado, ventanas cortas u otros controles según riesgo.

5. Verifica backups y restauración

Respalda lógica, proyectos HMI/SCADA, recetas, configuraciones, certificados y licencias. Protege una copia del compromiso administrativo y registra la custodia de claves.

• Define prioridad de recuperación, responsables, dependencias y objetivos aceptables con los dueños del proceso.
• Prueba la restauración en un entorno seguro o una parada aprobada; verifica integridad, compatibilidad de versiones y prerrequisitos de reconstrucción.
• Conserva evidencia del último ejercicio, resultado, defectos y responsable de corregirlos. Un backup exitoso no equivale a una restauración probada.

6. Revisa logs y sincronización horaria

Identifica autenticación, privilegios, descargas de ingeniería, modos del controlador, configuraciones, sesiones remotas, firewall, alertas y acciones de seguridad funcional.

• Envía logs soportados a un punto de recolección protegido sin perjudicar el control determinista.
• Usa fuentes horarias aprobadas y resilientes, y documenta equipos que no puedan sincronizarse.
• Conserva origen, timestamp, zona horaria, desfase de reloj, retención, controles de acceso y procedimiento de cadena de custodia.
• Mapea la telemetría con comportamientos relevantes de MITRE ATT&CK for ICS para revelar brechas de detección. ATT&CK describe comportamiento adversario observado; no es una lista de controles ni una predicción.

7. Gobierna vulnerabilidades y excepciones de parcheo

• Correlaciona avisos del fabricante y versiones soportadas con el inventario; no escanees activamente activos OT frágiles sin autorización específica y un método probado.
• Evalúa explotabilidad, exposición, consecuencia de proceso, seguridad funcional, soporte, parada necesaria y reversión antes de remediar.
• Prueba parches o configuraciones en equipos representativos cuando sea viable, apruébalos mediante control de cambios OT y conserva evidencia de reversión.
• Para parches diferidos, registra motivo, responsable, controles compensatorios, próxima revisión y vencimiento. Reevalúa al cambiar la exposición o información de amenazas.

8. Prepara respuesta a incidentes y manejo de evidencia

Crea playbooks específicos para OT con roles de operaciones, ingeniería, seguridad funcional, legal y comunicaciones. Define quién puede aislar una zona, cerrar acceso remoto, recopilar evidencia, contactar proveedores o alterar un proceso. La seguridad y estabilidad del proceso gobiernan la contención; desconectar equipos automáticamente puede agravar las consecuencias.

• Mantén contactos offline, diagramas actuales, prioridades de sistemas, recursos limpios de recuperación y autoridad de decisión.
• Practica escenarios de credenciales comprometidas, ransomware en la IDMZ, cambio de lógica no autorizado y pérdida de visibilidad.
• Documenta fuentes de evidencia, autoridad de recolección, hashes, custodia, almacenamiento seguro y discrepancias horarias. Conserva evidencia volátil sólo con un método seguro y aprobado.
• Convierte hallazgos del ejercicio en acciones asignadas y actualiza la documentación de recuperación.

9. Usa un fixture determinista de decisión de evidencia

Aplica una regla: ALLOW sólo cuando todos los campos de evidencia requeridos estén presentes y vigentes; en caso contrario, DENY el ítem evaluado y abre un hallazgo. Son resultados de evaluación, no comandos para un firewall activo.

[
  {
    "id": "C-01",
    "flow": "Historian replica to enterprise reporting",
    "owner": "OT Operations",
    "evidence": "approved rule CR-1842; reviewed 2026-07-24",
    "decision": "ALLOW"
  },
  {
    "id": "C-02",
    "flow": "Vendor laptop directly to PLC",
    "owner": "",
    "evidence": "verbal request only",
    "decision": "DENY"
  }
]

El primer registro tiene responsable, aprobación y revisión. El segundo carece de responsable y evidencia aprobada. Los cambios reales requieren evaluación de riesgo y control de cambios.

Referencias oficiales

• NIST, SP 800-82 Rev. 3: Guide to Operational Technology (OT) Security, especialmente su guía sobre riesgo OT, arquitectura, controles, respuesta a incidentes, backups, acceso remoto y monitoreo.
• CISA, Principles of Operational Technology Cyber Security y ICS Cybersecurity Best Practices.
• MITRE, ATT&CK for ICS, utilizado aquí para orientar visibilidad defensiva y escenarios de ejercicio.

Fuentes consultadas el 2026-07-24. Aprobar esta lista no certifica cumplimiento, elimina el riesgo, demuestra un air gap ni garantiza disponibilidad o seguridad. El resultado útil es un paquete de evidencias revisado: inventario, mapa de zonas/conductos, excepciones, resultados de restauración, brechas de logs, acciones de incidentes, responsables y fechas objetivo.