Como se mostro en el blog anteriormente , las reglas de detección basadas en búsquedas y la detección de anomalías basada en aprendizaje automático de Elastic pueden ser una forma poderosa de identificar actividades raras e inusuales en los registros de API en la nube. Ahora, a partir de Elastic Security 7.13, se ha introducido un nuevo conjunto de trabajos de aprendizaje automático no supervisados para datos de red y reglas de alerta adjuntas, varias de las cuales buscan anomalías geográficas. En esta publicación de blog, exploraremos un estudio de caso que demuestra cómo los datos de la red pueden producir detecciones importantes.
Antes de la llegada de las herramientas de detección y respuesta de puntos finales (EDR), los equipos de seguridad dependían en gran medida de la instrumentación de la red, como los registros de firewall y las alertas de detección de intrusiones (IDS). Dada la falta de información del proceso o del contexto del usuario, en los registros de la red, la tasa de falsos positivos para los eventos de la red podría ser alta en ocasiones, y la respuesta en vivo basada en el host podría ser lenta e incierta. Durante la respuesta en vivo, el paso intermedio entre el incidente, la alerta o la clasificación de casos y el análisis forense formal, los analistas examinarían los hosts o los activos para determinar si se habían visto comprometidos. Esto puede ser lento e inexacto cuando los analistas carecen de acceso práctico a los hosts y necesitan trabajar a través de intermediarios o esperar a que se cumplan las solicitudes de información.
El aumento de las herramientas EDR y la rica información que proporciona nos brinda una imagen mucho más rápida, clara y completa de lo que está sucediendo en un sistema operativo host y si existe un compromiso genuino o una infestación de malware. A lo largo de los años, se ha producido un debate considerable sobre si los equipos de detección deberían utilizar eventos de red o de punto final en función de sus méritos relativos. Una mejor solución, en lugar de obligar a los equipos de seguridad a elegir un conjunto de registros u otro, es utilizar una especie de "tríada nuclear" de datos de detección: la combinación de datos de punto final, nube y red.
La "tríada nuclear"
El meollo de mi caso comercial para la combinación de datos de punto final, nube y red es similar a la razón de ser de la llamada "tríada nuclear": la proverbial condición de huevos en una canasta. La tríada nuclear se refiere a una doctrina estratégica de tres frentes destinada a proporcionar un alto nivel de disuasión al hacer que las fuerzas nucleares estratégicas sean tan robustas y diversas que no sea factible tratar de desarrollar planes para neutralizarlas en un primer ataque. La tríada consiste en una combinación de fuerzas nucleares aéreas, terrestres y marinas: bombarderos de largo alcance, misiles balísticos y "boomers": submarinos capaces de lanzar misiles balísticos más pequeños después de acercarse a un objetivo. Ninguna estrategia identificable puede neutralizar lo suficiente de la tríada como para reducir la amenaza de un contraataque lo suficiente como para hacer que un plan de primer ataque sea estratégicamente viable para un planificador de guerra nuclear.
La combinación de los tres tipos de datos de detección (endpoint, nube y datos de red) plantea un problema similar para los actores de amenazas. Pueden manipular las fuentes de datos de los puntos finales u operar desde hosts sin instrumentación, pero su comando y control (C2) aún estarán visibles en los registros de la red. En pocas palabras, ningún elemento de la tríada proporciona una detección garantizada de todas las amenazas en todos los escenarios; tal expectativa no es razonable. Por supuesto, la combinación de los tres elementos de la tríada de detección tampoco proporciona una detección garantizada, pero la posibilidad de que los tres pasen por alto algo es exponencialmente menor que depender de uno u otro solo. Consideremos un caso de estudio de ejemplo en el que los datos de la red arrojaron una detección importante.
Un caso de estudio
Desarrollé un conjunto de reglas de detección de anomalías en la red después de hacer un descubrimiento accidental, como lo hago a veces al filtrar datos. Había tomado prestado (con fines de investigación) un clúster de producción que contenía, entre otras cosas, un conjunto de registros de cortafuegos de tamaño mediano. Al tamizar y graficar los datos de la red, a lo largo de líneas geográficas, noté que Rusia estaba entre los 3 principales países de destino para las direcciones IP de destino que habían sido geolocalizadas. Esto fue extraño porque no había flujos de trabajo o relaciones comerciales de gran tamaño con organizaciones rusas (y porque la actividad rusa es una de las principales preocupaciones hoy en día simplemente debido a eventos recientes).
Me gusta tener al menos una confirmación del propietario del sistema de que la actividad es realmente anómala antes de plantear la cuestión de un incidente. No todas las anomalías son un incidente y no todos los incidentes son críticos. En este caso, el propietario del sistema sintió que la actividad de la dirección IP rusa era bastante inexplicable, por lo que procedimos a charlar con un grupo más grande, incluidos los líderes del equipo cuya infraestructura habitaba la red en cuestión. Nos subimos a un Zoom y rastreamos la fuente del tráfico hasta un cortafuegos de enclave más pequeño, que era un punto NAT, por lo que necesitábamos leer sus registros para identificar la fuente del tráfico pre-NAT. La fuente fue una instancia de Windows en un laboratorio donde ocasionalmente se detonó malware. Al carecer de eventos de punto final, ejecutamos netstat en un bucle de un segundo, mientras se canalizaba a un archivo de texto, como lo hicimos una vez,
Determinamos que el tráfico provenía de un proceso de malware que se ejecutaba en un laboratorio. La naturaleza del laboratorio era que las máquinas virtuales de Windows se pondrían en marcha, con los eventos de endpoint de Windows que se enviarían a un clúster local, y todo se interrumpiría en cuestión de días. Debido a una imperfección en las reglas del cortafuegos del enclave, se permitía que el tráfico HTTPS saliera del enclave y se negaba corriente abajo en el cortafuegos fronterizo. Debido a la naturaleza ascendente y descendente del laboratorio, los eventos y registros de Windows no se conservaron después de que se desactivara un entorno determinado, por lo que estos eventos no estaban disponibles en los clústeres de SOC principales para su detección. Los únicos indicadores y registros de la actividad en los clústeres principales eran los registros del firewall del firewall fronterizo que negaba el tráfico.
Podríamos debatir si los eventos de punto final del laboratorio deberían haberse reenviado o preservado, y quizás deberían haber sido así. Sin embargo, desafortunadamente, la cobertura de los terminales rara vez es completa en una organización determinada. Considere los muchos escenarios posibles donde pueden ocurrir excepciones y brechas:
En todos estos escenarios, el monitoreo de la red puede proporcionar un valioso mecanismo de detección para cosas que de otra manera podrían perderse.
Detección de anomalías para la supervisión de la red
El enriquecimiento de los registros de la red con datos geográficos y el análisis de patrones geográficos se ha utilizado durante mucho tiempo como una técnica de análisis para el monitoreo de la seguridad de la red. El análisis geográfico, en busca de relaciones geográficas anómalas, en los datos de la red es una técnica simple, pero me gusta por algunas razones. El análisis geográfico y las anomalías geográficas han llevado a investigaciones que produjeron algunos de los casos más importantes en los que he trabajado. Encuentro que los datos geográficos a menudo contienen sorpresas cuando se analizan por primera vez, cosas que la organización necesita saber. La detección geográfica a menudo funciona simplemente porque la infraestructura de malware generalmente se encuentra en el país al que los desarrolladores de malware llaman hogar. Los desarrolladores de malware pueden, por supuesto, ubicar la infraestructura en el mismo país que las víctimas, como vimos en el caso de SolarWinds, pero por lo general no se molestan.
Linware Panamá ⯈