Diseño de aplicaciones HMI/SCADA con criterios de ciberseguridad: principios que reducen el riesgo ya desde la fase de diseño

La seguridad de una aplicación HMI/SCADA se define mucho antes de la fase de selección de los mecanismos de protección. Que el sistema sea resistente a errores, usos indebidos y cambios no controlados en el estado del proceso depende, ante todo, de los criterios adoptados en el diseño: la distribución de roles, los límites de confianza, el alcance de las funciones accesibles desde la interfaz y la forma de organizar el servicio y el acceso remoto. Si estas cuestiones se tratan como algo secundario, la aplicación empezará a consolidar el riesgo en lugar de reducirlo. Por eso, el diseño de HMI/SCADA con criterios de ciberseguridad debe abordarse como una tarea de ingeniería: primero hay que determinar qué operaciones son críticas, qué consecuencias pueden tener y quién debe poder ejecutarlas realmente, y solo después diseñar pantallas, alarmas y la comodidad de uso.

La ciberseguridad empieza en el diseño

En los sistemas HMI/SCADA, la ciberseguridad no es un añadido a una visualización ya terminada. Es el resultado de decisiones tomadas previamente: la arquitectura de la aplicación, el modelo de permisos, la forma de comunicación con el control y los criterios definidos para el servicio. Esto es especialmente importante porque la aplicación HMI/SCADA es, al mismo tiempo, el punto de contacto entre las personas, el proceso y la infraestructura. Por tanto, un error de diseño no se limita al riesgo informático. También puede afectar a la respuesta del operador, a la seguridad funcional, al riesgo operativo y a la continuidad de la producción.

Desde la perspectiva del diseño, la pregunta básica no es qué protección añadir al final, sino qué decisiones tomadas desde el principio reducirán la superficie de ataque. Los problemas más graves normalmente no se deben a la ausencia de un mecanismo concreto, sino a un exceso de confianza incorporado en la propia aplicación. En la práctica, esto significa cuentas de usuario compartidas, acceso de servicio amplio y permanente, falta de separación de roles entre el operador, el personal de mantenimiento y el integrador, así como una comunicación demasiado abierta entre la capa de operación y el sistema de control. En la fase de puesta en marcha, estas soluciones parecen cómodas porque aceleran el trabajo y facilitan el diagnóstico. Más adelante, se convierten en una característica permanente del entorno y aumentan el riesgo de uso indebido, error o cambio no controlado del estado del proceso.

Por eso, antes de diseñar las pantallas conviene definir no solo qué debe ver el usuario, sino sobre todo dónde están los límites de confianza, qué operaciones son críticas y en qué puntos la interfaz puede convertirse en una herramienta para provocar errores o eludir procedimientos. Este orden ayuda a estructurar las decisiones posteriores: si el HMI debe ser únicamente una capa de visualización o también un entorno de configuración, diagnóstico y cambio de recetas; si las funciones de servicio deben estar activas de forma permanente o solo tras una activación consciente; si el operador debe tener acceso exclusivamente a la operación del proceso o también a funciones que modifican parámetros y el historial de datos.

El coste práctico de estas omisiones suele hacerse visible solo cuando la aplicación ya está vinculada a recetas, alarmas, informes, archivado y procedimientos de mantenimiento. En ese momento, incluso una corrección aparentemente simple, como separar cuentas, cambiar el flujo de aprobación de una operación crítica o limitar el acceso remoto a un modo puntual, deja de ser un simple cambio en las pantallas. Requiere rediseñar la lógica, volver a probar la gestión de alarmas, definir responsabilidades y, con frecuencia, introducir también cambios organizativos en la planta.

