En resumen, diré que emulaba una ciudad en toda regla, y bastante grande, en la que había prácticamente de todo, desde el aeropuerto hasta las instituciones financieras y un parque de atracciones. Esto les dio a los atacantes la oportunidad de mostrar sus habilidades de piratería y a los defensores sus habilidades para detectar y repeler amenazas.
Entonces, surgió la pregunta, ¿cómo podemos “observar” esta batalla desde el punto de vista de la seguridad de la información? En realidad, este artículo trata sobre los detalles de la construcción de dicho proceso de observación y los resultados que obtuvimos.
Entendimos que no deberíamos interferir con el funcionamiento del polígono y que el formato del evento no nos permite realizar ajustes detallados de los perfiles de detección de ataques, por lo que se eligieron soluciones de clase NTA (NTA - Network Traffic Analytics), que son soluciones que identifican amenazas mediante el análisis de la telemetría de red. o, simplemente, el perfil de tráfico de la red. La implementación de tales sistemas es mucho más simple y fluida que, por ejemplo, la implementación de los sistemas clásicos de detección y prevención de intrusos. Esto se debe al hecho de que no es necesario realizar cambios en la topología de la red, así como al hecho de que el núcleo de dichos sistemas es el aprendizaje automático combinado con datos de inteligencia de amenazas. Este enfoque permite al sistema no solo identificar rápidamente las amenazas típicas, sino también "aprender" durante un cierto período de tiempo,y luego utilizar los conocimientos adquiridos para detectar comportamientos anormales de usuarios, sistemas y aplicaciones. Además, estos sistemas, simplemente por su enfoque, son significativamente menos "ruidosos" en términos de advertencia sobre todo tipo de amenazas y mucho más precisos en términos de identificación de incidentes reales. Sobre esto, terminaré una pequeña excursión a este tema, quien quiera leer más sobre esto, le aconsejo que preste atención.
en este material .
Inicialmente, decidí utilizar el conocido producto Cisco Stealthwatch Enterprise, que muchos de mis colegas en diferentes organizaciones utilizan con éxito. Y estaba a punto de llamar a mis colegas de Positive para decirles cuántos procesadores, espacio en disco, máquinas virtuales, etc. necesito. En ese momento, se me ocurrió una idea extraña: recordé cuántos recursos, tanto humanos como técnicos, se pusieron para crear este polígono cibernético, y pensé que nadie esperaba que solicitara algunos de estos recursos. Por otro lado, no quería renunciar a la idea y, en el contexto de las tendencias modernas en seguridad de la información, decidí cambiarme a una solución en la nube llamada Stealthwatch Cloud. Debo decir que esta solución se llama nube por una razón, ya que puede recolectar y analizar telemetría de nubes privadas,creado dentro de nubes públicas a través de interfaces de programación de aplicaciones (API). Es decir, con la ayuda de esta solución, puedo analizar, desde el punto de vista de la seguridad de la información, lo que está sucediendo dentro de Amazon AWS, Microsoft Azure, Google GCP, así como los contenedores de Kubernetes. Pero ahora necesitaba otra aplicación para este producto, a saber, la supervisión de redes privadas. En este caso, simplemente se instala un sensor (sensor) en dicha red, que envía telemetría a la consola de control y supervisión basada en la nube. En la oración anterior usé la palabra "simple" y ahora intentaré ampliarla con más detalle.así como contenedores de Kubernetes. Pero ahora necesitaba otra aplicación para este producto, a saber, la supervisión de redes privadas. En este caso, simplemente se instala un sensor (sensor) en dicha red, que envía telemetría a la consola de control y supervisión basada en la nube. En la oración anterior usé la palabra "simple" y ahora intentaré expandirla con más detalle.así como contenedores de Kubernetes. Pero ahora necesitaba otra aplicación para este producto, a saber, la supervisión de redes privadas. En este caso, simplemente se instala un sensor (sensor) en dicha red, que envía telemetría a la consola de control y supervisión basada en la nube. En la oración anterior usé la palabra "simple" y ahora intentaré ampliarla con más detalle.
Entonces, ¿cómo es el proceso?
Necesita solicitar una prueba, tarda un par de minutos.
Enlace aquí .
Luego, en un par de días, comienzan a llegar varias cartas útiles, y al final surge una carta que ¡se activa el portal!
Después de eso, se obtiene un portal personal, cuyo enlace se ve así:
cisco-YOUR_CISCO_USERNAME.obsrvbl.com , por ejemplo: cisco-mkader.obsrvbl.com .
Ingresando allí, vemos la pantalla principal, desde donde se puede descargar una máquina virtual de sensores para monitorear redes privadas. Los requisitos para esta máquina virtual no son muy buenos: 2 vCPU, 2 gigabytes de memoria y 32 gigabytes de espacio en disco. En general, el proceso de instalación es extremadamente simple y se describe en un manual inusualmente simple y conveniente, hecho en forma de un libro electrónico desplazable .
Debo decir de inmediato que el sensor tiene dos interfaces: una sirve para la comunicación con la consola de control y también recopila telemetría sobre sí mismo, por ejemplo, NetFlow, y al mismo tiempo monitorea todo el tráfico que llega a él. El segundo puede funcionar en el modo de captura de paquetes (modo promiscuo) y generar telemetría sobre el tráfico que capturó. En nuestro caso particular, solo usamos la primera interfaz.
Después de la instalación, el sensor se ejecuta en la nube donde se encuentra la consola; esto es en realidad AWS y produce un hermoso mensaje:
{"error":"unknown identity","identity":"185.190.117.34"}
Esta es la misma dirección IP bajo la cual el sensor cree que se ve a sí mismo en el mundo exterior, rompiendo un firewall corporativo, traducción de direcciones, etc. Por si acaso, diré de inmediato que el sensor necesita HTTP y HTTPs, además de configurar DNS. a. Después de recibir el mensaje anterior, solo necesita tomar esta dirección y agregarla a la lista de sus sensores en la consola:
Y después de un tiempo, el sensor se vuelve verde, esto significa que el sensor ha establecido una conexión con la consola.
Y, en general, el lanzamiento del sistema se completa con esto. El siguiente paso es agregar fuentes de telemetría, además de que el propio sensor escuche. Si queremos recibir telemetría usando el protocolo NetFlow, entonces el sitio es extremadamente útil .
En él podemos seleccionar el dispositivo de red que necesitamos, ingresar un par de parámetros y obtener una configuración ya hecha:
Y copiar la información recibida a nuestros dispositivos de red. Eso es todo, ¡el sistema está listo para funcionar! Más bien, incluso ha comenzado a funcionar.
Por cierto, los ejemplos de configuración de Netflow de este sitio se pueden usar no solo para Steathwatch, sino para cualquier otro producto que pueda usar dicha telemetría, por ejemplo, Cisco Tetration, IBM QRadar, etc.
Ahora puede realizar un ajuste fino del sistema. Quiero decir de inmediato que realmente me gusta ver cómo varios productos de seguridad de la información de Cisco me informan sobre todo lo que sucede en una única consola de respuesta y supervisión de Cisco SecureX. De hecho, SecureX es algo extremadamente interesante y merece una descripción aparte. En pocas palabras, es un sistema de monitoreo de seguridad de la información (SIEM) basado en la nube, investigación (Threat Hunting), investigación y respuesta a incidentes y, al mismo tiempo, automatización de procesos (SOAR). Le recomiendo que se familiarice con este sistema con más detalle, y está "adjunto" de forma predeterminada a cualquier producto de seguridad de la información de Cisco. Bueno, un poco de marketing sobre este tema aquí .
Entonces, en primer lugar, configuré dicha integración:
al mismo tiempo, configuré la integración con nuestra plataforma en la nube para brindar servicios de seguridad Cisco Umbrella: https://habr.com/ru/company/jetinfosystems/blog/529174/ .
No puse ninguna esperanza particular en él, creyendo que todas las cosas más interesantes sucederían dentro del vertedero, y no era mi tarea proteger este vertedero.
Después de eso, creé una nueva consola de monitoreo en SecureX. Todo esto tomó un total de 5 minutos, y tal vez incluso menos. Un par de imágenes de mi SecureX a continuación:
Después de eso, decidí desactivar las notificaciones que no me interesaban y activar las interesantes. Para hacer esto, volví a la consola SWC y fui a configurar estas mismas notificaciones:
diré enseguida que para cada una de las notificaciones puedes ver qué es, cuántos días de recopilación de información telemétrica se requieren para detectar la amenaza correspondiente y cómo va si falla. para MITRE ATT & CK.
La cantidad de amenazas detectadas y notificaciones relacionadas crece constantemente a medida que evoluciona la solución. Pero realmente no necesito pensar en eso: la nube, ya que agregaron algo nuevo, está inmediatamente a mi disposición.
Deshabilité la mayoría de las notificaciones relacionadas con los ataques a las nubes de AWS, Azure, GCP, ya que no se usaban dentro de este polígono, y encendí todas las notificaciones relacionadas con los ataques a las redes privadas.
Además, puedo administrar políticas de monitoreo para diferentes subredes que quiero controlar. También puede habilitar el monitoreo por separado para los países de particular interés para nosotros:
en este punto, leí el texto anterior y me di cuenta de que me tomó mucho más tiempo escribirlo que configurar el sistema, incluidas todas las integraciones.
Ahora que hemos visto?
En los primeros días de Standoff, un par de nuestros firewalls virtuales ASAv me proporcionaron la telemetría, pero luego la cantidad de fuentes aumentó ligeramente: se agregaron más firewalls, así como Netflow de un agente de tráfico central.
Las primeras notificaciones llegaron muy rápidamente y, como era de esperar, se asociaron con numerosos escaneos. Bueno, entonces se volvió más interesante ver el proceso cada hora. No describiré todo el proceso de observación aquí, solo les contaré algunos hechos. En primer lugar, logramos recopilar buena información sobre qué es qué en el sitio de prueba: en
segundo lugar, para evaluar la escala del evento, con qué países fue el intercambio de tráfico más activo:
De hecho, existe un formato más conveniente para presentar estos datos, pero aquí decidí mostrar más detalles.
Entonces, los principales "externos", además de Rusia, los usuarios del vertedero fueron Estados Unidos, Alemania, Holanda, Irlanda, Inglaterra, Francia, Finlandia, Canadá, aunque hubo alguna interacción con casi todos los países, incluidos los países de Sudamérica, África y Australia: por
supuesto, nosotros pudo ver quién es el propietario de las direcciones que vieron:
Y, si lo desea, preguntar sobre ellas de otras fuentes analíticas útiles:
Lo que nos permitió ver, por ejemplo, una interacción activa con los recursos de Microsoft en muchos países.
Además, la tabla de las interacciones más activas podría verse en forma de cuadro dinámico de conexiones con posibilidad de su análisis más detallado:
¿Pero qué hemos recogido exactamente desde el punto de vista de los ataques?
La lista de notificaciones nos informa sobre esto, algunas de las cuales ves a continuación:
En total, se identificaron 117 ataques, confirmados por muchas observaciones (Observables) Vemos aquí escaneos de red, sesiones largas sospechosas, problemas con SMB, uso incorrecto de puertos y servicios de red, comportamiento extraño nodos de red, cambios inesperados en su comportamiento y otras rarezas que deberían alertar a un especialista en seguridad de la información.
Para cada evento de nuestro interés, podemos recibir información detallada, incluyendo qué es, qué es malo y recomendaciones para la prevención. A continuación se pueden ver un par de estos eventos interesantes: un lanzamiento inesperado de un servidor SSH en una estación de trabajo Windows y el uso de un rango de puertos no estándar. También puede prestar atención al hecho de que, con la integración configurada, puede pasar directamente de la descripción del evento a la consola de investigación de SecureX Treat Response para un análisis detallado de este incidente:
Entonces, algunas conclusiones breves basadas en los resultados de este pequeño y entretenido piloto.
En primer lugar, Positive Technologies realizó excelentes ciberejercicios y fue muy interesante observarlos un poco "desde adentro", y fue conveniente, fácil y simple.
El segundo, que tengo que decir, las soluciones de seguridad en la nube son rápidas, simples y convenientes. Y si todavía hay muchos de ellos y puede configurar la integración entre ellos, también es muy efectivo.
En tercer lugar, los participantes del sitio de prueba también utilizaron activamente los servicios en la nube, por ejemplo, los servicios de Microsoft.
En cuarto lugar, el análisis automatizado de la máquina de varias redes de telemetría facilita la identificación de incidentes de seguridad de la información, incluidas las actividades planificadas de los intrusos. Y le aconsejo que preste atención al hecho de que ya existen muchos escenarios bien desarrollados para el uso eficaz de la solución Cisco Stealthwatch para las necesidades de seguridad de la información. Cada uno de los lectores pueden encontrar un script para su gusto aquí .
Bueno, y un pequeño comentario final: en este artículo, deliberadamente no enumeré en detalle las listas recibidas de direcciones IP, dominios, detalles de interacción, etc., dándome cuenta de cuánto esfuerzo tomó Positive Technologies para ensamblar este polígono y esperando que les sea útil muchas veces y nosotros en el futuro. Y no haremos la vida más fácil para futuros atacantes.