Patrones reales revisados
Resume situaciones de web server con HTTPS, certificados, trust list, usuarios, permisos HMI, switches gestionados, segmentación, OPC UA, conexiones seguras y equipos que siguen vivos pero ya no aceptan ciertas operaciones.
Diagnóstico de automatización industrial
OPC UA no conecta por trust list: separar certificado, hora, usuario, trust list, cliente, servidor, política y red OT antes de concluir.
Cuando OPC UA no conecta por trust list, no basta con mirar una alarma o una señal aislada. La guía ayuda a ordenar evidencias, condiciones de aparición, documentación y límites sin convertir el caso en una instrucción operativa.
El error es leer seguridad OT como si fuera solo una avería de red. Endurecer acceso, cambiar certificados o segmentar puede dejar la máquina viva a medias si no se entiende qué confianza se ha roto.
Criterio de la guía
Por qué esta guía puede ayudarte.
Está escrita para ordenar incidencias de acceso seguro OT sin publicar arquitectura privada, credenciales, rutas internas, políticas completas ni instrucciones de modificación.
Confianza antes que sospecha
Ayuda a separar si el problema está en identidad, certificado, hora, usuario, permiso, red, firmware, cliente, switch o controlador.
Límites claros
No da instrucciones para cambiar políticas, cargar certificados, modificar usuarios, abrir accesos remotos, publicar arquitectura ni relajar controles.
Separación diagnóstica
La primera separación: red viva no significa acceso autorizado.
La guía ayuda a ordenar qué relación de confianza se rompió antes de tratarlo como fallo de PLC o de red.
Certificado, hora e identidad
Entra cuando HTTPS, OPC UA, cliente de ingeniería o conexión segura fallan aunque el equipo responda y parezca operativo.
Usuario, rol y permiso
Entra cuando una HMI, SCADA o herramienta permite ver pero no operar, o cuando distintos perfiles obtienen resultados distintos.
Trust list y cliente
Entra cuando el controlador, servidor, cliente o estación no reconoce la contraparte esperada, sin que la red esté caída.
Switch, segmentación y nodos
Entra cuando un cambio de red deja parte de la celda viva y otra sin visibilidad, con pérdidas de nodos, rutas o servicios.
Firmware y compatibilidad
Entra cuando la política de seguridad, versión, herramienta o cliente no coincide con el estado del equipo o plataforma.
Diferencia entre seguridad y avería
Entra cuando el síntoma parece de comunicación, pero la causa puede estar en control de acceso, identidad o política OT.
Evidencia mínima
Evidencia mínima útil antes de tocar seguridad OT.
La evidencia útil conecta síntoma de acceso, equipo afectado, cambio reciente, política, cliente, red y alcance real.
- Síntoma exacto: acceso denegado, error de certificado, cliente no confiable, permiso insuficiente, nodo perdido, timeout o función bloqueada.
- Alcance: un usuario, una HMI, un cliente, un PLC, una celda, un switch, varios nodos o toda la línea.
- Cambio reciente: segmentación, switch, firmware, certificado, hora, usuario, rol, política, herramienta, backup, servidor o migración.
- Estado de red: equipo descubierto, ping o resolución disponible, servicio visible, comunicación parcial y diferencia entre red y autorización.
- Estado de identidad: certificado, trust list, hora, nombre, servidor, cliente, usuario, rol y permiso esperado sin publicar secretos.
- Contexto OT: impacto en producción, mantenimiento, acceso remoto, ingeniería, SCADA, OPC UA, HMI, histórico o alarmas.
- Documentación disponible: arquitectura funcional, matriz de usuarios, política aprobada, manuales y registro de cambios sin credenciales ni topología sensible.
- Riesgo: pérdida de visibilidad, acceso no autorizado, mantenimiento bloqueado, producción parcial o intervención sin responsable de seguridad.
Patrones de error
Errores que conviene evitar en ciberseguridad OT operacional.
La seguridad OT no se arregla con intuición de red ni con presión de producción. Se ordena con evidencia y responsable claro.
Culpar al PLC porque responde pero no deja entrar
Un equipo puede estar operativo y aun así rechazar acceso por identidad, usuario, certificado, política o cliente.
Confundir segmentación con caída
Tras un cambio de switch o red, algunos nodos pueden seguir vivos y otros quedar fuera por ruta, política o servicio.
Tratar permisos como avería de HMI
Si un perfil ve u opera distinto a otro, el caso puede pertenecer a roles, permisos o plataforma, no a pantalla rota.
Relajar controles para salir del paso
La continuidad no justifica dejar accesos abiertos, compartir credenciales o perder control de arquitectura.
Documentación
Documentación que conviene reunir sin exponer material sensible.
Harcki podrá trabajar con evidencias, manuales, capturas, políticas, registros y arquitectura funcional aportados por usuarios y validados. Esta guía pública solo ordena qué información conviene localizar.
- Descripción del error, usuario o cliente afectado, equipo, servicio, hora, cambio previo y alcance de la pérdida de acceso.
- Arquitectura funcional resumida: PLC, HMI, SCADA, switch, servidor, cliente, red, zona y relación entre equipos sin publicar secretos.
- Registro de cambios de certificados, usuarios, roles, políticas, firmware, segmentación, servidor, herramienta o mantenimiento.
- Capturas de mensajes y eventos ocultando tokens, credenciales, rutas privadas, direcciones sensibles y nombres internos no necesarios.
- Referencia de política aprobada, responsable de seguridad, manuales y procedimiento interno que gobierna el acceso.
Seguridad
Límites de seguridad antes de intervenir.
Una incidencia OT puede afectar visibilidad, operación, mantenimiento y seguridad. La guía ordena diagnóstico; no enseña a modificar defensas.
- No tratar certificados, usuarios, permisos, trust list o segmentación como obstáculos que se apartan sin responsable.
- No da instrucciones para cambiar políticas, cargar certificados, modificar usuarios, abrir accesos remotos, publicar arquitectura ni relajar controles.
- No compartir credenciales, capturas con secretos, rutas privadas, topologías sensibles ni información que facilite abuso.
- No sustituir políticas internas, fabricante, integrador, responsable de ciberseguridad, responsable de planta ni normativa aplicable.
- Ante duda de acceso, seguridad, producción parcial, pérdida de visibilidad o posible exposición, parar y escalar por el canal responsable.
Harcki
Esta guía ordena el inicio; Harcki permite continuar el caso completo.
Esta guía ayuda a separar ciberseguridad OT operacional sin publicar material sensible. Dentro de Harcki, el caso puede continuar con historial, evidencias, documentación validada, decisiones, contexto y memoria técnica compartida.
- 01Acceso con contexto
Certificado, usuario, rol, equipo, cliente, red, política y cambio reciente pueden quedar relacionados sin exponer secretos.
- 02Documentación validada
Capturas, manuales, registros, políticas y arquitectura funcional aportan valor cuando se revisan con control.
- 03Memoria OT prudente
Harcki puede acercar patrones de acceso seguro, trust list, permisos y segmentación sin convertirlos en instrucciones de debilitamiento.
Normativa y límites
Normativa, fabricante y responsable técnico siguen mandando.
Harcki ayuda a ordenar el caso. Las decisiones críticas dependen del profesional responsable y del marco aplicable.
Aviso de lanzamiento
Recibe el aviso cuando Harcki abra su primera fase.
Recibe el aviso para solicitar acceso a Harcki y continuar este tipo de diagnóstico dentro de la app: ciberseguridad OT, certificados, usuarios, permisos, switches, documentación validada, evidencias, historial y memoria técnica con límites claros.