En la práctica, el punto de partida más razonable es un mapa de trabajo de los roles de usuario y sus permisos sobre operaciones críticas, una lista de funciones que provocan cambios en el estado del proceso, en la configuración o en las recetas, y una relación de conexiones externas que incluya servicio, informes, sistemas de nivel superior y acceso remoto. Solo sobre esta base puede diseñarse con sentido la arquitectura de zonas y conexiones, así como preparar el análisis de riesgos posterior. Este enfoque responde tanto a la práctica de la ingeniería como a las exigencias de ordenar responsabilidades, separar funciones y controlar la comunicación en entornos de automatización industrial.

Dónde aumentan realmente el coste y el riesgo

El mayor coste y riesgo en una aplicación HMI/SCADA no se derivan únicamente del hecho de conectar sistemas, sino de las consecuencias operativas y organizativas que generan las distintas funciones de la aplicación. Los puntos más sensibles son aquellos que permiten cambiar consignas con rapidez, introducir una anulación, silenciar una alarma, modificar una receta o ejecutar un mando manual sin disponer de todo el contexto tecnológico. Si el diseño permite este tipo de operaciones desde la pantalla de producción en modo rutinario, el riesgo aumenta porque una sola decisión del usuario o una sola sesión comprometida puede cambiar directamente el estado del proceso.

Esto significa que el catálogo de operaciones críticas debe tratarse como un elemento de la arquitectura de seguridad, y no únicamente como una cuestión de ergonomía de la interfaz. El mismo principio se aplica a la trazabilidad de las acciones. Los inicios de sesión compartidos, las cuentas usadas por todo un turno, la falta de separación de permisos de lectura, control, configuración y administración, así como un registro de eventos insuficiente, hacen que tras un incidente resulte difícil determinar con rigor si se produjo un error, una omisión del procedimiento, un uso indebido del acceso de servicio o una actuación no autorizada. El problema no se limita a investigar las causas. Sin un rastro fiable de las acciones del usuario, tampoco es posible evaluar la eficacia de los procedimientos, gestionar los permisos de forma razonable ni justificar las decisiones operativas ante una auditoría interna, los requisitos del cliente o las políticas de seguridad adoptadas. En la práctica, aquí se trata de la trazabilidad de las acciones y de la posibilidad real de identificar quién hizo qué, y no solo del mero registro de eventos.

Otro error de diseño muy costoso es trasladar al entorno de producción pantallas de servicio y diagnóstico complejas, preparadas originalmente para la puesta en marcha o para el soporte del integrador. Estas vistas suelen ofrecer un acceso amplio a variables internas, forzado de estados, borrado de bloqueos y modificación de parámetros, aunque en la operación normal solo se necesiten de forma puntual. Si no se someten a restricciones adicionales, se convierten en la vía más directa para intervenir en el proceso al margen del recorrido habitual del operador. Una solución razonable consiste en separar el diagnóstico necesario para mantenimiento de las funciones que permiten intervenir en la lógica de funcionamiento, así como decidir por separado si el diagnóstico del fabricante de la máquina debe estar disponible localmente, en remoto o solo de forma condicionada, tras una activación consciente y con registro completo de la sesión.

La integración con bases de datos, sistemas de informes, soporte remoto y sistemas de oficina debe abordarse del mismo modo. Cada una de estas conexiones mejora la comodidad de trabajo, pero al mismo tiempo incrementa el número de dependencias que pueden convertirse en vía de entrada, fuente de perturbaciones o causa de pérdida de claridad en las responsabilidades. El fallo de un servicio intermediario, una sincronización horaria incorrecta, un intercambio de datos no controlado con el sistema superior o un canal de servicio dejado abierto pueden afectar no solo a la disponibilidad de los informes, sino también a las decisiones que toma el operador.

Por eso, ya en la fase de diseño conviene medir no solo la disponibilidad de las pantallas, sino también indicadores más simples y útiles: el número de operaciones críticas posibles desde el HMI de producción, el número de conexiones externas activas, el número de cuentas con privilegios y el alcance de los eventos cubiertos por la pista de auditoría. Este tipo de revisión facilita después el registro de eventos, el control de cambios de parámetros y las reglas de acceso remoto.

