MVP: System Center Cloud and Datacenter Management, MCT, MCSE, MCITP, MCPD, MCDBA
MVP Logo

Últimos posts

Categorias

Tags

Manutenção de Incidentes no Microsoft Sentinel

Um recurso que testamos no Private Preview e agora está em GA é a manutenção de incidentes, que envolve a deleção e criação.

Create and delete incidents in Microsoft Sentinel - Microsoft Tech Community

Deleção de Incidentes

Pode parecer em um primeiro momento que deletar um incidente no ambiente de SOC seja uma tarefa fora do padrão, pois poderia ser usado para esconder ou melhorar uma estatística (KPI) do time de atendimento.

Apesar de aparente contradição, esse recurso é importante pois nem sempre um incidente é encerrado ou tratado. Um exemplo comum é o Adaptative application que responde repetidamente a aplicações como o próprio Azure Arc ou Automation.

Em casos em que o incidente não foi efetivo e nem um falso positivo por não ter a ver com uma brecha de segurança efetiva, a deleção pode ser um recurso útil ao invés de você passar a ignorar o alerta. Afinal, um dia uma aplicação realmente suspeita irá rodar no servidor e por ter ignorado a regra de aplicações suspeitas você não irá saber.

image

Como pode ser visto acima, o recurso está bem visivel e acessível.

Observação: Incidentes gerados por integração com Microsoft 365 Defender não podem ser deletados, já que foram linkados.

Importante: Na tabela SecurityIncident estará registrado o incidente e quem o deletou. Não existe uma lixeira para recuperar o incidente, mas os alertas e o próprio incidente continuam registrados nas tabelas de log e você poderá eventualmente auditar os incidentes deletados para evitar manipulações indevidas.

Captura de tela 2022-09-13 095509

Criação Manual de Incidentes

Esse recurso era esperado a um tempo e nem precisa de muita explicação, afinal usávamos alertas customizados para criar incidentes customizados. Isso dava trabalho, já que era necessário identificar uma situação que pudesse gerar um incidente mas que não fosse mapeada. Por exemplo um evento especifico que geravamos manual e mapeavamos um alerta em KQL para criar um incidente de um caso especifico.

Mas isso nem sempre funcionava, por exemplo digamos que um usuário recebeu um phishing em seu email pessoal e abriu no computador da empresa e consequentemente não foi detectado pelo MDE. Neste caso registramos o incidente manualmente para constar nas atividades de SOC.

Outro caso muito comum são as atividades de chamados de programas que não puderam ser instalados, atividades que foram barradas e foi necessário criar algum tipo de mitigação, etc. Nestes casos hoje o SOC não tinha como registrar estes incidentes, normalmente oriundos do sistema de chamados.

O processo é bem simples, você irá utilizar o botão de criação de incidentes e informar todos os campos necessários e depois trabalhar com ele como faz com os outros incidentes.

image

Agora seu dashboard de atendimento no SOC terá uma visão muito melhor, sem a necessidade de agregar mais de uma ferramenta.

Detectando Atividades Suspeitas com o IRM - Inside Risk Management

Detectar atividades suspeitas trabalha com o comportamento dos usuários.
Esse comportamento não se limita ao DLP, mas abrange:
  • Regras de Proteção de Dados do MPIP (antigo Microsoft Information Protection)
  • Regras do MDE (Microsoft Defender Endpoint)
  • Regras do MDfC (Microsot Defender for Cloud Apps, antigo CASB)
  • Log de atividades do Office 365 e do Windows
Uma vez que eu capturo estes dados posso criar uma linha de tempo (baseline) para detectar:
  1. Comportamentos inesperados de uma pessoa em relação a sua própria atividade nos ultimos 30 a 90 dias
  2. Comportamento inesperado de uma entidade comparada ao baseline da empresa como um todo
Para isso são criados gatilhos que podem ser atividades como uma regra DLP, copia de arquivos em um pendrive, exfiltração via web, etc.
Apresentei todos estes recursos no webcast com a Thais Mafra. Assista e entenda melhor este recurso!

Entregando Alertas do Sentinel no Teams

Uma funcionalidade simples e muito funcional do Sentinel na integração com playbooks é a entrega como uma mensagem de chat no Teams.

O exemplo abaixo demonstra como os alertas são entregues ao Teams com os detalhes do alerta que foi disparado.

image

Criando o Logic Apps e Regra de Automação

Quando são instalados os conectores do Sentinel automaticamente é criado um Logic Apps para automação, sem ter tasks configurados exceto a primeira que é o gatilho de incidente.

Esse será o playbook que a todos os alertas habilitados é configurado como forma de resposta padrão.

image

Ao editar o playbook entre no objeto For each que é o loop para possibilitar que vários incidentes sejam disparados e não só o primeiro. Isso pode acontecer em ambientes onde uma situação criou mais de um incidentes e a falta deste loop não dispararia para todos os que ocorressem.

Note que o loop do For each lê os dados do incidente e os envia para o email com as propriedades abaixo para titulo, destinatario e texto enviado.

No caso abaixo deletei o objeto padrão que era email e troquei pelo objeto Post message in a chat or channel que permite enviar a mensagem tanto para um usuário unico como para um grupo ou canal do Teams:

image

O passo seguinte é criar no Sentinel a regra de disparo para o playbook de notificação.

