Azure Sentinel–MITRE Coverage

Outra feature que estava em private preview para MVPs e parceiros e agora se tornou público é o recurso de mapeamento dos alertas e huntng queries do Sentinel com a matriz de cobertura do MITRE.

Esse recurso não gera um custo já que ele é um dashboard que demonstra a matriz ao inves da lista de itens.

Como MITRE é mapeado atualmente

Hoje os alertas e hunting queries já trazem as técnicas MITRE que estão sendo abordadas como mostra a imagem abaixo:

image

Podemos observar que as táticas e técnicas já são mapeadas tanto no cabeçalho quando em cada um dos itens de pesquisa ativa do Sentinel.

Mas esses dados estão desestruturados e é necessário clicar para fazer um filtro das vulnerabilidades com o mapa de cobertura do MITRE, muito usado hoje.

Como o MITRE será mapeado agora com o Preview

Os mesmos dados da consulta acima, agora podem ser visto diretamente no mapa de cobertura MITRE:

image

Com esse mapa ficará muito mais fácil categorizar os diferentes tipos de vulnerabilidades que preciso me proteger já que ele me traz a possibilidade nos detalhes de abrir as queries que geraram os diferentes pontos de atenção!

Alem disso, tambem é possivel com a opção Simulated mapear quantos diferentes tipos de vulnerabilidades eu tenho cobertura, mesmo que não tenha resultado na query hoje.

image

Esse efeito de simulação é muito interessante pois me permite saber se o Sentinel tem o necessário para cobrir todos os pontos que me interessam e me permitirá ter uma visão gerencial incluindo as hunting queries que eu mesmo crie.

Anuncio do Public Preview: What’s Next in Microsoft Sentinel? - Microsoft Tech Community e documentação View MITRE coverage for your organization from Microsoft Sentinel | Microsoft Docs

Azure Sentinel–Log Search & Restore Preview

Um dos programas que a Microsoft disponibiliza a MVPs e parceiros é participar de previews privados para funcionalidades de Cloud Security.

Um destes recursos liberados para Public Preview recentemente foi o Log Search and Restore onde pode-se estender o tempo de log do Analytics alem de utilizar o próprio Sentinel para ler os dados destes logs armazenados.

Limitação Atual

Na versão GA o Sentinel guarda os logs por até 2 anos, sendo que pela interface visual é possivel configurar 90 dias e via PowerShell para até 755 dias.

Alem disso, ao configurar para 2 anos o log acaba gerando um custo mais alto por estar vinculado ao preço de armazenamento do Log Analytics que é por Giga.

Novos Limites e Custo

Neste Preview o log agora poderá ser guardado por 7 anos (2520 dias) alem de ter um custo menor que será divulgado no GA, porem muito menor que o atual.

Assim como no GA atual, a alteração pode ser feita via PowerShell para os 7 anos.

Mas para ajudar, vc pode usar o aplicativo disponibilizado no GitHub onde poderá escolher as tabelas e o tempo de arquivo para operação. Ou seja você pode colocar a tabela de alertas por 5 anos e a tabela de incidentes por 2 anos.

Link para o aplicativo de configuração: Azure-Sentinel/Tools/Archive-Log-Tool/ArchiveLogsTool-PowerShell at master · Azure/Azure-Sentinel · GitHub

Usando o Recurso

Vou demonstrar com prints abaixo do meu Preview como fiz o processo de Restore, Search e o resultado final.

Executando um Restore com o nome da tabela que desejo, a data inicial e final:

image

Na sequencia executei uma consulta abordando o tempo que configurei do Restore da tabela SecurityEvents com o nome do meu servidor:

image

Por fim, o resultado é uma nova Custom Table no Log Analytics com o nome indicado acima e os mais de 3 anos de eventos restaurados!!!

image

Anuncio do Preview: What's New: Search, Basic Ingestion, Archive, and Data Restoration are Now in Public Preview - Microsoft Tech Community

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:

Performance

Metricas-1

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.

image

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.

Application Map

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.

Ataque-1

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.

Ataque-2

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.

Ataque-3

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 Smile) 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!!!

Failures-1

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…

Failures-2

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.

Failures-3

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.

Failures-4

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:

Failures-4a

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:

Failures-5

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.