Respondiendo a incidentes industriales, SOC OT

SOC vs. SOC-OT, definición y retos

Un SOC es un centro de respuesta a incidentes, mientras que un SOC-OT, sigue siendo el mismo concepto, pero orientado al mundo industrial. Las grandes diferencias entre ambos pueden notarse en los retos que supone la implementación y creación de un SOC-OT.

Uno de los primeros retos dentro de la ciberseguridad en el mundo industrial guarda estrecha relación con la catalogación de incidentes realizada por las organizaciones. Generalmente, estos incidentes están relacionados con las brechas de seguridad, intrusiones en las redes, pérdida de visionado en los procesos y control en las redes industriales, etc. Es por ello que, uno de los pasos que podría ayudar a construir un centro de operaciones de seguridad para dar soporte a un entorno industrial, en adelante SOC-OT, se centra en conocer los últimos incidentes de ciberseguridad industrial sucedidos.

La recopilación de información sobre estos incidentes nos mostrará información valiosa, tanto a la hora de poder gestionar incidentes parecidos, como sobre la forma de anticiparnos a los diferentes retos que supone solventar un incidente de ciberseguridad en un entorno industrial. No debemos olvidar que la disponibilidad es uno de los pilares sobre los que se sustentan los procesos industriales y, por ello, el restablecimiento de la operativa en los procesos es prioritario.

Otro de los retos a tener en cuenta en el mundo industrial es la falta de información a la que se puede enfrentar nuestro centro de operaciones. No es nada extraño encontrar, tanto sistemas como protocolos propietarios sin documentación o sin especificación pública. El paso del tiempo y la sucesión de diferentes incidentes en el mundo industrial, desde Stuxnet, han sido suficientes argumentos de peso para mostrar a la comunidad que la seguridad por oscuridad o el aislamiento de los sistemas a Internet no son las mejores opciones a la hora de proteger los sistemas industriales.

Además de la falta de documentación o desconocimiento de ciertos puntos relacionados con dispositivos, sistemas o procesos, la falta de una entrada en los logs, de algunos sistemas, relacionados con eventos de seguridad, puede complicar el tratamiento de los incidentes de ciberseguridad en entornos industriales.

Sumado a todos los retos anteriormente expuestos, debemos incluir las normativas, regulaciones, requerimientos legales, etc., que a diferencia del mundo TI, afectan a las empresas industriales, dependiendo del sector y el objetivo de negocio que tenga la propia organización. Por ejemplo, si el incidente sucede en un proceso de una infraestructura catalogada como crítica, posiblemente la información que se esté manejando requiera de un tratamiento especial. En esta línea, se ha de tener en cuenta la transposición de la directiva NIS que, entre otras cosas, habla de las obligaciones que tienen ciertos operadores de reportar la incidencia tras un incidente o la normativa GDPR de obligado cumplimiento para empresas que realizan un tratamiento de datos sensibles. Al tratamiento de la información podemos añadir el tiempo de respuesta, ya que si en un entorno industrial la respuesta y solución del incidente ha de ser ágil, en una infraestructura crítica los tiempos manejados son aún más reducidos, debido a la importancia que tiene para un país este tipo de infraestructuras.

Una vez expuestos los retos más destacables a los que puede enfrentarse un SOC-OT, a continuación se expondrá la definición de objetivos y propósito que perseguirá el centro, así como los roles a repartir en los diferentes equipos que compondrán el centro y responsabilidades que asumirá cada integrante del mismo. Todos estos puntos han de completarse bajo un prisma industrial que diferenciará el SOC-OT de otro centro más orientado a la respuesta de incidentes TI.

Objetivo

Entre los objetivos a tener en cuenta, destaca el de mantener la disponibilidad en los procesos industriales, este ha de ser el objetivo principal para los equipos de respuesta a incidentes que se enfrenten a un problema en un entorno industrial. El problema más directo es la indisponibilidad de servicios o productos que pueden experimentar los clientes. Este hecho generaría una pérdida de confianza por parte del cliente. Posteriormente, podrá sobrevenir un impacto en la imagen debido a la repercusión mediática que derivará en más pérdida de confianza, etc. Los anteriores y otros problemas sobrevenidos, derivarán en pérdidas económicas o incluso en la quiebra o cierre de la empresa.

Además de mantener la disponibilidad, el entendimiento del incidente a lo largo de todas sus fases para aplacar sus posibles consecuencias forma parte de otro de los objetivos con mayor peso para los equipos multidisciplinares que pueden encontrarse con este tipo de incidentes. En este proceso se ven envueltas diferentes fases, desde la fase inicial de triaje (separación y clasificación de los incidentes) y monitorización desarrollada por el primer nivel definido en el SOC, hasta llegar al último nivel donde se encuentra un equipo mucho más especializado y con formación específica. En este último nivel, se suele encontrar el equipo de DFIR (Digital Forensics and Incident Response – Respuesta a incidentes y forense digital), encargado del análisis forense. Este equipo generará inteligencia (IoC, reglas YARA, reglas Snort, etc.) para que otros equipos de respuesta a incidentes se aprovechen de la misma.

