Cómo implementamos el segundo SIEM en el centro de respuesta y monitoreo de ciberataques

Una cabeza es buena, pero dos no son hermosas ... Eso pensamos mientras vivíamos en una época maravillosa, cuando solo había una plataforma SIEM en nuestro centro para monitorear y responder a los ciberataques. No es ningún secreto que fue HP ArcSight, que resultó ser el único finalista de un largo maratón a través de las espinas de demandas, deseos y planes ambiciosos para construir el corazón de SOC.



Y nada parecía ser un buen augurio, pero en algún momento, aparecieron pensamientos sobre la necesidad de trabajar con una plataforma alternativa y se volvieron cada vez más persistentes. Y la locomotora principal aquí fue el desarrollo activo de los centros GosSOPKA. Para convertirnos en uno de estos centros, tuvimos que utilizar el software que se proporciona"Garantía y soporte técnico de organizaciones rusas que no están bajo el control directo o indirecto de personas físicas y (o) jurídicas extranjeras" (Orden del FSB de fecha 06.05.2019 No. 196, cláusula 3.4). Cómo sufrimos todo esto pasó y qué pasó al final, lo contamos a continuación.





Tomada de la serie animada "Catdog"



Hemos escuchado que hay SOCs que profesan la poligamia, multi-vendedor y dicen (y este tipo de actividad, como recordamos, es muy diferente a la descarga de bolsas) que están listos para trabajar con cualquier solución SIEM extendida en el mercado. Por qué es imposible implementar un enfoque de este tipo de manera cualitativa, lo comprenderá a partir de la descripción a continuación. Nos apegamos tanto a ArcSight y logramos construir un ecosistema completo de soluciones y procesos a su alrededor que incorporar un SIEM alienígena se convirtió en un verdadero desafío y nos planteó una serie de preguntas difíciles:

1. ¿Qué solución elegir?
2. ¿Cómo integrar el nuevo sistema SIEM en la operación TIER1?
3. ¿Cómo se pueden transferir todas las integraciones internas que ArcSight actualmente tiene a la nueva plataforma?
4. ¿Cómo sincronizar la ideología de desarrollo de contenido SIEM y proporcionar conjuntos simétricos de reglas de detección?

Elegir una solución no fue tarea fácil. En todas partes tuvimos que sumergirnos en un remolino, cuya profundidad no teníamos nada que estimar. Como resultado, decidimos tomar una decisión de una manera diferente: utilizar SIEM del proveedor, quien nos prometió una alta prioridad de mejoras de acuerdo con nuestros requisitos y en cuyas promesas creíamos. Así nació una alianza tecnológica con Positive Technologies y MaxPatrol SIEM apareció en el embudo de nuestros SIEM.

Ok, tenemos una nueva plataforma. ¿Pero quién trabajará con ella?

Para ser sincero, al principio teníamos la sensación de que no podíamos prescindir de un segundo equipo trabajando en paralelo con el nuevo conjunto de herramientas. Este sentimiento se vio reforzado por el hecho de que incluso las líneas de analistas senior que participaron en las pruebas del segundo SIEM lo encontraron difícil de aceptar. Por tanto, en un principio, el concepto se trazó de la siguiente manera: dos líneas TIER1, cada una afilada con su propio instrumento, y la TIER2 multiplataforma. Con el factor de preparación multiplataforma como factor de crecimiento para un especialista de T1 a T2.



Fue en esta época cuando acumulamos suficientes razones para dividir nuestro primer carril en TIER1 y TIER2 (más sobre esto en otra serie de artículos). Y dado que en el concepto inicial T2 debería funcionar con ambas plataformas, convertimos todos los incidentes de MP SIEM en el segundo carril, formado por los primeros luchadores más experimentados que estaban inmersos en el trabajo con el nuevo SIEM. De cara al futuro, diré que los ingenieros de la segunda línea percibieron el MP SIEM de manera más positiva que sus colegas analistas senior; esto nos dio la esperanza de que la plataforma podría aterrizar completamente en la primera línea y no cerca de varios especializados.



El tema de la integración en un solo ecosistema tampoco fue tan doloroso como esperábamos; quizás fue ayudado por el hecho de que la flexibilidad y la redundancia de configuración se incluyeron inicialmente en los mecanismos de integración desarrollados. No hubo victorias particularmente grandes de las que quisiera presumir. Rápidamente incorporamos el nuevo sistema en el ecosistema y los procesos de investigación, y ahora el procesamiento de incidentes de varios SIEM difiere para los chicos solo en la interfaz del SIEM mismo. Todos los mecanismos de enrutamiento y priorización, toda la información enriquecedora para la toma de decisiones, todas las plantillas de notificación son idénticas y se encuentran en los mismos lugares familiares.

