Um buraco como ferramenta de segurança - 2, ou como capturar a “isca viva” do APT

(obrigado pela ideia do título, graças a Sergey G. Brester sebres )

Colegas, o objetivo deste artigo é o desejo de compartilhar a experiência de uma operação de teste de um ano de uma nova classe de soluções IDS baseada em tecnologias Deception.



Para preservar a coerência lógica da apresentação do material, considero necessário começar pelas premissas. Então, os problemas:

1. Os ataques direcionados são o tipo mais perigoso de ataques, apesar de sua participação no número total de ameaças ser pequena.
2. Ainda não foi inventado algum tipo de meio eficaz garantido de proteger o perímetro (ou um complexo de tais meios).
3. Como regra, ataques direcionados ocorrem em várias etapas. Superar o perímetro é apenas um dos estágios iniciais, que (você pode atirar pedras em mim) não causa muito dano à "vítima", a menos que seja, é claro, um ataque DEoS (Destruição de serviço) (criptografadores, etc.). A verdadeira "dor" começa depois, quando os ativos apreendidos começam a ser usados ​​para girar e desenvolver um ataque "profundo", mas não percebemos isso.
4. Como começamos a sofrer perdas reais quando os invasores atingem os objetivos do ataque (servidor de aplicativos, DBMS, armazenamento de dados, repositórios, elementos críticos da infraestrutura), é lógico que uma das tarefas do serviço de SI seja interromper os ataques antes desse triste evento. Mas, para interromper algo, você deve primeiro descobrir sobre isso. E quanto mais cedo melhor.
5. Portanto, para o gerenciamento bem-sucedido de riscos (ou seja, para reduzir os danos causados ​​por ataques direcionados), é essencial ter ferramentas que forneçam um TTD mínimo (tempo para detectar - o tempo desde o momento da invasão até o momento em que o ataque é detectado). Dependendo do setor e da região, esse período é em média de 99 dias nos EUA, 106 dias na região EMEA e 172 dias na região APAC (M-Trends 2017, Uma visão das linhas de frente, Mandiant).
6. O que o mercado oferece?
   
   • Caixas de areia. Outro controle preventivo que está longe de ser o ideal. Existem inúmeras técnicas eficazes para detectar e contornar caixas de areia ou soluções de lista branca. Os caras do "lado sombrio" ainda estão um passo à frente.
     
   • UEBA (perfil de comportamento e sistemas de detecção de desvio) - em teoria, pode ser muito eficaz. Mas, na minha opinião, isso será em algum momento distante. Na prática, ainda é muito caro, não confiável e requer uma infraestrutura de segurança de TI e informação muito madura e estável, que já possui todas as ferramentas que gerarão dados para análise comportamental.
     
   • O SIEM é uma boa ferramenta para investigações, mas não é capaz de ver e mostrar algo a tempo, porque as regras de correlação são as mesmas assinaturas.
   
   
7. Como resultado, amadureceu a necessidade de um instrumento que:
   
   • trabalhou com sucesso em condições de perímetro já comprometido,
     
   • detectou ataques bem-sucedidos no modo quase em tempo real, independentemente das ferramentas e das vulnerabilidades usadas,
   • não depende de assinaturas / regras / scripts / políticas / perfis e outras coisas estáticas,
   • não exigia a disponibilidade de grandes quantidades de dados e suas fontes para análise,
   • Isso permitiria definir ataques não como uma espécie de pontuação de risco como resultado do trabalho dos "melhores do mundo, patenteados e, portanto, da matemática fechada", o que requer investigação adicional, mas praticamente como um evento binário - "Sim, eles nos atacam" ou "Não, está tudo bem"
   • Era universal, efetivamente escalável e realmente implementado em qualquer ambiente heterogêneo, independentemente da topologia de rede física e lógica usada.

As chamadas soluções de engano agora reivindicam o papel de tal ferramenta. Ou seja, soluções baseadas no bom e velho conceito de hanipot, mas com um nível de implementação completamente diferente. Este tópico está agora claramente em ascensão.

De acordo com os resultados da cúpula de gerenciamento do Gartner Security & Risc 2017, as soluções Deception estão incluídas nas 3 principais estratégias e ferramentas recomendadas para serem aplicadas.

De acordo com o relatório anual Deception da TAG Cybersecurity 2017 , a Deception é uma das principais linhas de desenvolvimento das soluções IDS Intrusion Detection Systems.

A seção inteira do último relatório de status de segurança de TI da Cisco no SCADA é construída com base nos dados de um dos líderes de mercado TrapX Security (Israel), cuja solução está em funcionamento na nossa zona de teste há um ano.

