Indicadores de Comprometimento na detecção de incidentes e redução de falsos positivos na prática

Por Manoelito Carneiro das Neves Filho e Moacir Araújo Candido Bezerra

O MISP (do inglês: Malware Information Sharing Platform) é uma plataforma de inteligência que coleta, compartilha, armazena e contribui na correlação de indicadores de comprometimento (IoCs) ao oferecer aprimoramentos na detecção de incidentes (FOTIADOU, 2020). Diversos times podem fazer uso do MISP para integrar e aperfeiçoar seus processos, auxiliar substancialmente na tomada de decisão e inteligência para detecção de ameaças; o que implica em maior eficácia na detecção, diminuição do tempo de resposta a incidente, ao mesmo tempo que reduz o número de falsos positivos.

Objetivo

Este artigo apresenta como fazer a integração entre MISPs e a sincronização com um SIEM através deste laboratório. O cenário será composto por duas equipes hipotéticas: o time de Inteligência alimentará um MISP e o time de SOC fará uso dos eventos e indicadores de comprometimento (IoCs) publicados pelo time de Inteligência. O conceito forense IoC (do inglês, Indicator of Compromise) define o “pedaço” de informação que auxilia no reconhecimento de uma ou mais ameaças a um sistema.

Ao final deste artigo, você será capaz de implementar um sistema de inteligência com dois MISPs e oferecer integração com um SIEM, através de um serviço desenvolvido pela Tempest: o MISP-broker. Os MISPs serão alimentados pelo time de Inteligência e os analistas SOC irão validar ou invalidar os IoCs, com a devida gestão dos IoCs, com intuito de diminuir falsos positivos, contribuindo para uma performance acurada, conforme representado na Figura 1.

Figura 1 – Implementação do sistema de inteligência com integração completa.

Ambiente

Por praticidade, este artigo fará uso da instância disponível para máquinas virtuais e utilizará o VirtualBox como hypervisor na versão 6.1.26. Faça o download do arquivo em Open Virtual Appliance (OVA), a partir do mirror da última versão [1], neste artigo utilizamos a versão 2.4.150, importe a máquina com a placa de rede em modo bridge – para que faça parte da sua rede local – e inicialize conforme visto na Figura 2. O laboratório proposto poderá ser feito também em ambiente VMWare e o importante é ter as instâncias funcionais e comunicáveis. Lembre-se de sempre consultar a documentação oficial [2].

Figura 2 – MISP inicializado com rede em modo bridge com IP da rede local.

Faça o login com o usuário “misp” e a senha “Password1234”. Lembre-se de alterar a senha padrão para uma forte e configure a URL base da sua instância com o IP da máquina obtido pelo seu servidor DHCP através do seguinte comando:

$ sudo -u www-data /var/www/MISP/app/Console/cake Baseurl https://SEU.IP.AQUI

Figura 3 – Saída do comando para configurar a URL base no MISP.

Esta já será a instância do time Inteligência, acesse o MISP pelo navegador com a credencial padrão [email protected] com senha admin. Desta vez o MISP exigirá a mudança da senha padrão, escolha uma senha forte. Para criar a instância do time SOC, você poderá repetir os passos de criação ou utilizar o recurso de clonagem da instância atual, para tal, desligue a máquina virtual, renomeie para “MISP_v2.X – Intelligence” e crie a instância SOC, a partir do clone da Intelligence. Na política de endereço MAC escolha para que “novos endereços MAC sejam atribuídos para todas as placas de rede”, conforme visto na Figura 4 e isso facilitará a criação da sua segunda instância.

Figura 4 – Criando a instância SOC a partir do clone da instância Intelligence.

Após a clonagem da máquina, lembre-se de repetir o passo para configuração da URL base da nova instância também, afinal de contas, ela terá um outro IP.

Configurações Iniciais

Com as instâncias funcionais e comunicáveis, acesse as máquinas no navegador a partir dos IPs de cada uma. Conforme visto na Figura 5, começaremos editando o nome da organização local da instância Intelligence. Uma vez feito, repita o procedimento para a instância SOC.

Figura 5 – Passo a passo para editar o nome da organização da instância Intelligence.

