Burato como ferramenta de seguridade - 2, ou como atrapar APT "con cebo vivo"

(grazas a Sergey G. Brester pola idea do título sebres)

Compañeiros, o propósito deste artigo é compartir a experiencia dunha operación de proba dun ano dunha nova clase de solucións IDS baseadas en tecnoloxías Deception.

Para manter a coherencia lóxica da presentación do material, considero necesario comezar polas premisas. Entón, o problema:

1. Os ataques dirixidos son o tipo de ataque máis perigoso, a pesar de que a súa participación no total de ameazas é pequena.
2. Aínda non se inventou ningún medio eficaz garantido de protexer o perímetro (ou un conxunto de tales medios).
3. Como regra xeral, os ataques dirixidos teñen lugar en varias etapas. A superación do perímetro é só unha das etapas iniciais, que (podes tirarme pedras) non causa moito dano á "vítima", a non ser que, por suposto, se trate dun ataque DEoS (Destrución do servizo) (cifradores, etc.) .). A verdadeira "dor" comeza máis tarde, cando os activos capturados comezan a usarse para pivotar e desenvolver un ataque de "profundidade", e non nos decatamos diso.
4. Dado que comezamos a sufrir perdas reais cando os atacantes chegan por fin aos obxectivos do ataque (servidores de aplicacións, DBMS, almacéns de datos, repositorios, elementos de infraestrutura crítica), é lóxico que unha das tarefas do servizo de seguridade da información sexa interromper antes os ataques. este triste suceso. Pero para interromper algo, primeiro debes descubrir iso. E canto antes, mellor.
5. En consecuencia, para unha xestión exitosa do risco (é dicir, reducir o dano dos ataques dirixidos), é fundamental contar con ferramentas que proporcionen un TTD mínimo (tempo para detectar: ​​o tempo desde o momento da intrusión ata o momento en que se detecta o ataque). Dependendo da industria e rexión, este período ten unha media de 99 días nos EUA, 106 días na rexión EMEA, 172 días na rexión APAC (M-Trends 2017, A View From the Front Lines, Mandiant).
6. Que ofrece o mercado?
   • "Caixas de area". Outro control preventivo, que dista moito de ser o ideal. Existen moitas técnicas eficaces para detectar e ignorar as solucións de sandbox ou listas brancas. Os rapaces do "lado escuro" aínda están un paso por diante aquí.
   • UEBA (sistemas para perfilar comportamento e identificación de desviacións) - en teoría, pode ser moi eficaz. Pero, na miña opinión, isto é nalgún momento nun futuro distante. Na práctica, isto aínda é moi caro, pouco fiable e require unha infraestrutura informática e de seguridade da información moi madura e estable, que xa conta con todas as ferramentas que xerarán datos para a análise do comportamento.
   • SIEM é unha boa ferramenta para investigacións, pero non é capaz de ver e mostrar algo novo e orixinal de forma oportuna, porque as regras de correlación son as mesmas que as sinaturas.

7. Como resultado, é necesaria unha ferramenta que:
   • traballou con éxito en condicións dun perímetro xa comprometido,
   • detectou ataques exitosos case en tempo real, independentemente das ferramentas e vulnerabilidades utilizadas,
   • non dependía de sinaturas/regras/scripts/políticas/perfís e outras cousas estáticas,
   • non requiriu grandes cantidades de datos e as súas fontes para a súa análise,
   • permitiría definir os ataques non como algún tipo de puntuación de risco como resultado do traballo dos "mellores do mundo, matemáticas patentadas e, polo tanto, pechadas", o que require unha investigación adicional, senón practicamente como un evento binario - "Si, estamos sendo atacados" ou "Non, todo está ben",
   • era universal, escalable de forma eficiente e factible de implementar en calquera ambiente heteroxéneo, independentemente da topoloxía de rede física e lóxica utilizada.

As chamadas solucións de engano compiten agora polo papel desta ferramenta. É dicir, solucións baseadas no bo vello concepto dos honeypots, pero cun nivel de implantación completamente diferente. Este tema definitivamente está en aumento agora.

Segundo os resultados Cumio de xestión de Gartner Security & Risc 2017 As solucións de engano están incluídas nas 3 principais estratexias e ferramentas que se recomenda utilizar.

Segundo o informe TAG Cybersecurity Annual 2017 O engano é unha das principais direccións de desenvolvemento das solucións IDS Intrusion Detection Systems).

Todo un apartado deste último Informe sobre o estado da seguridade informática de Cisco, dedicada a SCADA, baséase nos datos dun dos líderes neste mercado, TrapX Security (Israel), cuxa solución leva un ano traballando na nosa área de probas.

TrapX Deception Grid permítelle custar e operar IDS distribuídos masivamente de forma centralizada, sen aumentar a carga de licenzas e os requisitos para os recursos de hardware. De feito, TrapX é un construtor que che permite crear a partir de elementos da infraestrutura de TI existente un gran mecanismo para detectar ataques a escala empresarial, unha especie de "alarma" de rede distribuída.

