Uso do Elastic Stack como um canivete suíço para operações de segurança baseada em SaaS

Na RS2, a segurança está no centro de tudo o que fazemos. Nosso carro-chefe, o BankWORKS, é uma solução integrada completa para todas as necessidades de processamento de pagamentos — desde a aquisição de transações de dispositivos até o acordo final e a integração de livros-razão. O software é usado por bancos, processadores e prestadores de serviços de pagamento no mundo inteiro, sejam grandes ou pequenos, simples ou complexos. Também oferecemos o produto como um serviço gerenciado hospedado.

Como equipe, somos responsáveis por garantir a minimização do risco de comprometer ou vazar os dados, em todas as áreas de nosso negócio e, ao mesmo tempo, garantir o cumprimento de vários requisitos de conformidade, além de evitar a interrupção das operações diárias.

Em novembro de 2017, tínhamos planos para aumentar nossa equipe de segurança. Antes de obter aprovação para contratações adicionais, entretanto, precisávamos aliviar parte do esforço manual envolvido ao lidar com incidentes e eventos de segurança. E foi nessa hora que começou nossa jornada com o Elastic Stack.

A jornada da proposta à produção

Etapas iniciais

Como já usei antes o Elastic Stack em outras funções e para projetos pessoais, eu gostaria de apresentar o produto à equipe. Eu achava que ele atenderia a todos os nossos requisitos graças ao seu amplo conjunto de recursos e escalabilidade.

Nos primeiros dias da minha nova função na RS2, executei as instâncias do Elasticsearch e do Kibana (versão 6 neste caso) em uma máquina virtual em meu laptop, instalei alguns Beats na máquina virtual em si (packetbeat, auditbeat, metricbeat e filebeat) e enviei todos os dados diretamente ao Elasticsearch. O processo inteiro levou cerca de uma hora (sendo 40 minutos para fazer download e instalação da imagem ISO do sistema operacional) para que dados significativos fossem populados no Kibana.

Mostrei esse processo ao meu colega e quase que na mesma hora ele concordou que esse era o caminho e que deveríamos criar uma demonstração para a equipe executiva usando dados reais para enfatizar a eficácia. Decidimos incluir alguns dispositivos de rede e servidores existentes que não exigiram nenhuma alteração em nossa rede de produção (usando os Beat e Logstash diferentes), além de algumas integrações de terceiros.

Avaliação da nuvem

Em funções anteriores, hospedei grandes implantações da Elastic em vários servidores. Entretanto, eu nunca realmente analisei a oferta Elastic Cloud. Ocorreu de a RS2 estar em um "congelamento de infraestrutura" devido à iminente migração para a nuvem. Essa situação, aliada a prazos apertados e recursos limitados, levou-me a explorar o Elastic Cloud. Como profissional de segurança, eu estava cético. Queria garantir que o serviço foi projetado com algum nível de segurança em mente.

Como eu já tinha o cluster, fiz alguns testes de segurança rápidos para ver se conseguia identificar quaisquer vulnerabilidades ou fraquezas evidentes. E foi isto o que descobri:

• A Elastic permite escolher entre o AWS e o GCP como provedor de nuvem de backend, por isso todos os recursos de segurança são herdados, juntamente com as respectivas certificações de conformidade.
• As redes segregadas são usadas para cada cluster, e não as sub-redes padrão para cada provedor.
• As cifras e configurações TLS modernas são usadas tanto para os URLs do Elasticsearch quanto do Kibana.
• As portas de transporte do Elasticsearch são randomizadas
• As URLs para cada instância também são randomizadas completamente, por isso não é possível enumerar nomes de clientes.
• O acesso direto a IP não é possível sem o ID de cluster
• As versões mais recentes do Elastic Stack são usadas, juntamente com uma versão recente do Java 8.

Integração

Agora que eu dispunha do meu cluster de nuvem, precisava projetar os fluxos de dados. O diagrama a seguir descreve a arquitetura para o POC.

Como tínhamos o X-Pack disponível para nós, o Watcher foi intensamente utilizado como parte da estrutura de alertas. Isso foi integrado com um Slackbot personalizado usando ações webhook do Watcher.

Preparação da demonstração – manipulação dos dados

A primeira etapa era analisar e enriquecer nossos logs ao máximo. Em um contexto de segurança, o enriquecimento é crucial para resolver incidentes rapidamente, porque ele reduz muito o tempo de investigação para os analistas. Ele também ajuda a filtrar falsos positivos. Usando vários plugins de filtro Logstash, consegui fazer isso com facilidade. Além disso, para complementar a nossa ferramenta de arquivamento de logs existente, consegui configurar várias saídas Logstash para enviar simultaneamente dados ao nosso cluster do Elastic e à ferramenta de arquivamento existente.

