Alertas de dispositivo nuevo y de órdenes inusuales

La política opcional de Zeek que sigue a los equipos de Modbus (known_modbus.log) anota cada equipo visto actuando como maestro, el que pide, o como esclavo, el que responde. Cuando un equipo aparece por primera vez como maestro, ese registro es la señal de dispositivo nuevo. Hay un detalle: la memoria de lo ya visto dura un día por defecto, de modo que los equipos de siempre vuelven a aparecer cada día. Lo que cuenta no es que aparezca una línea, sino que aparezca una línea de alguien que no debería.

Un dispositivo nuevo no es por sí solo un ataque: puede ser el portátil de un integrador, una pantalla nueva o un equipo instalado sin avisar al equipo de seguridad. Se contrasta con tres fuentes: el inventario, las ventanas de mantenimiento y los cambios aprobados. Si ninguna lo explica, entonces sí es una pregunta urgente.

Dos equipos aparecieron como maestros de Modbus durante la mañana. Uno es un puesto de la oficina que sí está en el inventario aunque nunca debió pedir a un PLC; el otro, una dirección que el inventario no conoce. Son hallazgos de naturaleza distinta: el primero es un equipo conocido que hace algo que no le toca, el segundo es un equipo sin dueño.

Un equipo sin dueño es la peor combinación: nadie sabe quién lo instaló, quién lo mantiene ni a quién llamar. Se escala con su dirección y la hora exacta en que Zeek lo vio por primera vez.

Las reglas de Suricata empiezan por una acción: alert avisa, drop descarta el tráfico. Un sensor en línea, puesto en el camino del tráfico, puede ejecutar el drop. Un sensor pasivo trabaja sobre una copia: no hay un paquete real que descartar, porque el real sigue su camino por otro lado. Una regla con acción drop en un sensor pasivo no bloquea nada, por mucho que su mensaje diga «bloqueada».

Ese mensaje es peligroso. Quien lo lea en el panel puede creer que la escritura quedó detenida cuando en realidad llegó al PLC. En OT, además, no se quiere un equipo capaz de cortar órdenes: un falso positivo detendría un comando legítimo. La regla debe decir lo que hace el sensor, que es avisar.

Una regla útil se mide por lo que acierta, no por lo que grita. Siete días de disparos con las veces que el turno confirmó que era algo dan la medida: una regla con miles de disparos y ninguna confirmación está describiendo algo que ocurre todos los días y es normal. Mantenerla así cuesta atención y entierra las alertas que sí importan.

Una de las tres reglas de la tabla hizo muchísimo ruido en la semana sin que el turno confirmara ni un solo caso. Escribe su identificador (sid).

La regla ruidosa avisa de toda escritura en registros de retención, y la supervisión escribe consignas a diario con permiso. El afinado correcto calla solo ese caso: la regla sigue activa para todos los demás orígenes y se calla solo para el equipo autorizado. En Suricata se puede hacer con una supresión por origen, suppress gen_id 1, sig_id N, track by_src, ip X, que no toca la regla ni a los demás equipos.

Las dos salidas malas son las que más seducen: apagar la regla entera, que deja sin vigilancia las escrituras de cualquier equipo, o dejarla como está, que mantiene a los analistas ignorándola. Lo primero pierde la señal; lo segundo, el hábito de mirarla.