Reducir el Tiempo de Detección de Brechas: Disponibilidad de los Datos de Registro

¡Hola de nuevo! En el artículo anterior, ya establecimos que muchas cosas pueden salirse de control cuando uno se dedica a construir un SOC virtual o a gran escala, especialmente cuando se trata de operacionalizar el SIEM como la tecnología central de cualquier SOC. También establecimos que la automatización es el camino a seguir si uno quiere mantenerse al día con las amenazas modernas y la carga producida por las tecnologías de SIEM & SOC. Hoy comenzamos a analizar cada implementación y operación de SIEM pieza por pieza, la primera que viene a la mente es la disponibilidad de datos. Hay muchos factores que impactan el tiempo de detección de brechas y, a partir de 2015, todavía está por encima de un promedio de 200 días, pero esto no se debe a que SIEM sea una tecnología elegida para la detección de brechas. Un SIEM solo puede proporcionarte el resultado basado en las entradas que recibe, y si nos falta algo en la entrada, no debemos esperar que el resultado sea completo, procesable y, a veces, no tendremos ningún resultado en absoluto.¿Es realmente culpa del SIEM que pierda registros (e incidentes)? Bueno, esto nuevamente depende de muchos factores y para aclarar este desorden y mantener el SIEM continuamente operativo, la persona responsable de su administración/mantenimiento (¿tu empresa tiene uno, verdad?) necesita tener suficiente información en cualquier momento para responder estas dos preguntas: “¿Se están recopilando todos los datos de registro en el alcance?” y si la respuesta es NO “¿El problema está en el lado del SIEM o fuera de él?”. Si la respuesta a la primera pregunta es NO, ten por seguro que estás perdiendo cosas importantes que tienen un impacto directo en tu tiempo de detección de incidentes y precisión. Y la verdad es que ninguna solución de SIEM simplemente responde esto de manera predeterminada: siempre es un esfuerzo manual responder a esta pregunta.¿Alguna vez has visto un SIEM que diga “La disponibilidad de tus datos de registro de red es del 85%”? Yo no. Sin embargo, todavía tenemos una segunda pregunta que obviamente no es respondida por el sistema, ya que no puede responder a la primera. Pero, no todo está perdido y hay respuestas si uno hace suficiente investigación o ha dedicado suficiente tiempo y esfuerzo a buscarlas manualmente.Consideremos algunos ejemplos basados en cómo se recopilan los datos de registro y comencemos con el mecanismo de recopilación de registros más común – syslog. Es poco probable que uno pueda nombrar una implementación de SIEM que no use syslog en absoluto. Hay muchas maneras en que los datos se pueden perder con syslog: un demonio en el método de recopilación de piping pierde datos cuando el componente de recopilación se detiene; un protocolo syslog UDP (por defecto) no tiene garantía de entrega de paquetes, un alto volumen de tráfico syslog (tanto UDP como TCP) puede verse afectado por límites de tamaño de buffer y limitaciones de ancho de banda e incluso las especificaciones de procesamiento de velocidad de paquetes de un NIC concreto. Incluso en el caso de leer datos de registro de un archivo, uno debe considerar la rotación y la integridad del archivo. El diagnóstico de estos problemas siempre es una tarea rutinaria manual que involucra la lectura de registros de diagnóstico de los componentes de SIEM en sí mismos. ¡Si es que tiene datos de diagnóstico para empezar! Incluso los datos de diagnóstico más feos son mejores que no tener datos de diagnóstico en absoluto y una excusa barata de “oh, nuestro SIEM es tan mágico que no tiene errores”. Luego estaríamos ocupados construyendo (¿o reutilizando?) contenido de correlación que establece una línea de base de las cantidades de flujo de registro y desviaciones (¿Está alguien realmente satisfecho con los resultados de dicho contenido? ¿Qué pasa con los recursos que consume?), ejecutando TCPdump para verificar tasas de pérdida de paquetes, monitoreando la disponibilidad de componentes a través de fuentes externas… Espera, creo que hemos ideado al menos 3 herramientas adicionales que deben agregarse al SIEM para monitorearse a sí mismo, solo para responder una simple pregunta “¿Cuál es el % de disponibilidad de mis datos de registro de red?”. Si hablamos de intentos concretos para hacer esto de manera automática, digamos, Splunk sobre Splunk, ¿son realmente eficientes? ¿Cuánto costo adicional de licencia uno tiene que agregar para poder autodiagnosticar la plataforma SIEM/Gestión de Registros y cuánto sobrecarga de rendimiento produce esta aplicación más popular?.

Está bien, dejemos de lado syslog y Splunk por unos minutos y pensemos en la segunda fuente de registros más popular – Microsoft Windows Event Log. Para mantener los problemas breves: rotación de registros, ancho de banda de red, errores de autenticación / bloqueos de contraseña, inestabilidad de WMI y JCIFS, alta carga de servidores Windows ocupados (auditoría de archivos, Active Directory, etc.). Monitorear esto nuevamente requeriría todo un conjunto de herramientas y esas herramientas serán diferentes en comparación con las herramientas de monitoreo de syslog. Podríamos continuar con una larga lista que incluye bases de datos, firewalls/ngfw/ips/ngips/utm (hola OPSEC & SDEE) y descubriremos aún más cosas que ocurren fuera de SIEM, que SIEM no tiene efecto sobre ellas pero debe conocer (!), y debe proporcionar esta información de manera rápida y precisa al administrador. Sin embargo, para aquellos que han leído hasta aquí, hay buenas noticias, ya que SIEM (o la mayoría de los SIEM) en sí mismo tiene registros de diagnóstico legibles (casi). Esos archivos de diagnóstico difíciles de encontrar, llamadas de API ocultas o trazas de pila java multilínea tienen bits y bytes de información que podrían proporcionar respuestas a muchos de los problemas planteados anteriormente. Y al combinarlos juntos y aplicando métricas de perfilado significativas podemos responder esas dos preguntas simples que marcan una gran diferencia entre saber que tu plataforma crítica de detección de seguridad está funcionando como se espera o ignorar el problema/intervenir parcialmente arrojando más recursos en tiempo completo al problema. La automatización está aquí para todos aquellos que quieren asegurar que sus datos de registro estén disponibles según lo planeado en el proyecto, requerido por la organización/cliente y que obtengan un retorno adecuado de su inversión en SIEM. Espero que esto te deje con algo en qué pensar. ¡Mantente sintonizado!

p.s. En caso de que resultes ser uno de los expertos en HPE ArcSight, ¡hay más buenas noticias! Como parte de una iniciativa global para que las plataformas SIEM ofrezcan el valor y ahorren tiempo a los expertos en SIEM en todo el mundo, SOC Prime ofrece un servicio gratuito de verificación instantánea de salud de SIEM en línea, que puede consumir archivos agent.log y proporcionarte las 5 cuestiones críticas principales y soluciones para ellas en menos de 5 minutos. ¿Tienes un agent.log? Échalo aquí y compruébalo tú mismo!