La gestión de alarmas requiere un tratamiento específico. En este ámbito, una aparente exhaustividad suele ocultar una falta real de control. Un diseño deficiente de las alarmas y del historial de eventos no solo sobrecarga al operador, sino que además le priva de la capacidad de distinguir las señales críticas del ruido técnico. Si una alarma puede silenciarse fácilmente sin justificación, confirmarse sin referencia a la causa o perderse entre una masa de mensajes de diagnóstico, la aplicación deja de respaldar la seguridad del proceso. Por eso, las prioridades de las alarmas deben derivarse de su impacto real sobre las personas, la máquina y la calidad de la producción, y seguir vinculadas a las reglas de registro de confirmaciones, anulaciones y cambios de consignas. Es precisamente en este punto donde el análisis de riesgos deja de ser un documento formal y empieza a dar forma a la interfaz.

Cómo diseñar para limitar las consecuencias del error y del uso indebido

El punto de partida es sencillo: una aplicación HMI/SCADA no puede asumir que todos los usuarios actúan siempre correctamente y dentro del contexto adecuado del proceso. El diseño debe comenzar por la separación de funciones, no por dibujar pantallas. El equipo debe definir primero qué debe ver únicamente el operador, qué puede confirmar, qué se le permite modificar en el curso normal del trabajo y qué acciones deben trasladarse al modo de servicio, quedar sujetas a una autorización adicional o aislarse por completo en una herramienta o estación independiente.

Esta decisión ordena toda la arquitectura de acceso: los roles, el alcance de los permisos, la forma de registrar las acciones y las condiciones del soporte remoto. En la práctica, funciona bien una matriz de roles basada en responsabilidades reales, que distinga entre operador, jefe de equipo, mantenimiento, tecnólogo, integrador y administrador. No se trata de una mera formalidad. Si las funciones de servicio permanecen en la misma pantalla y bajo la misma cuenta que la operación del proceso, la propia aplicación crea una vía para el error, la omisión del procedimiento o el uso indebido de privilegios.

Un buen HMI/SCADA limita la posibilidad de ejecutar por accidente una operación peligrosa, pero no ralentiza innecesariamente las tareas rutinarias. Esto exige un contexto de trabajo claro: el usuario debe ver sobre qué equipo está actuando, en qué estado se encuentra el proceso, si opera localmente o en remoto y si el sistema está en modo automático, manual o de servicio. Las confirmaciones deben ser proporcionales al riesgo, no iguales para todas las acciones. Allí donde la consecuencia del error es reversible y limitada, normalmente basta con una única autorización. Las operaciones críticas requieren un control adicional: una segunda confirmación, una nueva autenticación, una dependencia del estado del proceso o el paso físico a una interfaz segregada.

También son importantes los bloqueos condicionados. Si la aplicación permite cambiar una consigna, forzar una señal o entrar en modo manual con independencia del estado del equipo, el riesgo se traslada del diseño al operador. Es precisamente aquí donde se ve que un diseño correcto de la interfaz no consiste solo en facilitar el manejo, sino en limitar las consecuencias del error mediante barreras integradas. En muchos casos, esta forma de pensar se acerca a cómo funciona el Poka-Yoke en líneas de producción.

El diseño por capas del acceso también debe incluir la forma en que se utilizan los permisos a lo largo del tiempo. Las cuentas individuales son imprescindibles allí donde se exige trazabilidad de las acciones. Una cuenta compartida elimina la posibilidad de determinar quién tomó realmente una decisión. El principio de privilegio mínimo significa que el usuario recibe únicamente las funciones que necesita para su trabajo actual, y que la elevación de permisos se produce de forma temporal y en condiciones controladas. Esto afecta especialmente al mantenimiento, al integrador y al soporte remoto del fabricante. Una vía de servicio permanente y abierta solo resulta cómoda en apariencia, porque elimina la frontera natural de confianza entre la operación y el servicio técnico. Un modelo más seguro es el acceso activado bajo demanda, limitado en el tiempo, asignado a una persona concreta y registrado en el historial de eventos. Este enfoque encaja bien con el principio de privilegio mínimo y la segmentación del acceso.

