Alertas distribuídos com o Elastic Stack

blog-security-radar-720x420.png

Os ambientes de computação moderna e forças de trabalho distribuídas geraram novos desafios para a abordagem de segurança de informação tradicional. Muitas estratégias tradicionais de detecção de ameaças e resposta contam com ambientes homogêneos, linhas de base de sistemas e implementações de controle consistentes. Essas estratégias foram criadas com base em suposições tradicionais sobre os ambientes e podem não ser mais válidas em ambientes específicos, se considerarmos a evolução da computação em nuvem, do trabalho remoto e da cultura moderna.

O Elastic já foi projetado para serdistribuído, com base em nossa tecnologia, para nossa força de trabalho. Os funcionários da Elastic podem trabalhar onde, quando e como quiserem. Isso inclui a escolha das tecnologias que utilizam, as configurações de que precisam e o software que preferem usar. Acolher essa cultura moderna de produtividade gera um novo desafio para a segurança da informação. 

Como podemos manter seguro um ambiente que permite atividades de alto risco, por exemplo, criar novos usuários, configurar proxies de rede e instalar novos software sem o envolvimento da TI? Como podemos aplicar detecções a um ambiente sem linhas de base de atividades? Como redimensionar a prática de detecção e resposta integralmente em uma empresa moderna que opera em inúmeras localidades diferentes, até mesmo em outros países? Como fazer isso sem um centro de operações de segurança (SOC)?

É simples. Enviamos o alerta àqueles que estão mais bem posicionados para confirmar ou negar a atividade por meio de nosso framework de alertas distribuídos. 

Os alertas distribuídos permitem que nossa equipe de detecção de ameaças e resposta identifique automaticamente atividades de risco, envie uma mensagem para nossos funcionários em linguagem natural e peça uma confirmação da atividade. Se o funcionário da Elastic não reconhecer a atividade, o alerta poderá ser encaminhado imediatamente para nossa equipe de resposta a incidentes para remediação. Veja abaixo um exemplo de alerta distribuído que foi enviado para nossos funcionários, informando sobre um novo dispositivo MFA registrado em suas contas:

Se eles reconhecem a atividade, clicam na opção YES: This Was Me. Eles recebem uma instrução pedindo mais informações que possam ser úteis para explicar a atividade ou oportunidades de ajuste.

No backend, um novo caso de segurança é criado, alertas são associados ao caso, os detalhes são registrados e o caso é fechado como “No Impact” (sem impacto), com um resumo do relatório diário.
Se eles não reconhecem a atividade, clicam na opção NO: Escalate to InfoSec. Essa ação gera um novo caso de segurança, que cria um novo canal no Slack e convida a equipe de resposta a incidentes e o relator a comparecerem ao canal para que mais informações sejam dadas à equipe.

Ao enviar essas mensagens diretamente a quem pode confirmar melhor a atividade, podemos manter atualizados nossos índices de positivos reais e falsos das detecções, além de reduzir o tempo que levamos para remediar todas essas detecções “difíceis” de atividades que criam um alto risco, caso sejam ameaças reais que ocorram regularmente em nosso ambiente. 

Que características uma atividade deve apresentar para merecer um alerta distribuído?

O requisito necessário para que as atividades tenham alertas distribuídos é apresentar alto risco à sua postura de segurança, mas sem contexto ou indicação de atividade maliciosa. Por exemplo, um único alerta acionado relatando “New MFA Device Registered” a um usuário não oferece nenhum contexto sobre o intuito da atividade. Os usuários adicionam novos dispositivos MFA às suas contas rotineiramente. Entretanto, se o dispositivo for uma ameaça, a conta será considerada comprometida, já que todas as autenticações subsequentes serão autenticadas com sucesso usando um dispositivo multifator válido. Esse cenário apresenta uma situação difícil para as equipes de detecção de ameaças e resposta. Como podemos validar essas atividades sem nenhum contexto e sem investigar todos os detalhes desses eventos? Com a distribuição desses alertas.