Es importante tener en cuenta que la inteligencia sólo puede ser elaborada por analistas de seguridad y no por dispositivos desplegados a lo largo de la red. Los sistemas de detección de intrusos (IDS), cortafuegos y otro tipo de tecnologías para el análisis de actividad dentro de una red, las soluciones endpoint para la monitorización de actividad en los activos, los sistemas de autenticación y autorización, sumados a la posible inteligencia ya generada por otros equipos de respuesta a incidentes, proporcionan los datos necesarios para la posible detección de amenazas avanzadas.

-Origen de los datos para la detección de amenazas avanzadas-

Dentro del entendimiento del incidente se encuentran unas fases de recuperación y contención a tener en cuenta: los incidentes industriales originados por malware, como en el caso de Crashoverride. Gracias al uso de protocolos industriales, este malware avanzado permitía seguir infectando otros dispositivos que reunían las características que el propio malware verificaba antes de infectarlo.

En el caso de la recuperación, puede darse el caso de que la empresa posea copias de seguridad que tan sólo tendrá que restaurar. En estos casos, la situación podría complicarse si el malware tiene algún tipo de persistencia. Si la empresa no posee dichas copias de seguridad, la restauración puede no ser posible en caso de destrucción o cifrado malicioso de datos.

Por su parte, en la fase de contención, y dado que se está hablando de entornos industriales, el corte de comunicaciones o el apagado de equipos puede ser bastante complejo. De ahí que la segmentación en las redes industriales sea tan importante.

Ya desde un plano más secundario, la generación de inteligencia ha de ser otro de los objetivos a lograr por el SOC-OT. Dentro de estos contenidos encontramos Indicadores de Compromiso (IoCs), reglas Snort, reglas YARA, etc.

Además de su generación, es importante la compartición de los mismos Este concepto es llamado en inglés como “information sharing” y existen diferentes estándares a seguir para realizar esta compartición de información y, aunque cada uno posee sus pros y sus contras, el objetivo siempre es el mismo: compartir inteligencia para combatir las amenazas a las que se puedan ver expuestos los diferentes sistemas.

Roles y responsabilidades

Los roles y responsabilidades dentro del SOC-OT estarán estrechamente ligados al modelo de SOC elegido por la empresa que tiene pensado proporcionar este servicio.

Tomando como referencia un modelo multinivel, tendremos un esquema parecido al que se puede ver en la siguiente imagen.

-Ejemplo de personal requerido en un SOC-

• Director: intermediario entre SOC y empresa víctima de un incidente. Será el encargado de reportar la información y la inteligencia creada por los diferentes equipos que puedan coexistir en el centro. El director se encargará de comunicar los avances y mantener reuniones con la empresa víctima del incidente para mediar entre las posibles necesidades que pueda tener el mismo.
• Jefe de equipo: persona que gestionará el equipo o los equipos multidisciplinares dentro del centro. Es posible que, dadas las dimensiones o la especialización que puedan tener los equipos, exista un jefe por cada equipo.
• Analistas de nivel 1: la función de los analistas a este nivel será la de triaje y monitorización de incidencias.
• Analistas de nivel 2: en este segundo nivel, los analistas realizarán investigaciones básicas, darán posibles soluciones para solventar las incidencias y proporcionarán recomendaciones para realizar cambios en los sistemas con el fin de contener posibles propagaciones en el caso de una infección malware.
• Analistas de nivel 3: a este nivel trabajarán los perfiles más especializados, entre los que se pueden encontrar especialista en forense o ingenieros malware. Su objetivo será el de realizar tareas muy concretas, como reversing de malware, investigaciones forenses avanzadas, modelado de amenazas, etc.

Conclusiones

Aunque el concepto de SOC-OT, tal y como se desarrolla en este artículo, no está muy extendido, la estructura heredada de otros SOC focalizados en incidentes IT proporciona un buen punto de partida.

La creciente detección de amenazas gracias a las nuevas tecnologías de monitorización en entornos OT está proporcionando una visión que, para muchas empresas, era desconocida, entre otras cosas, por el pensamiento de falsa seguridad en los sistemas industriales.

Aunque existen varios retos a tener en cuenta antes de poner un SOC-OT en marcha, el servicio que proporcionará el mismo podría llegar a rentabilizar todo el esfuerzo invertido.