Enriquecendo o Sentinel com dados do Virus Total

Apresentando o Virus Total

O site Virus Total é um serviço muito conhecido do time de cibersegurança por permitir acompanhar diversos IoCs (Indicators of Compromissed) como hash de arquivo, IP, dominio ou URL baseado em uma pesquisa simples.
O Virus Total tem uma modalidade de assinatura onde é gratuita e possui limites para consultas, a fim de evitar o uso por bots ou sistemas de terceiros.
Veja abaixo os detalhes e note que temos aqui nossa API Key mesmo sendo uma conta gratuita:

Solution no Sentinel

Já que temos a possibilidade de integrar os dados do Virus Total com os alertas e incidentes do Sentinel, a primeira ação é instalarmos a Solution:

Ao instalar a solução verá na tela de informações a esquerda que inclui 9 playbooks que irão colher os dados do incidente, alerta, domínio ou arquivo para buscar e correlacionar os dados do Sentinel com o Virus Total.
O passo seguinte é clicar em Automation --> Playbook templates e instalar os playbooks, para isso poderá filtrar pela palavra "virus total" e usar o botão Create Template para abrir a janela de instalação do playbook em seu ambiente:


Nesta tela verá que não é necessário ainda conectar seu API Key nem o Log Analytics, isso será feito após o deploy quando ele abrir a tela de design do Logic Apps:


Note que ao abrir as tarefas e sequencia do Logic Apps verá que a conexão do Virus Total e do LogAnalytics estarão com o simbolo de aviso e o botão salvar não irá funcionar até que arrume as conexões.
Para isso a primeira vez será necessáiro clicar em API Connections e informar os dados tanto do Virus Total quanto do Log Analaytics que será utilizado. Abaixo o exemplo de conexão com a Virus Total:


Nos próximos conectores você não precisará mais configurar as conexões, pois ele irá permitir utilizar a conexão já configurada nos playbooks anteriores, como a imagem abaixo:


Lembre-se que precisará conectar tanto a API do Virus Total quanto do Log Analytics (workspace ID e Key).
Uma vez configurado, agora você depois de abrir todas as tarefas e indicar as conexões poderá salvar o Logic Apps e verá que ele irá aparecer na tab Active playbooks:

Criando a Automação

Agora que já importamos a solução e criamos os playbooks que desejamos usar, o passo seguinte é criar a regra para executá-lo, chamada de Automation Rule.
Para isso clique no botão Create --> Automation Rule e indique o nome da regra e o disparador (trigger) que pode ser um incidente novo, alterado ou um novo alerta.
Ao escolher o tipo de disparador utilize como ação Run Playbook para escolher um dos que criamos no passo anterior:


Ao criar a regra há varias formas de filtros que você poderá utilizar, por exemplo para detectar que há um arquivo que será analisado já que um dos playbooks é especifico para hash. Tambem poderá filtrar apenas para certos tipos de incidentes ou alertas.

Conclusão

Integrar diferentes serviços para ter IoCs de diversas fontes irá ajudar muito em suas análises de incidentes.
Tambem estão sendo testados nesse momento em private preview widgets para trazer dados do Anomali, Record Future e do Virus Total quando você estiver investigando uma entidade (Entity) mas esse é outro post futuro 

Sentinel Recon Workbook


Sabemos que o Microsoft Sentinel é uma ferramenta para capturar, analisar e gerar insights de segurança para operações e SOC.
Uma vez que temos milhares de sinais e eventos dentro do Sentinel, podemos analisar diversas situações com seu uso.
Vamos abordar aqui um Workbook que está na galeria da comunidade que tem o nome Sentinel Recon que tem como função permitir a pesquisa de forma inteligente aos dados coletados.

Instalando o Workbook

O primeiro passo é procurar e salvar no seu ambiente o template. Procure com o nome "Recon" em Templates como abaixo:

Utilizando o Workbook