A TrapX Deception Grid permite custar e operar um IDS distribuído em massa centralmente, sem aumentar a carga de licenciamento e os requisitos de hardware. De fato, o TrapX é um construtor que permite criar a partir dos elementos da infraestrutura de TI existente um grande mecanismo para detectar ataques de toda a escala da empresa, uma espécie de "sinalização" de rede distribuída.

Estrutura da solução

Em nosso laboratório, estudamos e testamos constantemente várias inovações no campo da segurança de TI. Agora, cerca de 50 servidores virtuais diferentes são implantados aqui, incluindo os componentes da TrapX Deception Grid.



Então, de cima para baixo:

1. TSOC (TrapX Security Operation Console) - o cérebro do sistema. Este é o console de gerenciamento central com o qual você pode configurar, implantar a solução e todo o trabalho diário. Por ser um serviço da Web, ele pode ser implantado em qualquer lugar - no perímetro, na nuvem ou no provedor MSSP.
2. O TrapX Appliance (TSA) é um servidor virtual no qual usamos a porta de tronco para conectar as sub-redes que queremos monitorar. Além disso, todos os nossos sensores de rede realmente "vivem" aqui.
   
   Há um TSA (mwsapp1) implantado em nosso laboratório, mas, na realidade, pode haver muitos. Isso pode ser necessário em grandes redes onde não há conectividade L2 entre segmentos (um exemplo típico é "Holding e subsidiárias" ou "Sede e filiais do banco") ou se houver segmentos isolados na rede, por exemplo, sistemas de controle de processo. Em cada filial / segmento, você pode implantar seu TSA e conectá-lo a um único TSOC, onde todas as informações serão processadas centralmente. Essa arquitetura permite criar sistemas de monitoramento distribuído sem a necessidade de uma reestruturação fundamental da rede ou quebra da segmentação existente.
   
   Além disso, na TSA, podemos enviar uma cópia do tráfego de saída através da TAP / SPAN. Em caso de detecção de conexões com redes de bots, servidores de comando e sessões TOR conhecidas, também obteremos o resultado no console. O NIS (Network Intelligence Sensor) é responsável por isso. Em nosso ambiente, essa funcionalidade é implementada no firewall, portanto, não a usamos aqui.
3. Interceptações de aplicativos (SO completo) - identificadores de servidor tradicionais baseados no Windows. Eles não exigem muito, pois a principal tarefa desses servidores é fornecer serviços de TI para o próximo nível de sensores ou identificar ataques a aplicativos de negócios que podem ser implantados em um ambiente Windows. Temos um desses servidores instalado em laboratório (FOS01)
   
   
   
4. Armadilhas emuladas - o principal componente da solução, que nos permite usar uma única máquina virtual para criar um campo "minado" muito denso para atacantes e saturar a rede corporativa, todas as suas vlan-s, com nossos sensores. O invasor vê um sensor ou host fantasma, como um PC ou servidor Windows real, um servidor Linux ou outro dispositivo que decidimos mostrá-lo.
   
   
   
   Para fins de negócios e curiosidade, implantamos “todas as criaturas em pares” - PCs e servidores Windows de várias versões, servidores Linux, ATM com Windows incorporado, SWIFT Web Access, impressora de rede, switch Cisco, câmera Axis IP, MacBook, PLC -dispositivo e até uma lâmpada inteligente. No total - 13 hosts. Em geral, o fornecedor recomenda implantar esses sensores em uma quantidade de pelo menos 10% do número de hosts reais. A barra superior é o espaço de endereço disponível.
   
   Um ponto muito importante é que cada host não é uma máquina virtual completa que requer recursos e licenças. Esse é um problema, emulação, um processo no TSA, que possui um conjunto de parâmetros e um endereço IP. Portanto, com a ajuda de até um TSA, podemos saturar a rede com centenas de hosts fantasmas que atuarão como sensores no sistema de alarme. É essa tecnologia que permite escalar economicamente de forma eficaz o conceito de "Hanipot" na escala de qualquer grande empresa distribuída.
   
   Do ponto de vista do lado atacante, esses hosts são atraentes porque contêm vulnerabilidades e parecem alvos relativamente fáceis. O invasor vê os serviços nesses hosts e pode interagir com eles, atacando-os usando ferramentas e protocolos padrão (smb / wmi / ssh / telnet / web / dnp / bonjour / Modbus, etc.). Mas usar esses hosts para desenvolver um ataque e lançar seu código é impossível.
   