A seguir está uma lista de algumas operações de enriquecimento adicionadas aos nossos logs analisados:

• Dados GeoIP (localização e ASN)
• Consultas IP de malware
• Consulta de usuários de logins permitidos
• Análise de agentes de usuários
• Decodificação de URL

Esta é uma lista parcial de enriquecimentos configurados para o POC. Muitos mais foram adicionados depois que fizemos a transição para a produção.

Agora que todos esses dados estavam bem analisados, criei painéis personalizados para trabalhar com aqueles internos para realçar alguns dos recursos de enriquecimento mencionados anteriormente. A seguir estão apenas alguns exemplos de alguns painéis personalizados do Kibana que desenvolvemos para o POC (todos os dados confidenciais foram removidos):

Além disso, adicionei algumas outras integrações estilosas referentes à demonstração para mostrar como é simples adicionar dados ao Elastic. Ao final do dia, trata-se apenas de outro índice. Um exemplo disso foi a integração com o conhecido serviço "Have I been Pwned" de Troy Hunt. O serviço fornece uma API REST bastante útil, que permite consultar se um endereço de e-mail é detectado em violações de dados divulgadas. Foi criado um relógio para nos alertar sobre quaisquer novas entradas para o nosso domínio.

Alertas

A ideia por trás da estrutura de alertas no POC (para ser usado mais tarde em produção) era ter tudo produtivo através do Slack. A seguir estão alguns exemplos dos dados manipulados no Slackbot. Tudo o que um analista precisa ter para dar início a uma investigação está incluído. Os dados usados foram coletados por diferentes Beats, e os logs de dispositivo de rede analisados, via Logstash.

Alguns dos conjuntos de dados incluíram:

• Logs de retransmissão SMTP, logs de autenticação e logs de filtragem de pacote dos nossos firewalls
• Solicitações DNS em nível de pacote, usando o Packetbeat
• Logs SSH/SFTP, usando uma combinação entre Wazuh e Filebeat
• Uma lista de processos e seus estados, usando o Metricbeat
• Monitoramento de soquete de rede de saída, usando o Auditbeat em sistemas *nix

A seguir estão apenas alguns exemplos de alguns alertas Slackbot que desenvolvemos para o POC (todos os dados confidenciais foram removidos):

• Alerta de conexão do TeamViewer
  
  
• Alerta de login de firewall
  
  
• Alerta de malware
  
  

Resultados

Não é preciso dizer que o POC foi extremamente bem-sucedido e obtivemos aprovação para fazer a transição para a produção. Para recapitular, os principais pontos que nos deixaram passar por este POC tão tranquilamente foram:

• A facilidade e velocidade excepcionais de usar o Elastic Cloud e tudo o que ele abrange (backups integrados imediatamente, resiliência e alta disponibilidade, X-Pack integrado para o nosso tamanho de implantação).
• A capacidade de introduzir quaisquer dados e torná-los úteis e produtivos muito rapidamente (o POC, do início ao fim, levou cerca de 3 dias inteiros para implementar, incluindo todas as tarefas mencionadas nesta postagem – análise, painéis, enriquecimento, estrutura de alertas e assim por diante).
• O fato de que isso poderia ser feito paralelamente a todos os processos existentes, sem interrupção.

Manipulação de atualizações

Após algumas semanas em produção, houve uma atualização lançada pela Elastic. Como antes eu tinha atualizado grandes implantações do Elastic com o X-Pack, estava bastante curioso em ver como isso era executado por sua plataforma de nuvem. No final tudo foi tão simples quanto selecionar a nova versão em um menu suspenso. Tudo o mais foi feito automaticamente, sem interrupções.

Conclusão

Nossa jornada com a Elastic evidentemente não terminou aí. Estamos constantemente adicionando mais fontes de dados, mais enriquecimento (como correlação com nossos sistemas de RH para obter dados de férias dos usuários e sistemas de acesso físico para saber se alguém está ou deveria estar no prédio ou não) e adicionando alertas simultaneamente com base em ameaças e atividades maliciosas recém-descobertas. Também estamos trabalhando na integração com ferramentas internas adicionais que usamos.

Estamos empolgados com o futuro da análise de segurança com a Elastic. A cada atualização, a Elastic lança componentes adicionais que tornam as vidas dos analistas mais fáceis, e seus trabalhos mais satisfatórios. Além disso, estamos igualmente empolgados com as próximas atualizações do Elastic Cloud. Sem sombra de dúvida, a RS2 continuará a se beneficiar dos amplos conjuntos de recursos, não só para a análise da segurança, mas em toda a organização.