Para que haja integração entre os MISPs eles precisam se enxergar, e isto é consolidado através da distinção entre os identificadores únicos universais (UUIDs). Como neste artigo a instância SOC foi criada oriunda de um clone, os UUIDs ainda estão iguais e se faz necessário mudá-los, assim mudaremos o UUID da instância SOC conforme visto na Figura 6.

Figura 6 – Passo a passo para gerar novo UUID da instância SOC.

Uma vez de posse do novo UUID da instância SOC, para que a instância Intelligence se comunique SOC, em Intelligence cadastraremos SOC como uma organização não local (ou seja: remota) e apontaremos para seu respectivo UUID, conforme visto na Figura 7.

Figura 7 – Adicionando a organização SOC dentro da instância Intelligence.

Repita o mesmo procedimento dentro da instância SOC, desta vez apontando para a organização Intelligence e seu respectivo UUID. Depois disso, é importante verificar se as instâncias permitem autenticação por token. Em “Administration”, “Server Settings & Maintenance”, na aba “Security Settings”, filtre por “auth” e verifique se “Security.advanced_authkeys“ está “true” conforme verificado na Figura 8.

Figura 8 – Verificar se a autenticação por token está ativa.

Agora, um usuário para sincronização entre os MISPs será adicionado para autenticação por token. O usuário será adicionado na instância SOC para permitir que a instância Intelligence consiga se conectar à instância SOC e enviar IoCs para ela. Na instância SOC, acesse “Administration”, “Add User” e configure conforme visto na Figura 9.

Figura 9 – Configurações para adicionar um usuário de sincronização na instância SOC.

Para associar um token ao usuário criado vamos em “Administration”, “List Auth Keys” e “Add authentication key”, uma janela será aberta, em “User” selecionamos “[email protected]” e escrevemos um comentário a título de documentação: “Token para Inteligência sincronizar com SOC” e submetemos. ATENÇÃO: será necessário copiar o token para um lugar seguro e após copiado clicamos em “I have noted down my key, take me back now”. Agora vamos sincronizar a instância Intelligence com a SOC.

Sincronização entre as Instâncias

Existem duas opções de configuração para sincronização entre as instâncias MISPs, queremos que a instância Intelligence envie os eventos para a instância SOC e, para tal, utilizaremos a opção push, pois o envio de um evento ocorre de forma quase instantânea e automática. Para mais informações, consulte a documentação oficial [3]. Agora, adicionaremos a instância SOC a partir da instância Intelligence conforme visto na Figura 10.

Figura 10 – Configurações para sincronia (em push) com a instância SOC a partir de Intelligence.

Após a submissão, o MISP listará o servidor recém adicionado, teste a conexão ao clicar em “Run”, a saída deverá estar de acordo com a Figura 11.

Figura 11 – Teste de conexão entre as instâncias Intelligence e SOC bem sucedido.

Gestão e Inserção de IoCs

Para um SOC, os IoCs podem ser: User Agents, Hashs, URIs/URLs, IPs, domínios ou até mesmo aumento na leitura do banco de dados ou tráfego de rede. Consequentemente, existem IoCs fixos como Hash e User Agent, assim como temporários, como URL, IP e domínio; o que indica que deve haver uma gestão contínua dos IoCs em relação a análise de fluxo das ameaças por equipes dedicadas para tal função.

A devida gestão dos IoCs, aliada à agilidade operacional, pode contribuir para o enriquecimento dos alertas, casos de uso ou regras de detecção até para cenários em que não há correções oficiais das vulnerabilidades mais recentes. Assim, é possível elevar o poder de detecção – com agilidade e bons processos – para diminuir consideravelmente o tempo de detecção.

Para demonstrar a integração entre os MISPs, adicionaremos na Instância Intelligence um Evento, que será nosso incidente de teste, conforme visto na Figura 12.

Figura 12 – Adicionar um Evento (incidente teste) para então adicionar um atributo (IoC) no MISP Intelligence.

Uma vez criado o evento, o atributo que será caracterizado como IoC será do tipo Network Activity, tipo source ip (ip-src) e terá como valor o IP local da sua máquina hospedeira, neste laboratório é o 192.168.1.13. Essa configuração será importante para a prova de conceito.

