Visão Total TS. Coleta de eventos, análise de incidentes e ferramenta de automação de resposta a ameaças

Visão Total TS. Coleta de eventos, análise de incidentes e ferramenta de automação de resposta a ameaças

Boa tarde, em artigos anteriores conhecemos o trabalho do ELK Stack. Agora vamos discutir as possibilidades que podem ser realizadas por um especialista em segurança da informação na utilização desses sistemas. Quais logs podem e devem ser inseridos no elasticsearch. Vamos considerar quais estatísticas podem ser obtidas configurando painéis e se há algum lucro nisso. Como você pode implementar a automação de processos de segurança da informação usando a pilha ELK. Vamos traçar a arquitetura do sistema. No total, a implementação de todas as funcionalidades é uma tarefa muito grande e difícil, por isso a solução recebeu um nome separado - TS Total Sight.

Atualmente, soluções que consolidam e analisam incidentes de segurança da informação em um local lógico estão ganhando popularidade rapidamente, com isso, o especialista recebe estatísticas e uma linha de atuação para melhorar o estado da segurança da informação na organização. Estabelecemos essa tarefa ao usar a pilha ELK e, como resultado, dividimos a funcionalidade principal em 4 seções:

  1. Estatísticas e visualização;
  2. Detecção de incidentes de segurança da informação;
  3. Priorização de incidentes;
  4. Automação de processos de segurança da informação.

A seguir, examinaremos mais de perto cada um individualmente.

Detecção de incidentes de segurança da informação

A principal tarefa do uso do elasticsearch em nosso caso é coletar apenas incidentes de segurança da informação. Você pode coletar incidentes de segurança da informação de qualquer meio de segurança se eles suportarem pelo menos alguns modos de envio de logs, o padrão é syslog ou scp salvando em um arquivo.

Você pode dar exemplos padrão de ferramentas de segurança e muito mais, de onde você deve configurar o encaminhamento de logs:

  1. Quaisquer ferramentas NGFW (Check Point, Fortinet);
  2. Quaisquer scanners de vulnerabilidade (PT Scanner, OpenVas);
  3. Firewall de Aplicações Web (PT AF);
  4. analisadores de netflow (Flowmon, Cisco StealthWatch);
  5. Servidor AD.

Depois de configurar o envio de logs e arquivos de configuração no Logstash, você pode correlacionar e comparar com incidentes provenientes de diversas ferramentas de segurança. Para isso, é conveniente utilizar índices nos quais armazenaremos todos os incidentes relacionados a um determinado dispositivo. Em outras palavras, um índice representa todos os incidentes em um dispositivo. Esta distribuição pode ser implementada de 2 maneiras.

Primeira forma de realização Isso é para definir a configuração do Logstash. Para fazer isso, você precisa duplicar o log de determinados campos em uma unidade separada com um tipo diferente. E então use esse tipo no futuro. No exemplo, os logs são clonados da lâmina IPS do firewall Check Point.

filter {
    if [product] == "SmartDefense" {
        clone {
	    clones => ["CloneSmartDefense"]
	    add_field => {"system" => "checkpoint"}
	}
    }
}

Para salvar tais eventos em um índice separado dependendo dos campos de log, por exemplo, como assinaturas de ataque IP de destino. Você pode usar uma construção semelhante:

