CISO de la Bolsa de Valores de Tel Aviv: Hacer un mejor uso de su SIEM

CISO de la Bolsa de Valores de Tel Aviv: Hacer un mejor uso de su SIEM

Para Gil Shua, sacar el máximo provecho del sistema de gestión de eventos de información de seguridad (SIEM) de la Bolsa de Tel Aviv se reduce a conseguir la relación señal-ruido adecuada. Eso y escribir las reglas correctas.

La relación señal-ruido, como todo ingeniero de radiofrecuencia sabe, se reduce a las cantidades de contenido real (señal) frente a perturbaciones estáticas y sonoras (ruido). Para Shua, el objetivo es minimizar la cantidad de ruido que se envía al SIEM en favor de contenido procesable. Está buscando algo que le haga levantarse de su escritorio y darse cuenta: “Tenemos un problema; Tenemos algo que queremos abordar ahora y solucionarlo”.

Shua ha trabajado en varios puestos de seguridad en la Bolsa de Valores de Tel Aviv (TASE) durante más de una década y fue nombrado CISO en 2022. Durante ese tiempo, dice, ha habido una “búsqueda constante de recursos de datos” para garantizar que la señal. La relación ruido-ruido se inclina a favor de los datos de señal para maximizar las capacidades y beneficios del SIEM del intercambio.

CISO de la Bolsa de Tel Aviv, Gil Shua

CISO de la Bolsa de Valores de Tel Aviv, Gil Shua. Fuente: Gil Shua, Bolsa de Valores de Tel Aviv

Filtrar el ruido

Shua y su equipo tienen mucho trabajo por delante, ya que con la mayoría de los SIEM, "se ve mucho ruido y poca señal". Esto genera falsos positivos y configuraciones erróneas, lo que, a su vez, genera trabajo adicional para el equipo de SOC, reduce la productividad y es un impedimento para intentando hacer funcionar un SIEM.

Para minimizar esto, Shua dice que el equipo SOC puede escribir reglas sobre cómo SIEM maneja los datos entrantes, pero la creación de esas reglas también requiere un tiempo valioso del equipo SOC.

Pero escribir reglas de correlación SIEM es relativamente fácil si la solución SIEM ya tiene reglas y análisis de registros predefinidos para la aplicación de informes, afirma Shua. Pero antes de que se puedan redactar las reglas, el equipo SOC debe: 

  • Descubra la estructura de datos e identifique los campos relevantes necesarios para la regla.
  • Comprenda la lógica de los sistemas de informes, ya que pueden tener sus propios estándares de registro.
  • Cree una correlación de reglas exacta y analice excepciones.
  • Realizar controles y pruebas de calidad.

Estos elementos de acción pueden tardar unas horas cada uno, pero si son más complejos, pueden tardar días en completarse, añade Shua.

“Cuando se establece un SIEM, surgen dos preocupaciones. Una es: "¿Tengo reglas que me protejan contra ataques relevantes... estoy cubierto por reglas efectivas?" La segunda pregunta es: '¿Recibo la información de los sistemas de informes que activarán estas reglas?'”.

La reciente incorporación de la plataforma CardinalOps ha mejorado Splunk Enterprise en TASE; Shua dice que el proceso de redacción de reglas se ha reducido enormemente, con 85 reglas producidas en los pocos meses que esta tecnología en particular ha estado en uso. “El equipo está más centrado en implementar reglas y probarlas y no en escribirlas, que fue el proceso que llevó más tiempo en el enlace”, añade.

Entonces, ¿merece la pena invertir tiempo y dinero en los SIEM en correlación y redacción de reglas? Shua admite que mantener un SIEM es una tarea exigente, ya que es necesario realizar actualizaciones y modificaciones constantes. A pesar de todo el esfuerzo, algunos ataques pueden pasar desapercibidos debido a la falta de visibilidad o de reglas de coincidencia.

"Espero que las soluciones futuras adopten capacidades de automatización para la creación y respuesta autónoma de reglas, listas para usar", dice Shua. 

Y debido a que los SIEM obtienen datos de muchas fuentes, deben volverse más eficientes en el procesamiento, análisis y almacenamiento de datos que se encuentran en diferentes formatos. "Hay que hacer ajustes para mantener", dice Shua, y agrega que una gestión inadecuada del cambio significa que es probable que una organización pase por alto algunos eventos de seguridad.

Sello de tiempo:

Mas de Lectura oscura