Figura 13 – Adicionando um atributo (IoC) do tipo Network Activity no MISP Intelligence.

Uma vez adicionado, faz-se necessário publicar o Evento e, consequentemente, o IoC; a partir do menu lateral esquerdo, clique em “Publish Event” e confirme. Isso fará com que a instância Intelligence envie a informação para a instância SOC, e, para tal, basta acessá-la e listar os eventos conforme visto na Figura 14. Uma vez adicionado em Intelligence, a instância SOC já poderá fazer uso dos Eventos e seus respectivos IoCs.

Figura 14 – Evento compartilhado de Intelligence para SOC.

Integração com o Splunk através do MISP-broker

O MISP-broker disponibilizado neste artigo é o agente responsável que fará a integração entre a instância SOC e o Splunk, assim, ele precisará de credenciais para se conectar em ambos conforme representado na Figura 15.

Figura 15 – Representação da conexão entre o agente (MISP-broker) e o Splunk e MISP SOC.

Este artigo assume que o(a) leitor(a) já possui um servidor Splunk configurado que será utilizado para integrar com o MISP. Existem diversos tutoriais e maneiras de implementar um servidor Splunk, neste laboratório utilizamos uma imagem Debian 10 obtida a partir do projeto OS Boxes [4] e instalamos o Splunk Enterprise 9.0.0.1 instalado a partir do pacote Debian com licença trial e permissão de uso por sessenta dias.

Caso você já não possua, instale o app Lookup File Editor [5] no Splunk e gere um token para que o MISP-broker possa se autenticar no Splunk em: “Settings”, “Tokens (Users and authentication)”, “Enable Token Authentication”, de acordo com a Figura 14 crie e guarde o token em um lugar seguro.

Figura 16 – Gerar token para o MISP-broker.

Dentro da instância SOC geramos um outro token para o MISP-broker em “Administration”, “List Auth Keys” e “Add authentication key”. Em “User” selecionamos “[email protected]” e comentamos para documentar: “Token para o MISP-broker sincronizar com SOC”.

De posse dos dois tokens, faça o download da última versão do MISP-broker a partir deste link para uma máquina que esteja na mesma rede das outras, por exemplo: a sua máquina hospedeira. Se você não tiver conexão, verifique se as máquinas virtuais estão com a placa de rede em modo bridge.

Conforme instruções contidas na documentação [6], instale as dependências, ative o crontab, descompacte o arquivo, renomeie o diretório, crie e edite o arquivo lhebes.cfg conforme representado na Figura 17.

Figura 17 – Inserção dos tokens no MISP-broker.

Após configuração, devemos instalar o virtual environment pelo service.sh na pasta raiz do o broker conforme visto na Figura 18. Caso tudo ocorra com sucesso, o final da instalação deve retornar “All dependencies were successfully installed” seguido de “Venv installation DONE!”.

Figura 18 – Instalação do virtual environment.

O próximo passo exige que o MISP-broker crie as KVs Store no Splunk [7] a partir do comando ./service.sh start lhebes. Verifique os logs com ./service.sh logs lhebes conforme vista na Figura 19.

Figura 19 – Saída (com modificações) após execução do service.sh para criação do app a ser instalado no Splunk.

Junto com a criação das KVs Store, criou-se também um aplicativo que deverá ser instalado no Splunk e, após a instalação do a1_splunk_misp_1.1.4.tar.gz, tem-se as Lookups conforme visto na Figura 20.

Figura 20 – Algumas KVs Store Lookup do MISP SOC criada para uso nas regras do Splunk.

Após a instalação do aplicativo no Splunk podemos sincronizar com o MISP através do comando ./service.sh start lhebes e o sucesso do sincronismo se dará conforme visto na Figura 21, na qual tem-se o IP interno que foi inserido no incidente de teste.

Figura 21 – IoC consumido pelo Splunk a partir do MISP SOC através do MISP-broker.

A partir daqui o céu é o limite 🙂

Prova de Conceito

O cenário para a prova de conceito consiste em detectar uma conexão bem sucedida na porta 22 do Splunk a partir de uma regra que recebe um IP malicioso alimentado pela instância do MISP Intelligence, enviado para o MISP SOC e sincronizado com o Splunk através do MISP-broker.