Uma vez aberto, use-o na aba "My workbooks". Configure a assinatura de Azure onde está o seu Log Analytics que suporta o Sentinel, e inclua o periodo de pesquisa desejado. 
Obviamente, quanto maior o periodo mais lento ele ficará para retornar os dados e dependendo do tamanho do ambiente poderá ocorrer erro de timeout.
No exemplo abaixo usei o Recon para validar os agentes que tenho instalado, tanto nativos como Arc, onde ele me dá uma visão da ingestão de dados e permitindo nas tabelas de detalhes filtrar o que desejo analisar:

Outra pesquisa que me retornou dados interessantes é utilizando os recursos "Azure Activity" e "Security Events" onde assim como exemplo anterior passo a ter uma visão do fluxo de eventos ingeridos pelo Sentinel e utilizei alguns filtros para saber a origem especifica de determinados eventos e atividades:


Conclusão

Use este workbook junto com o Sentinel para vasculhar e descobrir detalhes do que está sendo analisado e ingerido de forma fácil e inteligente.

Azure Monitor SCOM Managed Instance–System Center Operations Manager no Azure

Em abril deste ano com o lançamento da suite System Center 2022 escrevi se os produtos ainda eram importantes e seus correspondentes em serviços e soluções no Azure Marcelo de Moraes Sincic | Lançamento do System Center 2022–Ainda Vale a Pena? Será descontinuado? (marcelosincic.com.br)

Um destes produtos era o System Center Operations Manager (SCOM) que sempre foi uma ferramenta muito importante na monitoração de ambientes on-premisse.

Como já abordado em abril, o uso de Azure Arc e Azure Monitor pode ser utilizado para ambientes on-premisse mas dependem de internet, geração de alertas correspondentes escritos em KQL e consumindo créditos com a ingestão maciça de eventos do log.

Por exemplo, uma regra construida no SCOM onde relacionamos o log de um servidor com outro usando um Event ID sequencial para indicar uma cadeia de quebra ou então um mapa com objetos relacionados é muito mais complicado de ser construido no Azure Monitor exigindo conhecimento de Notebooks Jupyter e KQL.

O que é o Azure Monitor SCOM Managed Instance

Na prática a Microsoft não está lançando um produto novo ou feature nova mas sim transformando um PaaS um produto que ainda é muito importante para diversas corporações.

O diagrama abaixo disponivel em About Azure Monitor SCOM Managed Instance (preview) | Microsoft Learn deixa bem claro que a funcionalidade se inverte onde o SCOM agora é que está em cloud monitorando o ambiente on-premisse.

Screenshot showing architecture.

Fatores a serem considerados

Com esse novo recurso temos que questionar se irá ou não valer a pena migrar para o ambiente gerenciado e podemos usar estes fatores inicialmente:

Vantagens Desvantagens
  • Não ter que gerenciar os recursos agregados, que normalmente eram o mais “problemático” como o Reporting Services e SQL
  • Utilizar os mesmos Management Packs que o on-premisse
  • Facilidade na implementação e escalabilidade já que todo o processo criativo dos recursos é realizado pelo Azure
  • Licenciamento é o mesmo, aproveitando o investimento nas licenças CIS ou System Center Suite
  • Utilizar o SCOM monitorar as VMs locais no Azure e outras clouds, aproveitando o conhecimento já adquirido no om-premisse, sem a necessidade de enviar dados das Azure VM para o ambiente on-premisse
  • Integração simples com Power BI
  • Custo de ingestão de logs no Azure Monitor utilizando o Arc é maior que o custo de upload dos logs via VPN
  • Custo de infraestrutura no Azure para VMs, Load Balancing e tráfego de dados
  • Situação de link internet invertida, agora não é mais o SCOM que enviaria os dados para o Azure Monitor e sim os servidores on-premisse que enviarão dados para o SCOM, gerando alertas em cascata quando houver queda de link
  • Discovery para instalação automática não é suportado (1)
  • Não é possível ter Management Servers no ambiente on-premisse (2)

(1) Até o momento não disponivel no Preview

(2) Até o momento não é suportado, mas permite o uso de Gateway Server