Veja nossa estratégia de detecção de ameaças e conheça mais detalhes. Temos algumas ideias diferentes que oferecem uma cobertura completa das atividades do sistema.

Dividimos nossos eventos em três categorias diferentes:

  • Logs: todos os eventos que ocorrem em um sistema. Os logs geralmente são incluídos em investigações para entender o que ocorreu. Um evento de log não indica nenhuma atividade suspeita. Ele apenas registra o que aconteceu.
  • Sinais: utilizamos a aplicação Elastic Security para gerar sinais. As regras de detecção são escritas para identificar atividades que possam indicar atividade suspeita. Mas, a atividade pode também ser benigna. É difícil confirmar o contexto desses eventos com base em um único evento, portanto, o alerta não é imediato. A detecção de ameaças é projetada levando em consideração os sinais, para identificar atividades relacionadas que possam ser usadas para perceber conteúdo malicioso ou benigno e, assim, ajustar a regra de detecção de um sinal para um alerta se for o caso.
  • Alertas: promovemos os sinais a alertas quando a confiança é alta no sinal indicativo de atividade maliciosa (por exemplo, a probabilidade de atividade maliciosa); ou quando uma atividade tem um alto impacto, fazendo com que todos os eventos precisem ser validados para reduzir a probabilidade do impacto (por exemplo, impacto da atividade maliciosa).

Os alertas com alto impacto mas baixa probabilidade de intenção maliciosa criam uma ótima oportunidade para distribuição de alertas. Assim, podemos validar as atividades administrativas, novas atividades, atividades de usuário anômalas e todas as outras atividades em escala empresarial sem precisar de um SOC tradicional.

Como distribuímos alertas?

Temos, como Cliente Zero dos produtos da Elastic, nosso Elastic Stack no centro da arquitetura SIEM e SOAR. Para saber detalhes de como todos os nossos dados são ingeridos no Elastic Stack, veja nosso post do blog Elastic on Elastic: Data Collected to the InfoSec SIEM (Elastic no Elastic: dados coletados para o InfoSec SIEM).

Fizemos algumas atualizações em nossa arquitetura para permitir esse novo recurso de alertas distribuídos.

Incluímos uma plataforma de automação para centralizar nossos fluxos de trabalho na plataforma de automação sem código do Tines. Os alertas do Elastic Stack usam os fluxos de trabalho criados no Tines e são selecionados e distribuídos com base na lógica predefinida nas histórias do Tines.

Quando uma regra de detecção for marcada para distribuição com DISTRIBUTE_ALERT, o Tines redirecionará o alerta da fila de seleção de alerta e para o fluxo de trabalho de alertas distribuídos.

Todos os alertas que contiverem a tag DISTRIBUTE_ALERT serão executados em todo o nosso fluxo de trabalho de alertas distribuídos. O fluxo de trabalho do Tines identifica o usuário no banco de dados de ativos e, em seguida, envia o alerta ao usuário via Slack para confirmação.

Quando o usuário clica no botão do alerta, ele entra no seguinte fluxo de trabalho para solicitar informações adicionais ou encaminhar o alerta para a equipe de resposta a incidentes.

Esses alertas abrem automaticamente um novo caso nos Cases do Elastic com todas as informações relevantes. Utilizamos automações adicionais para fornecer aos analistas enriquecimentos, como por exemplo, GreyNoise e alertas relacionados do Elastic Security. Os últimos 30 dias de atividade para o endereço IP também são incluídos em uma linha do tempo do Elastic para que o analista possa revisar.

Quando o usuário dá feedback e confirma a atividade, o feedback é registrado no caso, que é fechado. 

Como começar?

Você pode começar com uma avaliação gratuita de 14 dias do Elastic Cloud e utilizar a história de exemplo do Tines Triage Elastic Security alerts and block malicious IPs (Selecione alertas do Elastic Security e bloqueie IPs maliciosos) para começar a ingerir alertas do Elastic Security nos seus fluxos de trabalho de automação. Você então vai precisar fazer a integração com seu cliente de mensagens preferencial. O Tines oferece histórias de exemplo em sua biblioteca para o Slack e o Microsoft Teams.