Algumas consultas KQL que usamos para o Log Analytics e Resource Graph são simples mas nos fornecem todos os dados que precisamos para uma decisão ou servir de base para hunting.
Alem de algumas consultas "curiosas" que já precisei montar, tambem tenho as que uso em treinamento do Microsoft Defender for Cloud como exemplo de diferentes tipos de consultas.
Decidi juntar todas elas em um repositório no GitHub para ficar fácil a consulta e deixar disponivel para a comunidade.
msincic/scripts-KQL: Public KQL Scripts (github.com)
| Nome do Script |
Tipo |
Proposito |
| Agents_Last_Comm |
Log Analytics |
List type of agent (MMA or AMA) and last communication of all computers monitored |
| Array-Text-Extract |
Log Analytics |
Examples of extract data in arrays or text columns |
| Attack-Examples |
Log Analytics |
Example of detect attacks in logs (SQL Injection) |
| Emails-Threat-Intel |
Log Analytics |
Detect malicious IPs and domains in email, URL or sender |
| Events_Chart_ByDay |
Log Analytics |
Example of chat to detect anomolous events registered |
| Graph_examples |
Log Analytics |
Examples of graph (bar, time, pie) |
| List_CWPP |
Resource Graph |
List workload protections in all subscriptions to map a coverage protection in your environment |
| List-Deployments-and-Details |
Log Analytics |
List all deploymentos to audit object creations and details about dependant objects in the same deploy |
| M365_Operations |
Log Analytics |
List operations in M365 and IP/DLP actions |
| More-Changed-Computers |
Log Analytics |
List top 10 computers and users with changed configs |
| PIM_Included |
Log Analytics |
List activities of include users in PIM |
| PoliciesAssigned-State |
Resource Graph |
List policies applied and compliance states. You can filter for compliance or non-compliance to addresses actions |
| Policies-List |
Resource Graph |
List policies and details to export and use for determine assigments in your enviromnent |
| Purview-IP-Events |
Log Analytics |
List all activities in Purview (IP, DLP, IRM, etc) |
| Tables-Ingest-Day-by-Day |
Log Analytics |
List ingest data in all tables by day with indicator of billied or non-billed |
| ThreatIntel-Examples |
Log Analytics |
Samples to use Microsoft Defender Threat Intel table to detect malicious IP in sign-ins and consult tables |
| Usage_Tables |
Log Analytics |
Graph to identify and understand tables growing |
| VM_Process_Comm |
Log Analytics |
List of process communicated in all computers with IP and Port, source, destination, bytes send and received |
| VMs+Scale Set User Identity |
Resource Graph |
List VMs and Scale Sets using User Identity to mapped permissions |
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.
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 |