¿Y el contenido?

No llegará lejos con un SIEM “vacío” sin contenido (reglas para correlacionar eventos de seguridad de la información e identificar incidentes) y no podrá identificar muchas amenazas (no usamos contenido en caja), por lo que surgió la tarea de desarrollar rápidamente reglas de correlación en una nueva plataforma para escenarios JSOC ya existentes. Al principio, decidimos arreglárnoslas con un poco de sangre y transferir las reglas de ArcSight copiando la lógica de implementación, pero resultó ser un error, en el que nos quemamos seriamente: una arquitectura de producto completamente diferente requería "su propio" enfoque de desarrollo. Tuve que formar este enfoque, y a un ritmo acelerado. La interacción cercana con el proveedor ayudó mucho, quien asesoró sobre problemas emergentes, tomó en la implementación de nuestras solicitudes de revisión de chips existentes y creación de nuevos en la funcionalidad.La otra cara de la moneda es que teníamos que reescribir el contenido regularmente para que funcionara correctamente en esta nueva funcionalidad. Pero, como dicen, cambia o muere, así que no nos quejamos (bueno, excepto quizás dentro del equipo con un vaso de té).



En la etapa inicial, solo los analistas experimentados de cuarta línea, que se comieron el perro mientras trabajaban con ArcSight, participaron en el desarrollo de contenido para el nuevo SIEM. Curiosamente, algunos chicos ya habían sufrido una deformación profesional en ese momento y habían formado una "dependencia" de un SIEM específico con su alto nivel de madurez. Cambiar a una nueva plataforma fue difícil para ellos tanto psicológica como técnicamente. Más tarde, el equipo de desarrollo se amplió significativamente con nuevos miembros, incl. chicos de la tercera línea, y solo para ellos, este tema despegó mucho más fácil y, a menudo, incluso más productivo.



A pesar de la lista transversal de escenarios para ambos SIEM, su implementación puede diferir significativamente, principalmente debido a limitaciones en la arquitectura y funcionalidad de diferentes plataformas. Por ejemplo, en ArcSight, en la regla de correlación, no puede especificar una verificación de la existencia de un registro en la hoja activa por coincidencia no estricta, pero en MP SIEM puede hacerlo. Por otro lado, MP SIEM no genera eventos internos para agregar o eliminar un registro de la lista de la tabla, pero ArcSight puede hacerlo, y en varios escenarios se utiliza esta función. Tuve que vivir con una personalidad dividida para introducir la "línea dual" en nuestra base de conocimientos sobre scripts JSOC y describir los matices de la implementación, así como sus propias herramientas de investigación para cada plataforma.



Al mismo tiempo, era muy importante transmitir a la 1ª línea que la lógica de la investigación de incidentes no depende del SIEM en el que se generen, y que el nuevo SIEM es una nueva herramienta para resolver todas las mismas tareas. Tiene características propias que hay que estudiar, pero nada cambia radicalmente.

Y el trabajo en la 1ra línea comenzó a hervir

La inmersión de TIER1 en el trabajo con MP SIEM procedió gradualmente y de acuerdo con el proceso, se depuró con la introducción de nuevos empleados. Se determinaron los criterios de incidencias, que no dan mucho miedo para ceder al análisis de la 1ª línea, que aún no tiene mucha experiencia con MP SIEM:

• detalles de incidentes críticos bajos (hosts / redes y cuentas sin clasificar);
• tiempos de SLA largos;
• baja intensidad laboral del incidente (hemos acumulado estadísticas mientras procesamos los incidentes en TIER2);
• reglas de correlación no muy furiosas (sí, la primera línea debería mirar allí).

Los escenarios de acuerdo con estos criterios se dividieron en varias etapas y se entregaron a los ingenieros de TIER1 uno por uno, después de pasar los "créditos" y obtener acceso a la solución del grupo de incidentes.



Como resultado, tenemos en nuestro portafolio de herramientas dos SIEM, en los cuales se lanzan escenarios absolutamente idénticos en esencia y lógica de procesamiento.



Alexey Krivonogov, director adjunto de Solar JSOC para el desarrollo de redes regionales