Veja que o nome é parecido por minha opção mas poderá usar qualquer outro nome, que poderá facilitar no momento de relacionar os alertas com a chamada de automação.

image

Habilitando as Regras Analíticas para Envio no Teams

Entre nas opções de Analytics do Sentinel, habilite as regras que deseja ser alertado e as edite.

image

Nas opções da regra poderá editar a resposta automática de automação que criamos no passo anterior para que o playbook seja executado.

image

Ao editar as regras pode-se criar novas respostas de automação sem ter que criar antes em Automation como fiz anteriormente, apesar de achar que isso pode gerar multiplos objetos orfãos posteriormente.

Mas se desejar criar uma nova resposta, poderá clicar no botão Add new e nomear a automação e indicar qual dos playbooks será executado:

image

Pronto, agora você irá receber os detalhes de incidentes diretamente pelo canal ou chat do Teams!

Segurança para IoT Alem do Chão de Fábrica

Sempre abordamos com clientes a importancia de monitoração em ambientes fabris. Para isso faço sempre demonstrações do Microsoft Defender for IoT e mostramos a quantidade de dispositivos desconhecidos em um ambiente e como se comunicam muitas vezes diretamente com internet.

Mas não é apenas o chão de fábrica e sistemas de automação que podem ser um problema de vazamento em nossos ambientes. Então nos perguntamos:

Será que estou realmente seguro mesmo não sendo manufatura e automação industrial?

A resposta é NÃO!!!

Por exemplo, recentemente uma vulnerabilidade no Mikrotik e no passado com Cisco e outros produtos mostram que podemos ter equipamentos inteligentes ligados a rede invadidos e usados para vazamento de dados ou ataques cibernéticos.

Alexa e Google Home são comuns até em ambiente doméstico, mas nas empresas temos centrais telefonicas, equipamentos sofisticados de video conferencia, abertura de portas, luzes inteligentes, ar condicionado com wifi e sensores de energia. Isso citando apenas os que muitos tem em suas casas!

Alem disso, muitos destes equipamentos são de empresas que não temos certeza da segurança, por exemplo Sonoff utiliza o eWelink, Geonav o HI, LG o ThinQ e cada fabricante tem uma plataforma diferente que se integram com o Home e Alexa sem qualquer tipo de segurança sofisticada. Bastaria que eu invadisse um destes para fazer um reconhecimento e inventário remoto.

Como me Proteger?

Adote soluções que fazem o rastreio destes equipamentos. Estas soluções fazem a leitura de protocolos comuns a equipamentos inteligentes já que estes usam broadcast para serem configurados como é o caso da Alexa e do Google Home e dispositivos wifi.

No caso do Microsoft Defender for Endpoint ele detecta alterações em BIOS, tendo um catalogo da maioria dos fabricantes de automação industrial (ABB, Siemmens e outros) permitindo estar atualizado sempre que surgirem alterações importantes.

O print abaixo é um dashboard de um scan em minha casa, onde tenho ar condicionado, Google Home, lampadas inteligentes e sensores de energia:

image

image

image

image

O Microsoft Defender for IoT permite que você simule situações entre diferentes dispositivos para analisar se entre eles ocorrem comunicações diretas ou indiretas, que são demonstrados no print anterior como pontos vermelhos. Abaixo um exemplo desta analise:

image

Outra analise que tambem é realizada por estas soluções é a descoberta e alerta para novos dispositivos colocados na rede. Por exemplo se um funcionário aparecer com um wifi e conectar na rede ele irá detectar instantaneamente!

Alem disso, tambem é importante saber os protocolos e portas que os dispositivos utilizam e o consumo de banda de internet deles:

image

Por fim, podemos gerar reports executivos para analise com detalhamento e um score de segurança para o que foi inventariado:

image

Integração com Sentinel

O Microsoft Sentinel já possui um conector para o Defender for IoT, mas você tambem pode integrar sistemas autonomos como SCADA diretamente, alem de permitir que exporte os logs para um SIEM externo.

Stream Microsoft Defender for IoT alerts to a 3rd party SIEM

CONCLUSÃO

Mesmo ambientes domésticos já possuem muitas automações e em geral são softwares e fornecedores que não temos total confiança.

O comportamento destes equipamentos podem ser prejudiciais e passarem desapercebido de toda a equipe de segurança, então não deixe de lado por não ter um ambiente fabril!

Microsoft Sentinel–Automações não são executadas

Um erro muito comum quando vejo as implementações de Sentinel em clientes é não executar as automações.

Para entender o problema, é interessante interligar com aplicações Power Platform como o Power Apps, onde o usuário precisa autorizar a conta do Office 365 para que o app execute. Isso é feito na primeira execução e o Power Apps ou Power Automate irá guardar o usuário da conexão.

O mesmo acontece com as automações do Sentinel, elas não estão necessariamente interligadas a uma Automation Account e com isso é necessário autenticar todas as conexões!

Como saber se tenho automações não autenticadas?

Abra o Sentinel e clique em Automações.

Ao abrir clique na opção que irá aparecer no topo da lista do lado direito “API Connections”.

Faça um filtro pelas automações que estão com erros.

PPV 
; : - 0 -535F 
麟 一 do $ n , • 一 dwpa " 一 凵 
SUO!PBUUO) IdV

Para as automações que estão com erro na conexão, abra suas propriedades e vá para a opção “Edit API Connection” e voilá achou o problema 😊