DNP3 tiene un estándar de seguridad. No cifra nada.
Secure Authentication v5 es criptografía real, estandarizada en IEEE 1815, y demuestra quién envió un comando. No dice nada sobre quién puede leerlo. Esta guía cubre qué protege SAv5 en realidad, por qué tan pocas empresas de servicios la usan y qué hacer con el tráfico que deja en claro.
Última actualización:
¿Qué es la seguridad DNP3 y qué aporta realmente SAv5?
La seguridad DNP3 abarca dos cosas distintas que es fácil confundir. Secure Authentication v5, definida en IEEE 1815, añade autenticación por desafío-respuesta para que una estación remota pueda verificar que un comando crítico vino realmente del maestro que dice haberlo enviado. Eso es autenticación e integridad. No es confidencialidad: con SAv5 activo, el tráfico sigue siendo legible en la red. El cifrado es una decisión aparte y viene de ejecutar DNP3 sobre TLS.
DNP3 llegó en los años noventa para servicios eléctricos y de agua, y hace más que Modbus: datos con marca de tiempo, registro de eventos, respuestas no solicitadas y operación sobre enlaces largos y ruidosos. Esa riqueza explica que siga presente en la telesupervisión, y también es lo que le da más material a un atacante cuando nada autentica el tráfico.
¿Por qué SAv5 se activa tan pocas veces?
El estándar está disponible desde 2012. Su adopción en campo es baja, y no porque los operadores estén en desacuerdo. Cuatro obstáculos prácticos explican la mayor parte.
Las claves deben llegar a estaciones dispersas
SAv5 depende de que las claves de actualización y de sesión lleguen a cada estación remota. En una empresa de servicios, esas estaciones son bombeos, subestaciones y unidades terminales remotas repartidas por un territorio, a menudo alcanzables por un enlace lento o intermitente. Distribuir y rotar ese material de claves en semejante parque es el verdadero trabajo, y por eso la función queda sin usar.
Ambos extremos deben admitirla
SAv5 es una capacidad negociada. Una estación remota que la admite no gana nada si el maestro no la admite, y un parque de equipos comprado a lo largo de dos décadas rara vez la tiene en ambos extremos de cada enlace. El equipo más antiguo marca el techo.
Protege funciones críticas, no todo
El estándar autentica los códigos de función críticos: operar, operar directo, reinicios, cambios de configuración. El sondeo rutinario y la telemetría no están cubiertos por defecto, lo cual es correcto desde la ingeniería, pero significa que activar SAv5 no autentica toda la conversación.
Se confunde a menudo con cifrado
Este es el que causa daño real. Los equipos activan SAv5, registran el control como cumplido y suponen que el enlace ya es privado. No lo es. Los valores de proceso, los nombres de puntos y la forma de la operación siguen siendo legibles para cualquier cosa en el camino.
¿Qué puede hacer un atacante con una estación remota sin autenticar?
DNP3 organiza los datos en objetos y puntos, y admite respuestas no solicitadas. Esa estructura es lo que lo hace útil para los servicios públicos, y también es un mapa bien documentado para quien alcance el puerto.
Comandos de control no autorizados
Una petición de operar u operar directo contra un bloque de salida de relé, desde un maestro que nunca ha emitido una o hacia un punto que nunca ha recibido una. Es el precursor clásico de un accionamiento no autorizado, y sin SAv5 nada en el protocolo lo distingue de un comando legítimo.
Reconocimiento del mapa de datos
Peticiones de objetos, variaciones o rangos de puntos fuera del perfil normal de la estación. Como DNP3 es autodescriptivo, un atacante puede aprender el mapa de datos del equipo sin enviar nada que parezca malicioso.
Repetición de tráfico capturado
Retransmitir paquetes antes válidos para disparar una acción o enmascarar un cambio. SAv5 lo impide con desafío-respuesta y nonces de sesión; sin ella, el análisis de marcas de tiempo y secuencias es la única defensa, y eso es detección, no prevención.
Abuso de reinicio y configuración
Reinicio en frío, reinicio en caliente y códigos de función de configuración que aparecen fuera de una ventana de mantenimiento planificada. Son exactamente las funciones críticas que SAv5 se escribió para proteger, y por eso un parque sin autenticar queda expuesto a ellas.
¿Qué cubre Secure Authentication v5?
SAv5 es un mecanismo de desafío-respuesta transportado dentro del propio DNP3. Cuando un maestro emite una petición crítica, la estación remota la desafía y el maestro responde con un código de autenticación de mensaje calculado sobre la petición con una clave de sesión compartida. La estación actúa solo si esa prueba es válida.
| Propiedad | Con SAv5 | Qué significa en la práctica |
|---|---|---|
| Autenticación | Sí, en códigos de función críticos | La estación puede demostrar que un comando de control vino del poseedor de la clave de sesión, y no de cualquier otra cosa que alcanzara el puerto. |
| Integridad | Sí | Un comando alterado en tránsito falla su código de autenticación y se rechaza. |
| Protección contra repetición | Sí | El desafío-respuesta con nonces de sesión hace que un paquete capturado no pueda simplemente reenviarse. |
| Confidencialidad | No | No se cifra nada. Los valores de proceso, los nombres de puntos y la estructura de la operación siguen legibles en la red. |
| Cobertura | Funciones críticas | El sondeo rutinario y la telemetría no se autentican por defecto, así que activar SAv5 no autentica toda la sesión. |
¿La autenticación segura de DNP3 cifra el tráfico?
No, y este es el malentendido de mayor consecuencia sobre la seguridad DNP3. SAv5 demuestra quién envió un comando y que no fue alterado. No oculta lo que dice el comando ni la telemetría que vuelve. Si necesita confidencialidad, ejecuta DNP3 sobre TLS, un control aparte con sus propios certificados y su propia gestión de claves. Una lista que registra SAv5 como cumplimiento de un requisito de cifrado en tránsito está registrando algo que no es cierto.
¿Cómo se cifra realmente DNP3?
El cifrado para DNP3 viene de envolverlo en TLS, no del protocolo en sí. Es una opción real con costes reales, y en esos costes es donde se atasca la mayoría de los parques.
TLS en el enlace
DNP3 sobre TLS aporta confidencialidad y una segunda autenticación de los extremos, a nivel de transporte. Necesita certificados en ambos lados, lo que implica una autoridad de certificación, una vía de distribución y un proceso de renovación que alcancen cada estación remota.
El problema del certificado es otra vez el de la clave
Es el mismo obstáculo que deja SAv5 sin usar, con otro traje. Si las claves de actualización no pueden llegar en la práctica a un bombeo remoto, tampoco pueden hacerlo unos certificados que caducan.
Los enlaces serie cambian la pregunta
Buena parte de DNP3 sigue corriendo sobre serie o sobre convertidores de serie a IP. TLS asume una ruta IP, así que en esos enlaces la cuestión de la confidencialidad se traslada a lo que transporta el serie, no a DNP3.
O sacar el problema de las estaciones
Donde el trabajo de certificados por equipo no es realista, terminar la sesión en un proxy que entiende el protocolo permite que un solo componente guarde las claves y los certificados, en lugar de que cada equipo remoto sostenga una parte del problema.
¿Qué maestro, o qué técnico?
SAv5 responde a una pregunta más estrecha de lo que se supone. Una clave de sesión es una credencial de equipo: demuestra que la petición vino de algo que posee esa clave. No dice quién estaba en el teclado, y en un puesto de ingeniería compartido esos son hechos muy distintos.
Qué establece SAv5
Que la petición vino de una parte que posee la clave de sesión de ese enlace, y que no fue alterada ni repetida. Para un sondeo de máquina a máquina entre un maestro y una estación remota, esa es exactamente la garantía correcta, y basta.
Qué no puede establecer
Qué persona emitió el comando. Una clave compartida por una sala de control, un portátil de mantenimiento y la sesión remota de un integrador autentica a los tres igual. Si la clave se copia, la copia es indistinguible del original.
Esto importa sobre todo donde DNP3 se encuentra con personas: ventanas de mantenimiento, acceso de integradores, cualquier cosa alcanzada por soporte remoto. NERC CIP-004 y CIP-005 preguntan quién tuvo acceso y cuándo, y una credencial de equipo compartida por un equipo no puede responderlo. La identidad nominal debe venir de la capa que gestiona la sesión, no del protocolo.
¿Dónde se rompe la seguridad DNP3 en la práctica?
Como en la mayoría de los protocolos OT, los fallos son de despliegue más que de criptografía.
SAv5 registrada como cifrado
La fila de cumplimiento dice cifrado, la red dice otra cosa. Compruebe qué pedía realmente el control.
Activada solo en un extremo
Una estación capaz emparejada con un maestro que no puede negociar SAv5 no obtiene protección, y el inventario del parque suele registrarla como activada.
Claves de actualización nunca rotadas
Claves instaladas en la puesta en marcha y nunca tocadas de nuevo. Nada falla, así que nada obliga a revisarlas, y el alcance de una sola clave comprometida se vuelve permanente.
Puerto por defecto accesible
DNP3 escucha por convención en el puerto TCP 20000. Una estación accesible en ese puerto desde una red plana es accesible para todo lo que esté en esa red, autenticada o no.
Convertidores de serie a IP tratados como neutros
Poner un enlace serie sobre IP lo expone a todo aquello a lo que IP lo expone. El convertidor rara vez recibe el escrutinio que sí recibiría el equipo final.
Lista de endurecimiento DNP3: qué verificar
Casi todo es verificación más que construcción, y buena parte se responde con una captura y un inventario.
- 01
Confirmar qué enlaces negocian realmente SAv5, en ambos extremos, y no qué equipos la listan como capacidad.
- 02
Comprobar que los códigos de función críticos, operar, operar directo, reinicio y cambio de configuración, son los que se están autenticando.
- 03
Dejar constancia explícita, en el registro de riesgos y en cualquier evidencia de cumplimiento, de que SAv5 es autenticación y no cifrado.
- 04
Decidir dónde se requiere realmente confidencialidad y aplicar TLS ahí, en vez de suponer que el protocolo la aporta.
- 05
Dar a las claves de actualización un calendario de rotación y un responsable, y registrar las fechas de emisión y caducidad junto con el resto del estado de la red.
- 06
Establecer una referencia de los objetos, variaciones y códigos de función que cada estación ve normalmente, para que se vea cualquier cosa fuera de ese perfil.
- 07
Confirmar que el puerto TCP 20000 no es accesible desde ningún sitio que no lo necesite, sea cual sea el estado de autenticación.
Estos controles se corresponden con NERC CIP-005 para el perímetro de seguridad electrónica y CIP-007 para la seguridad de sistemas, con la identificación y autenticación (FR1) y el control de uso (FR2) de IEC 62443, y con NIST SP 800-82r3 para sistemas OT.
¿Cómo se asegura DNP3 que no se puede reconfigurar?
Todo lo anterior supone que se puede cambiar el equipo y hacerle llegar claves. En un parque distribuido esa suposición falla a menudo: el equipo es anterior a SAv5, el fabricante no admite el cambio, o el emplazamiento está a dos horas en coche de quien podría hacerlo. La alternativa es poner la protección delante de la estación.
Un solo sitio guarda las claves
Access Gate opera su propia PKI y termina la sesión, de modo que certificados y material de claves viven en el equipo y no en cada estación remota. El equipo que nunca habría podido sostener una clave rotativa ya no tiene que hacerlo.
Confidencialidad sin tocar el protocolo
El canal hacia la Gate es TLS 1.3 con intercambio de claves poscuántico (ML-KEM-768), verificado contra esa PKI, delante de una estación que no habla nada de eso.
Denegación por defecto, por identidad y protocolo
Conceder a un técnico acceso DNP3 a una estación no le concede nada más. Cada protocolo en cada activo es un permiso explícito, que es la aplicación que una estación sin autenticar no puede darse a sí misma.
Evidencia para CIP-005 y CIP-007
El mismo proxy que filtra la sesión la registra: qué identidad, qué estación, qué protocolo y cuándo. Esa es la evidencia de control de acceso que pide NERC CIP, producida por la operación y no por un proyecto aparte.
Poner bajo control un parque DNP3 sin visitar cada emplazamiento
Si sus estaciones remotas no pueden ejecutar SAv5, o la rotación de claves por todo el territorio no es realista, podemos repasar juntos cómo se ve el filtrado del canal en su red.
Red eléctrica y subestaciones
Cómo se aplica la misma arquitectura a SCADA, unidades terminales remotas y relés de la red eléctrica.
Verlo en su propio parque
Un repaso sobre su topología: qué estaciones están expuestas, cómo se ve la aplicación de políticas y qué exige el despliegue.
Preguntas sobre seguridad DNP3
El puerto TCP DNP3 por defecto. Una estación accesible aquí sin autenticación ejecutará cualquier comando bien formado que reciba.
No. SAv5 aporta autenticación, integridad y protección contra repetición para los códigos de función críticos. No aporta confidencialidad, así que la carga útil sigue siendo legible en la red. El cifrado para DNP3 viene de ejecutarlo sobre TLS, un control aparte con sus propios certificados y su propia gestión de claves. Registrar SAv5 frente a un requisito de cifrado en tránsito es registrar algo que no es cierto.
Es el mecanismo de seguridad definido en IEEE 1815, la norma que especifica DNP3. Cuando un maestro envía una petición crítica, como operar o reiniciar, la estación remota emite un desafío y el maestro debe responder con un código de autenticación de mensaje calculado con una clave de sesión compartida. La estación actúa solo si esa prueba es válida, lo que detiene tanto los comandos falsificados como los repetidos.
La gestión de claves. SAv5 necesita que las claves de actualización y de sesión lleguen a cada estación remota, y en una empresa de servicios esas estaciones están repartidas por un territorio en enlaces lentos, intermitentes o ambas cosas. También debe estar admitida en ambos extremos de un enlace, y un parque comprado a lo largo de dos décadas rara vez lo está. El obstáculo no es la criptografía, sino distribuir y rotar el material de claves.
No. Autentica los códigos de función críticos, los que cambian el estado: operar, operar directo, reinicio en frío y en caliente, cambios de configuración. El sondeo rutinario y la telemetría no se autentican por defecto. Es un compromiso de ingeniería deliberado, ya que autenticar cada sondeo costaría ancho de banda en enlaces que no lo tienen, pero significa que activar SAv5 deja sin autenticar la mayor parte de la conversación.
Poniendo la protección delante de ellas. Se lleva la estación a un enclave segmentado para que no sea directamente accesible, y se termina la sesión en un proxy que entiende el protocolo y aplica identidad y política antes de restablecer la conexión. Las claves y los certificados viven en el proxy y no en un equipo remoto que nunca habría podido sostenerlos, y el equipo conserva su configuración, su firmware y su IP.
