(gracias a Sergey G. Brester por la idea del título )
Colegas, el propósito de este artículo es compartir la experiencia de una operación de prueba de un año de duración de una nueva clase de soluciones IDS basadas en tecnologías Deception.
Para mantener la coherencia lógica de la presentación del material, considero necesario partir de las premisas. Entonces, el problema:
- Los ataques dirigidos son el tipo de ataque más peligroso, a pesar de que su participación en el número total de amenazas es pequeña.
- Aún no se ha inventado ningún medio eficaz garantizado para proteger el perímetro (o un conjunto de tales medios).
- Por regla general, los ataques dirigidos se desarrollan en varias etapas. Superar el perímetro es sólo una de las etapas iniciales, que (puedes tirarme piedras) no causa mucho daño a la “víctima”, a menos, por supuesto, que se trate de un ataque DEoS (Destrucción de servicio) (cifradores, etc. .). El verdadero "dolor" comienza más tarde, cuando los activos capturados comienzan a usarse para pivotar y desarrollar un ataque "profundo", y no nos dimos cuenta de esto.
- Dado que comenzamos a sufrir pérdidas reales cuando los atacantes finalmente alcanzan los objetivos del ataque (servidores de aplicaciones, DBMS, almacenes de datos, repositorios, elementos de infraestructura críticos), es lógico que una de las tareas del servicio de seguridad de la información sea interrumpir los ataques antes. este triste suceso. Pero para interrumpir algo, primero debes averiguarlo. Y cuanto antes mejor.
- En consecuencia, para una gestión de riesgos exitosa (es decir, reducir el daño de los ataques dirigidos), es fundamental contar con herramientas que proporcionen un TTD mínimo (tiempo de detección: el tiempo desde el momento de la intrusión hasta el momento en que se detecta el ataque). Dependiendo de la industria y la región, este período promedia 99 días en EE. UU., 106 días en la región EMEA y 172 días en la región APAC (M-Trends 2017, A View From the Front Lines, Mandiant).
- ¿Qué ofrece el mercado?
- "Cajas de arena". Otro control preventivo, que dista mucho de ser ideal. Existen muchas técnicas efectivas para detectar y eludir entornos sandbox o soluciones de lista blanca. Los chicos del “lado oscuro” todavía están un paso por delante.
- Los UEBA (sistemas para perfilar el comportamiento e identificar desviaciones) pueden resultar, en teoría, muy eficaces. Pero, en mi opinión, esto será en algún momento en un futuro lejano. En la práctica, esto sigue siendo muy costoso, poco confiable y requiere una infraestructura de seguridad de la información y TI muy madura y estable, que ya tenga todas las herramientas que generarán datos para el análisis del comportamiento.
- SIEM es una buena herramienta para investigaciones, pero no es capaz de ver y mostrar algo nuevo y original de manera oportuna, porque las reglas de correlación son las mismas que las de las firmas.
- Como resultado, se necesita una herramienta que:
- trabajó con éxito en condiciones de un perímetro ya comprometido,
- detectó ataques exitosos casi en tiempo real, independientemente de las herramientas y vulnerabilidades utilizadas,
- no dependía de firmas/reglas/scripts/políticas/perfiles y otras cosas estáticas,
- no requirió grandes cantidades de datos y sus fuentes para el análisis,
- permitiría definir los ataques no como una especie de puntuación de riesgo como resultado del trabajo de "las mejores matemáticas del mundo, patentadas y, por tanto, cerradas", que requiere una investigación adicional, sino prácticamente como un evento binario: "Sí, estamos siendo atacados” o “No, todo está bien”,
- era universal, eficientemente escalable y factible de implementar en cualquier entorno heterogéneo, independientemente de la topología de red física y lógica utilizada.
Las llamadas soluciones de engaño compiten ahora por el papel de dicha herramienta. Es decir, soluciones basadas en el viejo concepto de honeypots, pero con un nivel de implementación completamente diferente. Este tema definitivamente está en aumento ahora.
Segun los resultados Las soluciones de engaño se incluyen en el TOP 3 de estrategias y herramientas que se recomienda utilizar.
Según el informe El engaño es una de las principales direcciones de desarrollo de las soluciones IDS (sistemas de detección de intrusiones).
Toda una sección de este último , dedicado a SCADA, se basa en datos de uno de los líderes de este mercado, TrapX Security (Israel), cuya solución lleva un año trabajando en nuestra área de pruebas.
TrapX Deception Grid le permite calcular el coste y operar IDS distribuidos masivamente de forma centralizada, sin aumentar la carga de licencias ni los requisitos de recursos de hardware. De hecho, TrapX es un constructor que le permite crear a partir de elementos de la infraestructura de TI existente un gran mecanismo para detectar ataques a escala empresarial, una especie de "alarma" de red distribuida.
Estructura de la solución
En nuestro laboratorio estudiamos y probamos constantemente diferentes productos nuevos en el campo de la seguridad informática. Actualmente, aquí se implementan alrededor de 50 servidores virtuales diferentes, incluidos los componentes TrapX Deception Grid.
Entonces, de arriba a abajo:
- TSOC (TrapX Security Operation Console) es el cerebro del sistema. Se trata de la consola de gestión central a través de la cual se lleva a cabo la configuración, el despliegue de la solución y todas las operaciones del día a día. Dado que se trata de un servicio web, se puede implementar en cualquier lugar: en el perímetro, en la nube o en un proveedor MSSP.
- TrapX Appliance (TSA) es un servidor virtual al que conectamos, mediante el puerto troncal, aquellas subredes que queramos cubrir con monitorización. Además, todos nuestros sensores de red realmente “viven” aquí.
Nuestro laboratorio tiene una TSA implementada (mwsapp1), pero en realidad podría haber muchas. Esto puede ser necesario en redes grandes donde no hay conectividad L2 entre segmentos (un ejemplo típico es “Holding y subsidiarias” o “Sede central y sucursales del banco”) o si la red tiene segmentos aislados, por ejemplo, sistemas automatizados de control de procesos. En cada una de estas sucursales/segmentos, puede implementar su propia TSA y conectarla a un único TSOC, donde toda la información se procesará de forma centralizada. Esta arquitectura le permite crear sistemas de monitoreo distribuidos sin la necesidad de reestructurar radicalmente la red o interrumpir la segmentación existente.
Además, podemos enviar una copia del tráfico saliente a la TSA a través de TAP/SPAN. Si detectamos conexiones con botnets conocidas, servidores de comando y control o sesiones TOR, también recibiremos el resultado en la consola. De esto es responsable el Network Intelligence Sensor (NIS). En nuestro entorno, esta funcionalidad está implementada en el firewall, por lo que no la usamos aquí.
- Trampas de aplicaciones (sistema operativo completo): honeypots tradicionales basados en servidores Windows. No necesita muchos de ellos, ya que el objetivo principal de estos servidores es proporcionar servicios de TI a la siguiente capa de sensores o detectar ataques a aplicaciones comerciales que puedan implementarse en un entorno Windows. Tenemos uno de esos servidores instalado en nuestro laboratorio (FOS01)
- Las trampas emuladas son el componente principal de la solución, que nos permite, utilizando una sola máquina virtual, crear un "campo minado" muy denso para los atacantes y saturar la red empresarial, todas sus VLAN, con nuestros sensores. El atacante ve dicho sensor, o host fantasma, como una PC o servidor real con Windows, un servidor Linux u otro dispositivo que decidamos mostrarle.
Por el bien del negocio y por curiosidad, implementamos "un par de cada criatura": PC y servidores con Windows de varias versiones, servidores Linux, un cajero automático con Windows integrado, SWIFT Web Access, una impresora de red, un Cisco interruptor, una cámara IP Axis, una MacBook, un dispositivo PLC e incluso una bombilla inteligente. Hay 13 anfitriones en total. En general, el proveedor recomienda implementar dichos sensores en una cantidad de al menos el 10% del número de hosts reales. La barra superior es el espacio de direcciones disponible.Un punto muy importante es que cada uno de estos hosts no es una máquina virtual completa que requiera recursos y licencias. Este es un señuelo, una emulación, un proceso en la TSA, que tiene un conjunto de parámetros y una dirección IP. Por lo tanto, incluso con la ayuda de una TSA, podemos saturar la red con cientos de hosts fantasmas que funcionarán como sensores en el sistema de alarma. Es esta tecnología la que hace posible escalar de manera rentable el concepto de honeypot en cualquier gran empresa distribuida.
Desde el punto de vista de un atacante, estos hosts son atractivos porque contienen vulnerabilidades y parecen ser objetivos relativamente fáciles. El atacante ve servicios en estos hosts y puede interactuar con ellos y atacarlos usando herramientas y protocolos estándar (smb/wmi/ssh/telnet/web/dnp/bonjour/Modbus, etc.). Pero es imposible utilizar estos hosts para desarrollar un ataque o ejecutar su propio código.
- La combinación de estas dos tecnologías (FullOS y trampas emuladas) nos permite conseguir una alta probabilidad estadística de que un atacante tarde o temprano se encuentre con algún elemento de nuestra red de señalización. Pero ¿cómo podemos asegurarnos de que esta probabilidad sea cercana al 100%?
Las llamadas fichas de Engaño entran en batalla. Gracias a ellos, podemos incluir todos los PC y servidores existentes de la empresa en nuestro IDS distribuido. Los tokens se colocan en las PC reales de los usuarios. Es importante entender que los tokens no son agentes que consumen recursos y pueden causar conflictos. Los tokens son elementos de información pasivos, una especie de “migas de pan” para el bando atacante que lo llevan a una trampa. Por ejemplo, unidades de red asignadas, marcadores de administradores web falsos en el navegador y contraseñas guardadas para ellos, sesiones ssh/rdp/winscp guardadas, nuestras trampas con comentarios en archivos hosts, contraseñas guardadas en la memoria, credenciales de usuarios inexistentes, oficina archivos, apertura que activará el sistema y mucho más. Así, situamos al atacante en un entorno distorsionado, saturado de vectores de ataque que en realidad no suponen una amenaza para nosotros, sino todo lo contrario. Y no tiene forma de determinar dónde la información es verdadera y dónde es falsa. De este modo, no sólo aseguramos una rápida detección de un ataque, sino que también ralentizamos significativamente su progreso.
Un ejemplo de creación de una trampa de red y configuración de tokens. Interfaz amigable y sin edición manual de configuraciones, scripts, etc.
En nuestro entorno, configuramos y colocamos varios de estos tokens en FOS01 con Windows Server 2012R2 y una PC de prueba con Windows 7. RDP se ejecuta en estas máquinas y periódicamente los "colgamos" en la DMZ, donde se encuentran varios de nuestros sensores. (trampas emuladas) también se muestran. Así que, naturalmente, por así decirlo, tenemos un flujo constante de incidentes.
Entonces, aquí hay algunas estadísticas rápidas para el año:
56 – incidentes registrados,
2: hosts de origen del ataque detectados.
Mapa de ataque interactivo en el que se puede hacer clic
Al mismo tiempo, la solución no genera ningún tipo de megaregistro o feed de eventos, lo que lleva mucho tiempo comprender. En cambio, la propia solución clasifica los eventos por tipos y permite que el equipo de seguridad de la información se centre principalmente en los más peligrosos: cuando el atacante intenta aumentar las sesiones de control (interacción) o cuando aparecen cargas binarias (infección) en nuestro tráfico.
Toda la información sobre eventos es legible y presentada, en mi opinión, de forma fácil de entender incluso para un usuario con conocimientos básicos en el campo de la seguridad de la información.
La mayoría de los incidentes registrados son intentos de escanear nuestros hosts o conexiones individuales.
O intentos de fuerza bruta contrasenas para RDP
Pero también hubo casos más interesantes, especialmente cuando los atacantes "lograron" adivinar la contraseña de RDP y obtener acceso a la red local.
Un atacante intenta ejecutar código utilizando psexec.
El atacante encontró una sesión guardada, lo que le llevó a una trampa en forma de servidor Linux. Inmediatamente después de conectarse, con un conjunto de comandos preparado previamente, intentó destruir todos los archivos de registro y las variables del sistema correspondientes.
Un atacante intenta realizar una inyección SQL en un honeypot que imita SWIFT Web Access.
Además de estos ataques "naturales", también realizamos varias pruebas propias. Uno de los más reveladores es probar el tiempo de detección de un gusano de red en una red. Para ello utilizamos una herramienta de GuardiCore llamada . Se trata de un gusano de red que puede secuestrar Windows y Linux, pero sin ninguna "carga útil".
Implementamos un centro de comando local, lanzamos la primera instancia del gusano en una de las máquinas y recibimos la primera alerta en la consola TrapX en menos de un minuto y medio. TTD 90 segundos versus 106 días en promedio...
Gracias a la capacidad de integrarnos con otras clases de soluciones, podemos pasar de detectar amenazas rápidamente a responderlas automáticamente.
Por ejemplo, la integración con sistemas NAC (Network Access Control) o con CarbonBlack le permitirá desconectar automáticamente de la red las PC comprometidas.
La integración con sandboxes permite que los archivos involucrados en un ataque se envíen automáticamente para su análisis.
Integración de McAfee
La solución también tiene su propio sistema de correlación de eventos integrado.
Pero no estábamos satisfechos con sus capacidades, por lo que lo integramos con HP ArcSight.
El sistema de emisión de tickets integrado ayuda a todo el mundo a hacer frente a las amenazas detectadas.
Dado que la solución fue desarrollada “desde el principio” para las necesidades de agencias gubernamentales y un gran segmento corporativo, naturalmente implementa un modelo de acceso basado en roles, integración con AD, un sistema desarrollado de informes y activadores (alertas de eventos), orquestación para grandes estructuras holding o proveedores de MSSP.
En lugar de un curriculum vitae
Si existe un sistema de vigilancia que, en sentido figurado, nos cubra las espaldas, entonces con el compromiso del perímetro todo apenas comienza. Lo más importante es que existe una oportunidad real de afrontar los incidentes de seguridad de la información y no de sus consecuencias.
Fuente: habr.com