Estrutura da solución

No noso laboratorio estudamos e probamos constantemente diversos novos produtos no campo da seguridade informática. Actualmente, uns 50 servidores virtuais diferentes están despregados aquí, incluíndo compoñentes TrapX Deception Grid.

Entón, de arriba a abaixo:

1. TSOC (TrapX Security Operation Console) é o cerebro do sistema. Esta é a consola de xestión central a través da cal se realiza a configuración, o despregamento da solución e todas as operacións do día a día. Dado que este é un servizo web, pódese implementar en calquera lugar: no perímetro, na nube ou nun provedor de MSSP.
2. TrapX Appliance (TSA) é un servidor virtual no que conectamos, mediante o porto troncal, aquelas subredes que queremos cubrir con monitorización. Ademais, todos os nosos sensores de rede realmente "viven" aquí.

   O noso laboratorio ten un TSA implantado (mwsapp1), pero en realidade podería haber moitos. Isto pode ser necesario en redes grandes onde non hai conectividade L2 entre segmentos (un exemplo típico é "Holding e filiais" ou "Sede central e sucursais do banco") ou se a rede ten segmentos illados, por exemplo, sistemas de control de procesos automatizados. En cada rama/segmento deste tipo, pode implementar a súa propia TSA e conectala a un único TSOC, onde toda a información será procesada de forma centralizada. Esta arquitectura permítelle construír sistemas de monitorización distribuídos sen necesidade de reestruturar radicalmente a rede ou interromper a segmentación existente.

   Ademais, podemos enviar unha copia do tráfico de saída a TSA a través de TAP/SPAN. Se detectamos conexións con botnets coñecidas, servidores de comando e control ou sesións TOR, tamén recibiremos o resultado na consola. O sensor de intelixencia de rede (NIS) é o responsable diso. No noso entorno, esta funcionalidade está implementada no firewall, polo que non a usamos aquí.

3. Trampas de aplicacións (SO completo): honeypots tradicionais baseados en servidores Windows. Non precisa de moitos deles, xa que a finalidade principal destes servidores é proporcionar servizos informáticos á seguinte capa de sensores ou detectar ataques a aplicacións empresariais que se poidan despregar nun entorno Windows. Temos un servidor deste tipo instalado no noso laboratorio (FOS01)

   

4. As trampas emuladas son o principal compoñente da solución, que nos permite, mediante unha única máquina virtual, crear un "campo minado" moi denso para os atacantes e saturar a rede empresarial, todos os seus vlans, cos nosos sensores. O atacante ve ese sensor, ou host fantasma, como un verdadeiro PC ou servidor Windows, servidor Linux ou outro dispositivo que decidimos mostrarlle.

   
   
   Polo ben do negocio e por curiosidade, despregamos "un par de cada criatura": PCs con Windows e servidores de varias versións, servidores Linux, un caixeiro automático con Windows incorporado, SWIFT Web Access, unha impresora de rede, un Cisco. interruptor, unha cámara IP Axis, un MacBook, un dispositivo PLC e ata unha bombilla intelixente. Son 13 anfitrións en total. En xeral, o vendedor recomenda a implantación destes sensores nunha cantidade de polo menos o 10% do número de servidores reais. A barra superior é o espazo de enderezos dispoñible.

   Un punto moi importante é que cada un destes servidores non é unha máquina virtual completa que require recursos e licenzas. Este é un señuelo, emulación, un proceso na TSA, que ten un conxunto de parámetros e un enderezo IP. Polo tanto, coa axuda dun mesmo TSA, podemos saturar a rede con centos de hosts fantasmas deste tipo, que funcionarán como sensores no sistema de alarma. É esta tecnoloxía a que fai posible escalar de xeito rendible o concepto de honeypot en calquera gran empresa distribuída.

   Desde o punto de vista dun atacante, estes hosts son atractivos porque conteñen vulnerabilidades e parecen ser obxectivos relativamente fáciles. O atacante ve servizos nestes servidores e pode interactuar con eles e atacalos mediante ferramentas e protocolos estándar (smb/wmi/ssh/telnet/web/dnp/bonjour/Modbus, etc.). Pero é imposible usar estes hosts para desenvolver un ataque ou executar o teu propio código.