Con el mismo criterio, hay que decidir si las funciones de servicio deben estar disponibles desde el HMI de trabajo o exclusivamente desde una estación independiente, y si se deben permitir soportes extraíbles y la importación o exportación local de datos desde el panel de operador. Estas decisiones no son secundarias. De ellas depende que la mantenibilidad del sistema se lleve a cabo de forma controlada o mediante soluciones improvisadas.

Desde la perspectiva de un incidente o de una controversia operativa, la propia interfaz no basta. La aplicación debe dejar evidencia que permita reconstruir la secuencia de decisiones. El historial de eventos, los registros del sistema y el registro de cambios deben responder conjuntamente no solo a la pregunta de qué ocurrió, sino también quién, cuándo, desde qué ubicación y en qué estado del proceso realizó la operación. El alcance mínimo de eventos que normalmente conviene registrar incluye el inicio de sesión, el cambio de permisos, el cambio de parámetros, la entrada en modo manual, la confirmación de alarmas y la importación de configuración. Es fundamental vincular el registro con el contexto tecnológico, porque la mera información de que hubo un cambio, sin el estado del equipo, a menudo resulta inútil.

Un buen ejemplo, habitual en muchas implantaciones, es el siguiente: un cambio del umbral de alarma por parte del tecnólogo puede ser admisible, pero solo tras entrar en el modo previsto, dejando constancia del usuario, la estación, la hora, el valor anterior y el nuevo, así como la confirmación de que el equipo no se encontraba en estado crítico. Este rastro es importante tanto para la seguridad como para la gestión del cambio en aplicaciones industriales.

La última capa es la mantenibilidad sin eludir las protecciones. Si una actualización, la restauración de la configuración o el diagnóstico exigen desactivar el control de acceso, utilizar una contraseña compartida o trabajar sin rastro de auditoría, el problema está en el diseño y no en la disciplina del personal. La aplicación debe contar con un flujo de cambio previsto: solicitud, evaluación del impacto, prueba, implantación, confirmación y plan de reversión. También debe separar el entorno operativo del de servicio al menos de forma lógica y, cuando esté justificado, también organizativa y técnicamente. Las copias de configuración deben poder realizarse y restaurarse de forma controlada, sin exportaciones improvisadas «por si acaso» desde el panel. Este enfoque es coherente con el principio de privilegio mínimo en OT y con los requisitos relativos al control de acceso, la trazabilidad de las acciones y la gestión del cambio, aunque su alcance siempre debe referirse a la arquitectura del sistema y al reparto de responsabilidades adoptado.

Práctica de implantación y referencia a los requisitos

Lo que más aporta no es añadir más mecanismos de protección al final del proyecto, sino una revisión ordenada de la aplicación antes de la recepción o de la modernización. Ese es el momento en el que todavía se puede corregir, con un coste relativamente bajo, la forma de funcionamiento del sistema, en lugar de tener que rodear más tarde unos supuestos erróneos con procedimientos adicionales. Esta revisión debe llevarla a cabo un equipo mixto: proyecto, mantenimiento, operación, automatización y las personas responsables de la seguridad.

El objeto de la evaluación no es únicamente la configuración técnica, sino comprobar si la aplicación realmente separa roles, protege las operaciones críticas, limita el acceso remoto a los casos justificados, garantiza una gestión clara de las alarmas, conserva el historial de cambios y permite realizar copias y procedimientos de emergencia sin eludir las protecciones. Precisamente de esta revisión debe salir la lista para FAT/SAT y los requisitos que se incorporan a la recepción, al plan de servicio y a la documentación final de obra.