output {
    if [type] == "CloneSmartDefense"{
    {
         elasticsearch {
    	 hosts => [",<IP_address_elasticsearch>:9200"]
    	 index => "smartdefense-%{dst}"
    	 user => "admin"
    	 password => "password"
  	 }
    }
}

E desta forma, você pode salvar todos os incidentes em um índice, por exemplo, por endereço IP, ou por nome de domínio da máquina. Neste caso, salvamos no índice "smartdefense-%{dst}", pelo endereço IP do destino da assinatura.

No entanto, produtos diferentes terão campos de log diferentes, o que levará ao caos e ao consumo desnecessário de memória. E aqui você terá que substituir cuidadosamente os campos nas configurações do Logstash por outros pré-concebidos, que serão os mesmos para todos os tipos de incidentes, o que também é uma tarefa difícil.

Segunda opção de implementação - isto é escrever um script ou processo que irá acessar o banco de dados elástico em tempo real, extrair os incidentes necessários e salvá-los em um novo índice, esta é uma tarefa difícil, mas permite que você trabalhe com logs como quiser, e correlacionar diretamente com incidentes de outros equipamentos de segurança. Esta opção permite configurar o trabalho com logs da forma mais útil para o seu caso com a máxima flexibilidade, mas aqui surge o problema de encontrar um especialista que possa implementar isso.

E claro, a pergunta mais importante, e o que pode ser correlacionado e detectado??

Pode haver várias opções aqui, e isso depende de quais ferramentas de segurança são usadas em sua infraestrutura, alguns exemplos:

  1. A opção mais óbvia e, do meu ponto de vista, mais interessante para quem tem uma solução NGFW e um scanner de vulnerabilidades. Esta é uma comparação dos logs IPS e dos resultados da verificação de vulnerabilidades. Se um ataque foi detectado (não bloqueado) pelo sistema IPS, e esta vulnerabilidade não é fechada na máquina final com base nos resultados da verificação, é necessário denunciar, pois há uma grande probabilidade de que a vulnerabilidade tenha sido explorada .
  2. Muitas tentativas de login de uma máquina para locais diferentes podem simbolizar atividade maliciosa.
  3. Usuário baixando arquivos de vírus devido à visita a um grande número de sites potencialmente perigosos.

Estatísticas e visualização

A coisa mais óbvia e compreensível para a qual o ELK Stack é necessário é o armazenamento e visualização de logs, em artigos anteriores foi mostrado como você pode criar logs de vários dispositivos usando Logstash. Após os logs irem para o Elasticsearch, você pode configurar dashboards, que também foram mencionados em artigos anteriores, com as informações e estatísticas que você precisa por meio de visualização.

Примеры:

  1. Painel para eventos de Prevenção de Ameaças com os eventos mais críticos. Aqui você pode refletir quais assinaturas IPS foram detectadas e de onde elas vêm geograficamente.

    Visão Total TS. Coleta de eventos, análise de incidentes e ferramenta de automação de resposta a ameaças

  2. Dashboard sobre o uso dos aplicativos mais críticos para os quais informações podem ser vazadas.

    Visão Total TS. Coleta de eventos, análise de incidentes e ferramenta de automação de resposta a ameaças

  3. Resultados da verificação de qualquer scanner de segurança.

    Visão Total TS. Coleta de eventos, análise de incidentes e ferramenta de automação de resposta a ameaças

  4. Logs do Active Directory por usuário.

    Visão Total TS. Coleta de eventos, análise de incidentes e ferramenta de automação de resposta a ameaças

  5. Painel de conexão VPN.

Nesse caso, se você configurar os painéis para atualização a cada poucos segundos, poderá obter um sistema bastante conveniente para monitorar eventos em tempo real, que pode então ser usado para uma resposta mais rápida a incidentes de segurança da informação se você colocar os painéis em um local separado. tela.

Priorização de incidentes

Nas condições de grande infraestrutura, o número de incidentes pode disparar e os especialistas não terão tempo para lidar com todos os incidentes a tempo. Neste caso, é necessário, em primeiro lugar, destacar apenas os incidentes que representam uma grande ameaça. Portanto, o sistema deve priorizar os incidentes com base na gravidade deles em relação à sua infraestrutura. É aconselhável configurar um alerta por e-mail ou telegrama para esses eventos. A priorização pode ser implementada usando ferramentas padrão do Kibana configurando a visualização. Mas com notificações é mais difícil, por padrão essa funcionalidade não está incluída na versão básica do Elasticsearch, apenas na versão paga. Portanto, compre uma versão paga ou, novamente, escreva você mesmo um processo que notificará os especialistas em tempo real por e-mail ou telegrama.

Automação de processos de segurança da informação

E uma das partes mais interessantes é a automatização de ações para incidentes de segurança da informação. Anteriormente implementamos esta funcionalidade para o Splunk, você pode ler um pouco mais neste статье. A ideia principal é que a política de IPS nunca seja testada ou otimizada, embora em alguns casos seja uma parte crítica dos processos de segurança da informação. Por exemplo, um ano após a implementação do NGFW e a ausência de ações de otimização do IPS, você acumulará um grande número de assinaturas com a ação Detectar, que não serão bloqueadas, o que reduz bastante o estado de segurança da informação na organização. Abaixo estão alguns exemplos do que pode ser automatizado:

  1. Transferência de assinatura IPS de Detectar para Prevenir. Se o Prevent não funcionar para assinaturas críticas, então isso está fora de serviço e é uma séria lacuna no sistema de proteção. Mudamos a ação na política para tais assinaturas. Esta funcionalidade pode ser implementada se o dispositivo NGFW tiver funcionalidade REST API. Isso só é possível se você tiver habilidades de programação; você precisa extrair as informações necessárias do Elastcisearch e fazer solicitações de API ao servidor de gerenciamento NGFW.
  2. Se várias assinaturas foram detectadas ou bloqueadas no tráfego de rede de um endereço IP, faz sentido bloquear esse endereço IP por um tempo na política de Firewall. A implementação também consiste na utilização da API REST.
  3. Execute uma verificação de host com um scanner de vulnerabilidade, se este host tiver um grande número de assinaturas IPS ou outras ferramentas de segurança; se for OpenVas, você poderá escrever um script que se conectará via ssh ao scanner de segurança e executará a verificação.

Visão Total TS. Coleta de eventos, análise de incidentes e ferramenta de automação de resposta a ameaças

Visão Total TS

No total, a implementação de todas as funcionalidades é uma tarefa muito grande e difícil. Sem ter conhecimentos de programação, você pode configurar funcionalidades mínimas, que podem ser suficientes para uso em produção. Mas se você estiver interessado em todas as funcionalidades, fique atento ao TS Total Sight. Você pode encontrar mais detalhes em nosso On-line. Como resultado, todo o esquema de operação e arquitetura ficará assim:

Visão Total TS. Coleta de eventos, análise de incidentes e ferramenta de automação de resposta a ameaças

Conclusão

Vimos o que pode ser implementado usando o ELK Stack. Nos artigos subsequentes, consideraremos separadamente a funcionalidade do TS Total Sight com mais detalhes!

Então fique ligado (Telegram, Facebook, VK, Blog da solução TS), Yandex.Den.

Fonte: habr.com

Adicionar um comentário