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.
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.
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.
Agora seu dashboard de atendimento no SOC terá uma visão muito melhor, sem a necessidade de agregar mais de uma ferramenta.
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.
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.
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:
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.
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.
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.
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:
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:
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:
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:
Por fim, podemos gerar reports executivos para analise com detalhamento e um score de segurança para o que foi inventariado:
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!
Utilizando o Azure Application Insigths na Analise de Vulnerabilidades
Uma das ferramentas que são criadas costumeiramente nas aplicações Web hospedadas, o Azure Application Insigths, é subutilizado pelos time de desenvolvimento, operações e segurança.
O que é possivel com o App Insights?
O App Inisgths captura log e executa tarefas para avaliar performance, estabilidade e estatísticas de uso de um web app.
Quando comparado a outras ferramentas comuns com o Google Analytics é importante lembrar que o App Insigths tambem funciona como um APM (App Performance Monitoring) detalhando funções e linhas de código como chamadas a banco de dados, que estão gerando lentidão.
Particularmente gostou muito de algumas funções Smart detection settings que são regras comuns para detecção de tendências ou problema, além de métricas e as Live Metrics como abaixo. Alias, veja que a página de contato já demonstra um ataque simulado na chamada da página de contato:
Outra função interessante que utilizo com frequencia em projetos é Avaliabiliy onde podemos criar regras de teste com páginas especificas em diversas localidades do Azure para funcionar como o antigo Global Monitoring Service.
O foco neste post não é detalhar as funções de APM, mas sim o uso pelo time de segurança.
Como o App Insights é útil para Segurança?
Primeiro temos o Application Map de onde iniciamos as analises. Basicamente ele é um modelo simples de dependencias e comunicação de dentro e de fora, incluindo as analises de disponibilidade que mostramos anterioremente.
Mas ao retirar o WAF para gerar os logs e demonstrar nesse post, o resultado foi muito rápido como pode ser visto no diagrama abaixo.
Veja que os dois endereços na parte inferior são fontes desconhecidas e poderiam ser ataques, enquanto também se vê claramente os rastreadores e robôs do Google e outro site, mas estes não seriam o problema.
Ao pedir acima os detalhes de pacotes e comunicação trocada com o meu blog com este endereço é possivel ver o que eles tentaram e quantas vezes.
O passo seguinte é clicarmos em Samples ou na lista do lado direito para analisar as queries que foram recebidas.
Como pode ser visto abaixo, é possivel identificar de onde e como o acesso foi realizado por esse dominio que estava analisando os detalhes.
Mas vamos deixar rodando por mais tempo com o WAF desativado e veremos com um histórico detalhadas.
Validando ataques reais
Agora com mas tempo exposto (como gostamos de correr risco 
) o meu blog pôde ter mais dados para serem demonstrados.
Vamos abrindo em detalhes os itens no mapa onde demonstraram as estatisticas de falhas ocoridas.
Na primeira tela de detalhes vemos que só de falhas nas ultimas 24 horas eu recebi mais de 11 mil chamadas!!!
Mas a alegria se transforma em tristeza, ou melhor preocupação, essas 11290 chamadas na verdade fazem parte de um ataque orquestrado por força bruta…
Agora vamos começar a entender melhor o que estão tentando fazer no meu blog. Para isso vamos fazer uma “caminhada” pelos dados do App Insigths.
Do lado esquerdo já podemos ver que os ataques se deram por tentar enviar parametros e listas diretamente nas páginas do blog.
Abrindo mais detalhes consigo descobrir que a fonte do ataque são PCs na China usando um SDK especifico. Em alguns casos é possivel ver tambem o IP e com isso criar uma lista de bloqueio ou potenciais atacantes.
Segue um outro exemplo mais recente que teve quase a mesma origem (outra cidade chinesa), mas com detalhes de sofisticação onde foi utilizado um script e não apenas um SQL Injection:
Continuando a caminhada posso ver a sequencia que o “usuário” utilizou no meu site, vejam que a lista de tentativas foi grande, e muitas vezes na mesma página:
O ataque na tela acima é um SQL Injection muito comum de ser utilizado em sites web por atacantes. Veja detalhes em CAPEC - CAPEC-66: SQL Injection (Version 3.5) (mitre.org)
O que fazer ao detectar um ataque ao site site ou aplicação?
Em geral os Web Application Firewall seguram boa parte dos ataques que vimos acontecer no meu blog em 24 horas, tanto que eu não fazia ideia antes que poderiam chegar a quase 12 mil em apenas 24 horas.
Mas mesmo que tenha um WAF é importante que monitore constantemente o numero de falhas em páginas para identificar se é um problema de aplicação ou um ataque que está tentando encontrar as vulnerabilidades, como os exemplos acima do meu site.
Outra importante ação é ajudar os desenvolvedores e não aceitar comandos diretamente do POST e muito menos concatenar cadeias de caracteres dentro de parâmetros e comandos internos.
Utilize tambem uma biblioteca de desenvolvimento robusta, por exemplo no meu teste de exposição não tive o blog invadido pois o próprio .NET já possui filtros para evitar comandos enviados diretamente no POST ou URL.
Como um recurso mais sofisticado para ataques direcionados, veja a opção Create Work Items onde poderá criar automações, por exemplo barrar um determinado serviço ou até derrubar um servidor quando detectar uma anomalia muito grande!
Relembrando que o App Insights se integra ao Log Analytics para consultas e ao Sentinel para segurança inteligente de Threats!!!!
Conclusão
Se não conhece, não tem habilitado ou não utiliza o App Insights comece agora!
Não o limite a analises de performance e sessões, aprenda a ler também os indícios de falhas de segurança antes que uma invasão ocorra.