Este enfoque desplaza el centro de gravedad desde el debate sobre las propias medidas de protección hacia las decisiones de diseño, que después determinan el comportamiento de las personas y de los equipos. Si ya en la fase de proyecto no se define quién puede modificar los parámetros de las recetas, quién autoriza el modo de servicio, cómo se registra la intervención del integrador y en qué condiciones se permite el acceso desde fuera de la planta, una vez puesto en marcha el sistema acabará apoyándose en excepciones y acuerdos verbales.

Por la misma razón, conviene decidir si la evaluación de la aplicación debe realizarse dentro de la modernización de la máquina o de la línea, o como una revisión OT independiente. El primer enfoque vincula mejor la seguridad con la función del proceso; el segundo facilita detectar las dependencias entre sistemas y el reparto de responsabilidades sobre cuentas, permisos y registro de actividades. Este es también el lugar natural para un análisis preliminar de riesgos: identificar operaciones críticas, límites de confianza y consecuencias de un error del operador o de un uso indebido. En la práctica, también puede resultar útil el análisis de riesgos dentro del proyecto.

• los roles de usuario y la forma de autenticación,
• las operaciones críticas y las reglas para su confirmación,
• el acceso remoto y las funciones de servicio,
• las alarmas, el registro de cambios y la trazabilidad de las acciones,
• las copias, la restauración y los procedimientos de emergencia.

En planta, un buen resultado rara vez se debe a implantar muchas herramientas a la vez. Normalmente tiene más impacto eliminar unos pocos riesgos sistémicos que durante años se consideraron prácticos. La modernización de una aplicación HMI/SCADA puede empezar por suprimir las cuentas compartidas, separar las funciones de servicio de las funciones de operación, limitar las conexiones externas a rutas controladas y activar una traza de cambios de parámetros asignada a una persona o rol concretos. Este cambio no tiene por qué dificultar el trabajo de mantenimiento ni del integrador, siempre que desde el principio se hayan previsto el modo de servicio, las reglas de autorización y un proceso reproducible para las modificaciones.

Durante la explotación, conviene medir no un nivel abstracto de seguridad, sino indicadores útiles desde el punto de vista operativo: el número de cuentas compartidas que siguen existiendo en el sistema, el alcance del acceso remoto activo, la integridad de los registros de cambios, el tiempo de restauración de la configuración y el número de intervenciones realizadas fuera del procedimiento formal. Estos indicadores permiten evaluar si el proyecto realmente redujo el riesgo o si simplemente lo trasladó a la práctica diaria.

En el contexto polaco y de la Unión Europea, cada vez es más difícil sostener un enfoque en el que la ciberseguridad de HMI/SCADA sea un asunto exclusivo del departamento de TI. La responsabilidad se reparte entre proyecto, explotación, mantenimiento, proveedores e integradores, y los requisitos sectoriales y contractuales solo adquieren valor cuando la organización puede mostrar hechos concretos: qué decisiones de diseño se tomaron, cómo se asignan los permisos, cuál es la traza de las acciones y quién controla los cambios. Las simples referencias a normas, políticas o cláusulas contractuales no sustituyen la prueba de que la aplicación se ha diseñado y aceptado de una manera que permita una explotación segura.

La conclusión más importante es práctica. El momento más barato y más eficaz para reducir el riesgo sigue siendo el diseño y la aceptación de la aplicación. Es entonces cuando, con el menor coste, se definen los límites de confianza, los roles, las condiciones de acceso, la traza de acciones y la forma de gestionar los cambios. Si estos requisitos se traducen en criterios verificables para el proveedor y el integrador, HMI/SCADA deja de ser una interfaz cómoda pero excesivamente confiada y pasa a convertirse en una herramienta para la explotación segura del proceso, en línea con un enfoque de seguridad desde el diseño para la industria.