5. A combinação dessas duas tecnologias (FullOS e traps emulados) nos permite obter uma alta probabilidade estatística de que um invasor, mais cedo ou mais tarde, encontre qualquer elemento de nossa rede de sinais. Mas como tornar essa probabilidade próxima de 100%?
   
   Os chamados tokens (Deception tokens) entram na batalha. Graças a eles, podemos incluir em nosso IDS distribuído todos os PCs e servidores corporativos disponíveis. Os tokens são colocados em usuários reais de PC. É importante entender que os tokens não são um agente que consome recursos e pode causar conflitos. Os tokens são elementos de informação passivos, uma espécie de "migalhas de pão" para o lado atacante, que o levam a uma armadilha. Por exemplo, unidades de rede mapeadas, indicadores para administradores da Web falsos no navegador e senhas salvas para eles, sessões ssh / rdp / winscp salvas, nossos traps com comentários em arquivos de hosts, senhas armazenadas na memória, credenciais de usuários inexistentes, arquivos de escritório, abertura o que acionará o sistema e muito mais. Assim, colocamos o atacante em um ambiente distorcido saturado com os vetores de ataque que realmente não representam uma ameaça para nós, mas o oposto. E ele não tem como determinar onde está a informação verdadeira e onde é falsa. Assim, não apenas fornecemos uma definição rápida de um ataque, mas também diminuímos significativamente seu progresso.

Um exemplo de criação de uma interceptação de rede e configuração de tokens. Interface amigável e edição manual de configurações, scripts, etc.

Em nosso ambiente, configuramos e colocamos vários tokens no FOS01 executando o Windows Server 2012R2 e um PC de teste no Windows 7. Essas máquinas executam o RDP e periodicamente as “postamos” na DMZ, que também exibe vários de nossos sensores (traps emulados). Assim, temos um fluxo constante de incidentes, por assim dizer, de uma maneira natural.

Então, uma breve estatística para o ano:

56 208 - incidentes registrados
2 912 - hosts de origem de ataque detectados.


Mapa de ataque interativo e clicável

Ao mesmo tempo, a solução não gera nenhum mega-log ou feed de eventos, nos quais leva muito tempo para entender. Em vez disso, a própria solução classifica os eventos por tipos e permite que a equipe de IS se concentre principalmente nos mais perigosos - quando a parte atacante tenta aumentar as sessões de controle (interação) ou quando cargas binárias (infecção) aparecem em nosso tráfego.



Todas as informações sobre os eventos são legíveis e apresentadas, na minha opinião, de forma fácil de entender, mesmo para um usuário com conhecimentos básicos no campo da segurança da informação.

A maioria dos incidentes relatados são tentativas de verificar nossos hosts ou conexões únicas.



Ou tentativas de adivinhação de senha para RDP



Mas houve casos mais interessantes, especialmente quando os invasores "conseguiram" pegar uma senha para o RDP e obter acesso à rede local.



Um invasor está tentando executar código usando o psexec.



O invasor encontrou uma sessão salva que o prendeu como um servidor Linux. Imediatamente após conectar-se a um conjunto predefinido de comandos, ele tentou destruir todos os arquivos de log e as variáveis ​​de sistema correspondentes.



O invasor tenta injetar SQL em uma armadilha que imita o SWIFT Web Access.

Além desses ataques "naturais", realizamos vários testes próprios. Um dos mais indicativos é testar o tempo de detecção de um worm de rede em uma rede. Para fazer isso, usamos uma ferramenta do GuardiCore chamada Infection Monkey . Este é um worm de rede que pode capturar Windows e Linux, mas sem algum tipo de "carga útil".
Implementamos um centro de comando local, lançamos a primeira instância de worm em uma das máquinas e recebemos a primeira notificação no console do TrapX em menos de um minuto e meio. TTD 90 segundos contra 106 dias em média ...

Graças à capacidade de integração com outras classes de soluções, só podemos passar da detecção rápida de ameaças para a resposta automática a elas.

Por exemplo, a integração com os sistemas NAC (Network Access Control) ou com o CarbonBlack desconectará automaticamente os PCs comprometidos da rede.



A integração com sandboxes permite transferir automaticamente arquivos envolvidos no ataque para análise.

Integração da McAfee

A solução também possui seu próprio sistema interno de correlação de eventos.



Como os recursos dela não eram adequados para nós, nós o integramos ao HP ArcSight.



O sistema de bilhética integrado ajuda a lidar com as ameaças detectadas "em todo o mundo".



Desde que a solução "desde o início" foi desenvolvida para as necessidades de agências governamentais e de um grande segmento corporativo, é claro que é implementado um modelo de acesso baseado em função, integração com o AD, um sistema desenvolvido de relatórios e gatilhos (alertas de eventos), orquestração para grandes estruturas de retenção ou provedores de MSSP.

Em vez de um currículo

Se existe um sistema de monitoramento semelhante que, figurativamente falando, cobre nossas costas, então, com o comprometimento do perímetro, tudo está apenas começando. Mais importante ainda, há uma oportunidade real de lidar com incidentes de segurança da informação e não de lidar com suas conseqüências.