Registrando eventos en sistemas de control para mejorar la seguridad

Analizar las ventajas de desplegar gestores de logs propios, e independientes de la solución del SCADA, puede ser clave para descubrir lo que ha pasado o está pasando, e intuir lo que puede pasar, desde un punto de vista de ciberseguridad. Eso sí, siempre hay que intentar exprimir al máximo los logs ya disponibles en los propios dispositivos industriales que, aunque puedan tener una orientación más operativa, también pueden ser muy valiosos desde un punto de vista de ciberseguridad.

Repaso a los logs en sistemas de control

En el artículo “La evolución del software en los sistemas de control industrial” ya se comentó la evolución de los logs o registros de eventos desde los primeros equipos hasta la última generación de dispositivos:

• Primera generación: no se registra ningún tipo de actividad.
• Segunda generación: se generan logs relacionados con el mantenimiento/salud del mismo (uso de CPU, temperatura, cambio de ciertas variables, etc.).
• Tercera generación: la concienciación en seguridad comienza a aparecer sobre los sistemas de control y ya se registran diversos eventos relacionados con la seguridad (accesos de usuario, cambios en ciertas configuraciones, etc.), pero los eventos registrados seguían siendo escasos.
• Última generación: ya existen registros de eventos que recogen todo tipo de acciones, además, se separan en ficheros dependiendo si hacen referencia a la seguridad, al mantenimiento, etc.

Que la generación de eventos relevantes vaya en aumento tiene repercusiones sobre los propios dispositivos, ya que los ficheros en los que se almacenan cada vez son mayores y eso implica la necesidad de mayor espacio libre en los discos. Este aspecto debe tenerse en cuenta, y debe valorarse el tamaño máximo del log (número máximo de eventos registrado), el momento en el que comienzan a sobrescribirse eventos (log cíclico), etc., puesto que los dispositivos tratan de hacerse con los recursos mínimos para su funcionalidad con la intención de que el precio sea lo más ajustado posible.

Eventos de seguridad vs. Eventos de control

Tradicionalmente, los operadores de los sistemas de control solo estaban interesados en que su sistema funcionase de forma adecuada. Para hacer un seguimiento, disponían de alarmas sobre diferentes eventos de control que eran relevantes para ellos, habitualmente relacionados con cambios en determinadas variables. Con la incursión de la seguridad sobre estos sistemas y el cambio de paradigma en el pensamiento, los eventos relacionados con la seguridad se hicieron cada vez más necesarios, hasta convertirse en algo imprescindible en la actualidad.

Hoy en día, ambos tipos de eventos tienen la misma relevancia para un sistema de automatización y control industrial. Los eventos de control son importantes para la operativa, ya que permiten ver que el proceso se está llevando a cabo de manera correcta. Además, los eventos de seguridad son necesarios para conocer si existen indicios de anomalías que pueden proceder de un ataque, ya sea intencionado o no. En cualquiera de los casos, el registro de eventos debe realizarse de tal manera que permitan la identificación de un incidente con consecuencias sobre el proceso y, siempre que se pueda, en las fases iniciales.

Los principales eventos relacionados con la seguridad que deberían registrarse para ser útiles en análisis posteriores, tipo forense, son:

• Inicio y fin de sesión de aplicaciones.
• Inicio y fin de sesión local.
• Intentos de acceso fallidos.
• Nombre de usuario y perfil / roles de acceso.
• Fallo de conexiones de red.
• Todas las acciones sobre los usuarios: añadir, borrar, cambio contraseña, cambio de roles, etc.
• Definición de nuevos roles en la aplicación.
• Modificación de lógica de control.
• Uso de funciones no permitidas / privilegiadas, incluso los intentos.
• Reinicios, tanto del propio equipo como de servicios por parte del “watchdog” (técnica utilizada para detectar y recuperar fallos del sistema).

Monitorización y gestión de logs

Disponer de los logs en un fichero, por muy completos y muchos eventos de seguridad que se hayan registrado, no sirve de mucho si no se realiza un seguimiento de los mismos. Para el seguimiento, monitorización o gestión de logs, actualmente se utilizan de forma muy habitual herramientas automatizadas que se encargan de normalizar los logs de diferentes fuentes. Los scripts personalizados y las plantillas de informes rudimentarios han dado paso a sofisticadas aplicaciones de gestión de logs.