De maneira simplificada: o serviço SSH do Splunk está configurado com o LogLevel do tipo VERBOSE. No Splunk uma regra do tipo File Monitor foi criada com intuito de monitorar o arquivo /var/log/auth.log para alarmar quando houver um login bem sucedido (Accepted password) a partir do IP de origem da máquina hospedeira.

Deste modo, com tudo bem configurado, ao obtermos êxito no login por SSH o alerta é exibido conforme visto na Figura 22, ou seja: a regra foi enriquecida com IP sincronizado pelo MISP-broker oriundo do MISP SOC.

Figura 22 – Evento alertado no Splunk após o login bem sucedido do IP da máquina hospedeira.

Conforme visto, na primeira publicação, quando o IoC chega na instância SOC, a partir da Intelligence, o MISP-broker já envia para o Splunk. Todavia, o MISP-broker também oferece o recurso para a devida dinâmica da gestão dos IoCs e será demonstrado a partir da sinalização de que o IoC é válido ou é um falso positivo, conforme visto na Figura 23.

Figura 23 – A partir da Instância SOC é possível validar o IoC ou marcá-lo como falso positivo.

Caso queiramos que o Splunk não utilize mais um determinado IoC, deve-se marcá-lo como falso positivo no MISP SOC pelo menu superior, Event Actions e List Attributes ao clicar na mão com o polegar para baixo. Dessa forma, verifica-se o incremento do contador com o número vermelho e espera-se alguns segundos para que o IoC seja excluído do KV Store, conforme visto na Figura 24.

Figura 24 – IoC marcado como falso positivo em SOC e excluído da KV do Splunk.

Se o IoC não for um falso positivo, ou seja, se for válido e você quiser alimentá-lo novamente ao Splunk, basta validá-lo com o polegar para cima e pronto, a regra fará uso desta informação com inteligência e dinamicidade. A partir daí, pode-se fazer a devida gestão dos IoCs e tornar as regras mais aprimoradas e eficientes.

Conclusão

O último Fórum Econômico Mundial aponta que a cibersegurança é uma tarefa muito complicada para os governos ou empresas resolverem sozinhos (MEE, 2021). Desta forma, o compartilhamento de informações através de uma plataforma de compartilhamento distribuída é um possível caminho para contornar este desafio. Já existem bases públicas das quais os MISPs podem se conectar e contribuir para uma internet mais segura (WAGNER, 2016).

Este artigo demonstrou como organizar serviços MISPs para compartilhamento de inteligência através de incidentes compostos por indicadores de comprometimento e oferece uma ferramenta de integração para sincronismo entre um MISP e o Splunk através de um laboratório consumado em prova de conceito.

O compartilhamento dos IoCs visa contribuir também para ajudar os indicadores de segurança cibernética, fraude financeira ou informações de combate ao terrorismo. Através de pessoas capacitadas e processos bem definidos, a tecnologia demonstrada neste artigo pretende contribuir com a melhora na visibilidade, rapidez e inteligência ao diminuir o tempo de detecção e resposta a incidentes, redução nos falsos positivos, enriquecimento das regras de detecção e melhora na tomada de decisão.

Referências Bibliográficas

FOTIADOU, Konstantina et al. Incidents information sharing platform for distributed attack detection. IEEE Open Journal of the Communications Society, v. 1, p. 593-605, 2020.

KENNEALLY, Erin. Ransomware: a Darwinian opportunity for cyber insurance. In: Kenneally, Erin.” Ransomware: A Darwinian Opportunity for Cyber Insurance.” Connecticut Insurance Law Journal Fall Symposium Edition. 2021.

MEE, Paul; CHANDRASEKHAR, Chaitra. Cybersecurity is too big a job for governments or business to handle alone. European Union Agency for Law Enforcement Training (CEPOL): Budapest, Hungary, 2021.

WAGNER, Cynthia et al. Misp: The design and implementation of a collaborative threat intelligence sharing platform. In: Proceedings of the 2016 ACM on Workshop on Information Sharing and Collaborative Security. 2016. p. 49-56.