5. A combinación destas dúas tecnoloxías (FullOS e trampas emuladas) permítenos acadar unha alta probabilidade estatística de que un atacante se atope tarde ou cedo con algún elemento da nosa rede de sinalización. Pero, como podemos asegurarnos de que esta probabilidade sexa preto do 100%?

   As chamadas fichas de Engano entran na batalla. Grazas a eles, podemos incluír todos os ordenadores e servidores existentes da empresa no noso IDS distribuído. Os tokens colócanse nos ordenadores reais dos usuarios. É importante entender que os tokens non son axentes que consumen recursos e poden causar conflitos. Os tokens son elementos de información pasivos, unha especie de "migas de pan" para o bando atacante que o conducen a unha trampa. Por exemplo, unidades de rede mapeadas, marcadores para falsos administradores web no navegador e contrasinais gardados para eles, sesións ssh/rdp/winscp gardadas, as nosas trampas con comentarios en ficheiros hosts, contrasinais gardados na memoria, credenciais de usuarios inexistentes, oficina ficheiros, apertura que activará o sistema e moito máis. Así, situamos ao atacante nun ambiente distorsionado, saturado de vectores de ataque que en realidade non supoñen unha ameaza para nós, senón todo o contrario. E non ten forma de determinar onde a información é verdadeira e onde é falsa. Así, non só aseguramos a detección rápida dun ataque, senón que tamén ralentizamos significativamente o seu progreso.

Un exemplo de creación dunha trampa de rede e configuración de tokens. Interface amigable e sen edición manual de configuracións, scripts, etc.

No noso entorno, configuramos e colocamos unha serie de tales tokens en FOS01 con Windows Server 2012R2 e nun PC de proba con Windows 7. RDP está a executarse nestas máquinas e periódicamente "colgámolas" na DMZ, onde algúns dos nosos sensores. (trampas emuladas) tamén se mostran. Entón temos un fluxo constante de incidentes, naturalmente por así dicilo.

Entón, aquí tes algunhas estatísticas rápidas do ano:

56 - incidentes rexistrados,
2: detectáronse hosts fonte de ataque.

Mapa de ataque interactivo e clicable

Ao mesmo tempo, a solución non xera ningún tipo de mega-log ou feed de eventos, o que leva moito tempo entender. Pola contra, a propia solución clasifica os eventos segundo os seus tipos e permite que o equipo de seguridade da información se centre principalmente nos máis perigosos: cando o atacante tenta crear sesións de control (interacción) ou cando aparecen cargas útiles binarias (infección) no noso tráfico.

Toda a información sobre eventos é lexible e preséntase, na miña opinión, de forma fácil de entender incluso para un usuario con coñecementos básicos no campo da seguridade da información.

A maioría dos incidentes rexistrados son intentos de escanear os nosos hosts ou conexións individuais.

Ou intentos de forza bruta contrasinais para RDP

Pero tamén houbo casos máis interesantes, especialmente cando os atacantes "conseguiron" adiviñar o contrasinal de RDP e acceder á rede local.

Un atacante tenta executar código usando psexec.

O atacante atopou unha sesión gardada, o que o levou a unha trampa en forma de servidor Linux. Inmediatamente despois de conectarse, cun conxunto de comandos preparado previamente, intentou destruír todos os ficheiros de rexistro e as correspondentes variables do sistema.

Un atacante tenta realizar unha inxección de SQL nun honeypot que imita a SWIFT Web Access.

Ademais destes ataques "naturais", tamén realizamos unha serie de probas propias. Un dos máis reveladores é probar o tempo de detección dun verme de rede nunha rede. Para iso utilizamos unha ferramenta de GuardiCore chamada Mono de infección. Este é un verme de rede que pode secuestrar Windows e Linux, pero sen ningunha "carga útil".
Desprazamos un centro de mando local, lanzamos a primeira instancia do verme nunha das máquinas e recibimos a primeira alerta na consola TrapX en menos de minuto e medio. TTD 90 segundos fronte a 106 días de media...

Grazas á capacidade de integrarnos con outras clases de solucións, podemos pasar de detectar ameazas rapidamente a responder automaticamente a elas.

Por exemplo, a integración con sistemas NAC (Network Access Control) ou con CarbonBlack permitirache desconectar automaticamente da rede ordenadores comprometidos.

A integración con sandbox permite que os ficheiros implicados nun ataque sexan enviados automaticamente para a súa análise.

Integración con McAfee

A solución tamén ten o seu propio sistema de correlación de eventos incorporado.

Pero non estabamos satisfeitos coas súas capacidades, polo que o integramos con HP ArcSight.

O sistema de ticketing integrado axuda a todo o mundo a facer fronte ás ameazas detectadas.

Dado que a solución foi desenvolvida "desde o principio" para as necesidades das axencias gobernamentais e dun gran segmento corporativo, implementa naturalmente un modelo de acceso baseado en roles, integración con AD, un sistema desenvolvido de informes e disparadores (alertas de eventos), orquestración para grandes estruturas holding ou provedores de MSSP.

En lugar dun currículo

Se existe un sistema de vixilancia deste tipo, que, en sentido figurado, cobre as nosas costas, entón co compromiso do perímetro todo está a comezar. O máis importante é que exista unha oportunidade real de facer fronte aos incidentes de seguridade da información, e non de facer fronte ás súas consecuencias.

Fonte: www.habr.com