En el artículo “Monitorización de amenazas en SCADA” se mencionan algunas herramientas, como los SIEM, utilizadas para la gestión de los logs. Aunque para que estas herramientas sean capaces de “hacer su magia” requieren que la información llegue hasta ellas. El envío de logs hasta las herramientas encargadas de su gestión puede hacerse de dos maneras:

• Sistemas integrados en los propios sistemas operativos: de forma nativa, los sistemas operativos disponen de mecanismos para el envío automatizado de los logs hacia otros sistemas. Uno de los mecanismos más habituales se denomina Syslog, y es un estándar de facto para el envío de mensajes a través de redes IP.
• Agentes propios de las herramientas: en determinados entornos no existe un mecanismo normalizado, para estas ocasiones, las herramientas de monitorización disponen de agentes especiales para diversos dispositivos que permiten el envío de los logs hasta el sistema centralizado.

Sin embargo, disponer de los logs normalizados en un equipo centralizado aporta poco a la seguridad si no se definen indicadores, reglas de correlación o acciones a realizar a partir de toda la información obtenida.

Qué busco y qué me aporta

Las principales acciones que deben hacer saltar las alarmas son las mismas que se pueden observar sobre el mundo TI, y generalmente están relacionadas con el control de accesos. No obstante, el mundo TO tiene sus acciones específicas que también deben perseguirse. Entre ellas se pueden destacar:

• Uso de funciones no permitidas: seguramente la mayoría ya están controladas tanto por IDS/IPS, como por cortafuegos con inspección de estados en protocolos industriales, pero el aviso para que el técnico pueda investigar un poco más el origen y la razón de la petición puede aportar más datos.
• Cambios de configuración: el arranque de un dispositivo suele indicar la versión de binarios que utiliza, disponer de una base con la que comparar estas versiones permite identificar posibles cambios no autorizados.
• Fallos de comunicaciones: aunque un micro corte pueda ser un aspecto normal dentro de un sistema de control, un evento de fallo de comunicaciones en varios equipos a la vez puede suponer un indicio de ataque.
• Accesos privilegiados: los accesos privilegiados no son necesarios en un sistema de control. Se realizan en ocasiones puntuales para las modificaciones de la programación, pero durante una operativa normal el usuario estándar (denominado operador y operator) es suficiente. Por este motivo, encontrarse con varios accesos privilegiados en un corto espacio de tiempo sobre el mismo o varios equipos cercanos debe ser una alerta.
• Escaneos de red: algunos protocolos industriales permiten el envío de mensajes a todos los elementos de la red (mensajes broadcast) y otros responden siempre a determinados mensajes de control, lo que permiten hacer un inventario de los elementos que la componen. El operador de la infraestructura ya debería conocer los componentes de la misma y no requiere de estas acciones, por lo que deben ser adecuadamente controladas.

Evidentemente, todas estas acciones no son válidas si no se realiza una correcta configuración de los servicios de generación de log. Utilizar la configuración por defecto puede aportar valor, pero hacer una revisión y configurarla adecuadamente, siguiendo los criterios de la organización, hará que la gestión automatizada sea satisfactoria y facilitará el trabajo de los administradores y equipos de seguridad, además de aumentar el valor de la información generada permitiendo conseguir resultados más óptimos. Aparte de configurar los eventos a registrar, no debemos olvidarnos de configurar correctamente la manera de trabajar del log y el espacio máximo que pueden llegar a ocupar los eventos registrados. Y por supuesto, lo más importante de todo: la sincronización horaria. Si las máquinas no disponen de la misma fecha y hora, el análisis de los eventos recopilados no podrá llevarse a cabo de manera correcta. Hoy en día la sincronización vía GPS está muy extendida, lo que simplifica que los relojes de los dispositivos se encuentren en sincronía.

¿Y tú como tienes montado el sistema de monitorización en tu sistema de control? ¿Aún no usas una herramienta de centralización? Configura los logs de tus dispositivos, será como prender una antorcha en medio de una cueva oscura.