Un SIEM recibe los registros de muchos equipos, los une, los correlaciona y avisa de lo sospechoso. En una subestación, lo útil de enviar son los inicios de sesión y sus fallos, los cambios de configuración, el estado de las comunicaciones y las alarmas de seguridad de relés, switches y firewalls, con reloj sincronizado y retención definida. La norma NERC CIP-007 da una referencia concreta: registrar esos eventos, alertar ante fallas del registro, conservar 90 días y revisar un resumen al menos cada 15 días.
Qué problema resuelve
En una subestación hay decenas de equipos que registran lo que les pasa: relés, controladores, switches, firewalls, relojes, la HMI y el servidor SCADA. Cada uno guarda sus eventos en su memoria, que es corta, y se sobrescribe. Si el equipo se apaga, se reinicia o lo manipula alguien, el registro puede perderse justo cuando hace falta. Un registro central guarda copia fuera del equipo, y un SIEM (gestión de eventos e información de seguridad) añade capacidades para usarla.
En un SIEM suelen distinguirse estas funciones: agregación de datos de varias fuentes, correlación para convertir datos en información, alertas dirigidas a un responsable, paneles de control y apoyo al cumplimiento con informes. Es la herramienta central de un centro de operaciones de seguridad (SOC), propio o contratado.
Dónde encaja: la supervisión de la red con SNMP y syslog responde cómo está el equipo; el SIEM responde si alguien ha hecho algo que no debía. Los dos se alimentan de las mismas fuentes.
Qué enviar
No todo lo que registra un equipo es útil, y enviar todo satura. El criterio es el tipo de evento, no el volumen:
| Fuente | Eventos de seguridad útiles | Por qué |
|---|---|---|
| Relés y controladores | Inicios de sesión y fallos, cambio de ajustes o de grupo, creación y cambio de cuentas, reinicio, actualización de firmware | Cambios no autorizados y fuerza bruta |
| Switches y routers | Cambio de configuración, inicios de sesión, puerto que sube o baja, cambio de topología | Dispositivo conectado donde no debía, o ruptura del enlace |
| Firewalls | Conexiones bloqueadas, cambios de reglas, accesos administrativos | Escaneos y cruces de zona no previstos |
| Servidor SCADA y HMI | Inicios de sesión, mandos con usuario, cambios de configuración, acciones sobre alarmas | Quién operó qué |
| Puerta de acceso remoto | Sesiones abiertas y cerradas, usuario, destino, duración | Trazabilidad del acceso de ingeniería y de proveedores |
| Relojes y servidores de tiempo | Pérdida de la referencia, cambio de fuente | Sin tiempo fiable no se ordenan los eventos |
La norma NERC CIP-007 sirve de referencia aunque la instalación no esté sujeta a ella. Para los sistemas que cubre, en la edición que consultamos, pide registrar como mínimo los inicios de sesión exitosos, los accesos e inicios fallidos y el código malicioso detectado; generar alertas ante código malicioso y ante la falla del propio registro; conservar los registros al menos 90 días naturales consecutivos, y revisar un resumen o muestreo a intervalos no mayores de 15 días naturales para encontrar incidentes no detectados. Esa última exigencia es la que más se olvida: guardar sin revisar no es monitoreo.
Cómo llegan los datos
Syslog (IETF RFC 5424) es el formato más común para que switches, firewalls y muchos IED envíen sus mensajes. Algunos puntos prácticos:
- El transporte importa. Sobre UDP un mensaje puede perderse sin aviso; sobre TCP, y mejor aún con TLS, hay entrega confirmada y protección del contenido. Los equipos antiguos solo envían por UDP.
- Los relés a veces no hablan syslog. Algunos exponen sus eventos por el protocolo de la subestación o por una herramienta del fabricante; en ese caso, la puerta de enlace, el SCADA o un colector hacen de intermediario.
- Un colector local por subestación guarda en caché si el enlace al centro de control cae, y reenvía al restablecerse.
- La red de registro es de gestión, no la de proceso. El tráfico de syslog no debe compartir VLAN con GOOSE ni valores muestreados; vea segmentación de redes OT.
Tiempo y orden de los eventos
Un SIEM correlaciona eventos de equipos distintos por su estampa de tiempo. Si un relé tiene otra hora que el firewall, la secuencia de un incidente queda desordenada y la correlación falla. Todos los equipos que envían deben estar sincronizados con la misma fuente; vea sincronización de tiempo en subestaciones. Defina también la zona horaria de los registros, preferiblemente UTC en el colector.
Evitar el exceso de alertas
Un SIEM sin ajustar produce cientos de alertas que nadie lee. Para evitarlo:
- Parta de pocas reglas útiles: fallos de inicio de sesión repetidos, cambio de configuración fuera de ventana de mantenimiento, cuenta nueva, dispositivo desconocido en la red, falla del propio registro.
- Distinga ventana de mantenimiento de operación normal, para no alertar por el trabajo autorizado.
- Asigne un responsable y un tiempo de respuesta a cada alerta. Una alerta sin dueño no es una alerta.
- Revise y retire reglas que nunca sirven.
- Conecte las alertas con la respuesta: ¿a quién se llama y qué se hace? El plan de respuesta se trata en evaluación de brechas de ciberseguridad OT.
Un sistema de detección de intrusos añade eventos que el SIEM puede recibir; vea detección de intrusos en redes de subestación. Cómo armar el plan, con roles, escalamiento y pruebas anuales, está en plan de respuesta a incidentes en una subestación.
Qué cuidar al diseñar
- Los registros son sensibles: contienen nombres de usuario, direcciones y comportamiento de la red. Protéjalos como tal.
- El SIEM no debe ser un camino de entrada: el flujo es de la subestación hacia afuera, y el colector se aloja en una zona controlada.
- Capacidad: calcule el almacenamiento a partir de los eventos por equipo y la retención elegida.
- Prueba periódica: genere un evento de prueba y compruebe que llega, con hora correcta y a quien debe ver la alerta.
Qué se pudo verificar
Los requisitos de registro citados vienen del texto de CIP-007 tal como lo reproduce una matriz de cumplimiento de un fabricante de 2017; la versión vigente se confirma en nerc.com. La descripción de las funciones de un SIEM se contrastó con material de formación en ciberseguridad industrial, que se usó solo como mapa de temas. La compatibilidad con syslog, el transporte y el contenido de los eventos dependen de cada modelo y firmware; se verifican en el manual de cada equipo.
Cómo le ayudamos
En Tiza Group configuramos el envío de eventos de relés, controladores, switches y firewalls a un registro central, con reloj sincronizado y retención definida, dentro de nuestro servicio de ciberseguridad de subestaciones y plantas. Escríbanos. Las reglas para laptops de servicio, equipos de terceros y memorias USB que se conectan a relés y switches están en laptops de servicio y USB en subestaciones.
Guías relacionadas
- Supervisión de la red de subestación: SNMP y syslog
- Monitoreo de seguridad de red: IEC 62351-7
- Detección de intrusos en redes de subestación
- Cuentas y contraseñas en IED: roles y rotación
- Matriz de cumplimiento NERC CIP: cómo leerla
- Sincronización de tiempo en subestaciones
- Plan de respuesta a incidentes en una subestación
- Laptops de servicio y USB en subestaciones: reglas
Referencias
- IETF RFC 5424, The Syslog Protocol.
- NERC, CIP-007, Systems Security Management, requisito R4 (la versión vigente se confirma en nerc.com).
Preguntas frecuentes
¿Un SIEM es lo mismo que un servidor syslog?
No. Un servidor syslog recibe y guarda mensajes. Un SIEM, además, une datos de muchas fuentes, los correlaciona para encontrar patrones, genera alertas y paneles, y ayuda a preparar informes de cumplimiento. Muchas instalaciones empiezan con un syslog bien administrado y suben al SIEM cuando tienen quién lo opere.
¿Todos los eventos del relé deben ir al SIEM?
No. Los eventos de protección y de proceso, como disparos y arranques, pertenecen al registro de eventos de la operación y al SCADA. Al SIEM van los eventos de seguridad: accesos, fallos de acceso, cambios de ajustes o de cuentas, reinicios, conexión de dispositivos y alarmas de los equipos de red.
¿Cuánto tiempo hay que guardar los registros?
Lo fija su política y, si aplica, la norma. NERC CIP-007, en la edición que consultamos, pide conservar los registros de eventos al menos 90 días naturales consecutivos, donde sea técnicamente factible, y revisar un resumen o muestreo a intervalos no mayores de 15 días naturales. Muchas organizaciones guardan más por motivos de investigación.