Para que el análisis sea sustantivo, primero arreglaremos que estamos comparando el SOC OT con la estructura del centro de monitoreo, que está implementado en nuestro JSOC Solar.
Entre otras cosas, nos permitirá discutir estas diferencias en el contexto de las tareas del centro GosSOPKA, que también es responsable de los segmentos industriales.
Los detalles sobre cada nivel del modelo se pueden encontrar en artículos anteriores sobre inventario de infraestructura , monitoreo , inteligencia de amenazas ( 1 , 2 ), control de seguridad , personal y procesos.... En el artículo actual, nos centraremos en el bloque central de Monitoreo de seguridad (las características de los procesos de respuesta e investigación en el sistema de control de procesos automatizado estarán en artículos adicionales).
El teatro comienza con una percha y el SOC comienza con el monitoreo
Parece que en el campo de la monitorización de eventos, la correlación y la detección de incidentes, todo ya está definido y conocido. E incluso cerrar la brecha de aire para recopilar eventos de seguridad es un tema bastante probado y verdadero . Pero, sin embargo, hay un par de matices a los que definitivamente vale la pena prestar atención.
Arquitectura general de SOC... A pesar de la solución aparentemente simple con un espacio de aire, la situación para las grandes empresas federales con instalaciones distribuidas (esto es especialmente cierto para la industria de la energía) es bastante complicada. La cantidad de objetos se mide en miles, a menudo ni siquiera es posible colocar un servidor de recolección de eventos en ellos, cada uno de los objetos es bastante compacto, pero puede generar eventos de seguridad de la información importantes. Además de la situación descrita, el problema de los canales de comunicación se superpone a menudo, tan estrecho que al menos alguna carga significativa en la transmisión de eventos al "centro" comienza a interferir con el funcionamiento de las principales aplicaciones.
Por lo tanto, cómo descomponer correctamente los componentes SIEM por sitios es una cuestión muy seria. Volveremos a él en uno de nuestros materiales adicionales, ya que
Especialización en casos de uso y elaboración de perfiles . Incluso sin tocar el tema de escenarios completamente especializados que son relevantes solo para el segmento ICS, vale la pena señalar que incluso los incidentes estándar en el ICS tienen un significado y una criticidad completamente diferentes. Todos estamos acostumbrados a utilizar herramientas de administración remota en una red corporativa. Pero es obvio que la criticidad de tal incidente, así como, en principio, de una comunicación exitosa con Internet en una red tecnológica cerrada, es enorme. Lo mismo ocurre con la instalación de un nuevo sistema de servicio en una estación de trabajo tecnológica, el hecho de detectar malware, que requiere una investigación obligatoria, etc.
Las restricciones significativas en el uso de Use-Case son introducidas por restricciones en la implementación de sistemas de seguridad de la información (generalmente, los segmentos tecnológicos no son muy ricos en ellos) y el uso de versiones obsoletas y heredadas de sistemas operativos (y los tecnólogos miran la instalación de Sysmon con desconfianza).
Sin embargo, un gran volumen de casos de uso del entorno corporativo se puede aplicar con éxito al segmento de ICS y proporcionar un nivel suficientemente alto de control general de la infraestructura.
Bueno, es difícil pasar por el lugar santísimo: sistemas SCADA... Si en el nivel del sistema de seguridad de la información, los sistemas operativos y los flujos de red, todos los segmentos son al menos ligeramente similares, entonces surgen diferencias clave cuando se profundiza. En términos de redes y segmentos corporativos, todo el mundo sueña con la monitorización empresarial y la conectividad de las aplicaciones empresariales. Y este proceso, aunque complejo (los logs mutan y no quieren pretender ser CEF, la información normal solo se puede obtener de la base de datos, pero los administradores juran y se quejan de la ralentización), pero generalmente implementado. En el segmento tecnológico, al conectar sistemas de nivel medio y alto, estos problemas se elevan a un absoluto en relación con la criticidad espacial del tiempo de inactividad tecnológico. Para dar los primeros pasos para conectar la fuente, necesita:
- Montar el stand y comprobar el éxito de la recepción de eventos
- Dibujar una solución arquitectónica general con todos los detalles técnicos.
- Acuerdelo con el proveedor en unos meses
- Vuelva a consultar en el stand del cliente con emulación de carga de combate
- Con mucho cuidado (como en el chiste sobre los erizos) para implementar la solución en la producción.
Tristeza, nostalgia, procesos comerciales. Y esto a pesar del hecho de que, por regla general, el equipo del APCS se caracteriza por un registro suficientemente amplio, completo, comprensible y de alta calidad.
Pero, afortunadamente (o por coincidencia), generalmente se puede implementar un enfoque diferente en los segmentos de ICS. La mayoría de los protocolos que contienen no implican cifrado o enmascaramiento de la información transmitida. Por lo tanto, uno de los enfoques más comunes para monitorear y analizar comandos de control es la implementación de sistemas de detección de intrusos industriales o firewalls industriales que le permiten trabajar con una copia o tráfico de red real y analizar protocolos y comandos de control con el registro posterior. Algunos de ellos, entre otras cosas, tienen un motor de correlación básico incorporado en su interior (salvándonos del horror de la normalización, categorización y creación de perfiles de eventos), pero al mismo tiempo no son un reemplazo completo del sistema SIEM.
, ,
Hacia adelante. Parecería que los problemas de inventario en la red ICS deberían ser los menos dolorosos. La red es bastante estática, el equipo está aislado de los segmentos comunes, hacer cambios en la arquitectura requiere todo un proyecto de trabajo. Un cuento de hadas sobre las redes corporativas: "Simplemente corrija el modelo e introdúzcalo en la CMDB". Pero, como es habitual, hay un matiz: para el segmento ICS, la aparición de cualquier equipo nuevo es uno de los signos sumamente importantes de un incidente o ataque, y debe ser identificado sin falta. Y con todo ello, los métodos clásicos de inventario (modos de funcionamiento ahorradores de los escáneres de vulnerabilidades) provocan las alergias más graves entre los tecnólogos, e incluso entre el personal de seguridad del sistema automatizado de control de procesos. No es infrecuente en una red corporativa cuando incluso el Análisis de inventario en un modo fallido en un momento desafortunado podría "poner" alguna aplicación específica.Naturalmente, nadie está preparado para asumir tales riesgos en el sistema de control de procesos automatizado.
Por lo tanto, la principal herramienta de inventario en el APCS (además del control manual) son los sistemas de análisis de tráfico de red y los sistemas de detección de intrusos industriales mencionados anteriormente. Cada nuevo nodo, habiendo aparecido en la red, comienza a comunicarse con sus vecinos. Tanto los métodos como los protocolos de comunicación, la especificidad de los paquetes y los campos de servicio permiten no solo ver rápidamente al nuevo "vecino", sino también identificarlo claramente.
Por el contrario, el proceso de identificación y gestión de vulnerabilidades es más conservador. Como regla general, la infraestructura se actualiza y parchea con poca frecuencia y de manera muy controlada; la lista de software de aplicación y equipo tecnológico es fija. Por lo tanto, para determinar la lista y el estado de las vulnerabilidades actuales en el segmento ICS, generalmente es suficiente determinar el control de versiones del software clave y verificar los boletines de los fabricantes. Como resultado, nos estamos alejando del modo de escaneo agresivo y verificación de software a los métodos de auditoría y análisis de versiones técnicas y manuales de un experto de la industria.
El proceso de análisis o identificación de amenazas se construye de manera similar. Como regla general, un modelo fijo de una sola vez se moderniza cuando se realiza una reconstrucción crítica de la infraestructura (agregar nuevos nodos, actualizar la versión de firmware de equipos críticos, etc.) o al revelar una nueva vulnerabilidad relevante para la infraestructura y / o un nuevo vector de ataque. Sin embargo, con ellos tampoco todo es tan sencillo.
OT Threat Intelligence o ¿las redes aisladas sueñan con indicadores de compromiso?
¿Podría ser inútil la información sobre nuevas amenazas y vectores de ataque? Me gustaría responder inmediatamente "no", pero juntos intentemos comprender la aplicabilidad de los datos de TI clásicos en el segmento de OT maduro.
Los TI suelen ser feeds (flujos de datos) o IoC (indicadores de compromiso para identificar malware específico o herramientas de piratería). Contienen las siguientes características:
- (IP-, URL, ), upload «» , . , , . , , «» .
- (MD5- , , / ..), / / . , . , , , , whitelisting, , . – «» . TI .
Como resultado, para los ataques dirigidos a ICS, la información sobre TTP, tácticas y enfoques de los atacantes, lo cual es extremadamente raro en el mercado de TI, y las tácticas y enfoques de los atacantes ante un ataque, que permitirán adaptar los mecanismos y enfoques de defensa para monitorear e identificar amenazas en el segmento, cobra mucho mayor peso.
Estos y muchos otros matices nos obligan a adoptar un enfoque muy serio y reflexivo del proceso de construcción de dicho SOC o la elección de un contratista, así como a pensar seriamente en la estrategia para formar un OT SOC. Si se cruza con el SOC IT o funciona de forma separada de él, es posible que se resuelva algún tipo de enriquecimiento mutuo y sinergia en procesos, equipos y tareas. En nuestro próximo artículo, intentaremos destacar los diferentes enfoques de los equipos internacionales sobre este tema. Esté seguro en todos los aspectos de su infraestructura y vida.