Desbloqueando a visibilidade do M365: por que os conectores SIEM padrão deixam você às cegas

By Mirko Peters · 2026-08-11

Bem-vindo de volta ao blog! Se você gerencia as operações de segurança de uma organização que usa o Microsoft 365, provavelmente sente uma falsa sensação de segurança. Você clicou em "en…

Automatically translated with AI from the original post. Read the English original

Bem-vindo de volta ao blog! Se você gerencia as operações de segurança de uma organização que usa o Microsoft 365, provavelmente sente uma falsa sensação de segurança. Você clicou em "Habilitar" no conector padrão do M365 do seu SIEM, verificou que os logs estavam fluindo e marcou a caixa de conformidade. Mas você está realmente protegido? A verdade incômoda é que os conectores de SIEM prontos para uso costumam deixar enormes pontos cegos, deixando de fora justamente as cargas de trabalho avançadas na nuvem, onde os invasores modernos gostam de atuar. Para explorar esse tema crítico por completo, não deixe de ouvir nosso podcast complementar, Send Critical Microsoft 365 Logs to Your SIEM, em que detalhamos essas lacunas.

Neste post, vamos mergulhar a fundo em por que suas configurações padrão estão falhando, onde se escondem os pontos cegos e como você pode criar um pipeline de ingestão resiliente e com bom custo-benefício, que gere detecções de alto sinal que seus analistas realmente consigam usar.

Os pontos cegos do Microsoft 365 nos principais SIEMs

Seja qual for o SIEM que você usa, Microsoft Sentinel, Splunk ou QRadar, os modelos de ingestão padrão normalmente se concentram nos logins básicos do Azure Active Directory e nos logs rudimentares de atividade do Office 365. Embora isso cubra o mínimo essencial, deixa cargas de trabalho críticas totalmente expostas. Nas principais plataformas SIEM, alguns grandes pontos cegos aparecem de forma consistente:

• Exchange: Os conectores padrão costumam não capturar acessos a caixas de correio por quem não é o proprietário, a criação de regras suspeitas e de encaminhamentos, atividades de SendAs ou SendOnBehalf e alterações repentinas nas permissões da caixa de correio.
• SharePoint e OneDrive: Você pode ver downloads de arquivos, mas enxerga a criação e o uso de links externos e anônimos, o recompartilhamento de arquivos ou as alterações de permissões privilegiadas em sites?
• Teams: Atacantes adoram colaborar à vista de todos. As configurações padrão raramente capturam o compartilhamento externo por canais baseados no SharePoint, exclusões e edições de mensagens, alterações em políticas de reunião ou o sideloading não autorizado de aplicativos.
• Power Platform: A popularização dos ambientes low-code/no-code traz riscos ocultos. Picos na criação de fluxos e aplicativos, uso arriscado de conectores (como Outlook, Teams ou conectores HTTP genéricos) e tentativas de contornar políticas de prevenção contra perda de dados (DLP) costumam ficar de fora.
• Confidencialidade e DLP: A aplicação e a remoção de rótulos, as ocorrências de políticas e as substituições manuais muitas vezes estão totalmente ausentes, a menos que sejam explicitamente configuradas.
• Contexto do Azure AD: O contexto essencial sobre logins de risco, resultados de acesso condicional e anomalias de dispositivo ou geográficas costuma ficar de fora das consultas padrão.

Causas raiz: por que você está perdendo eventos críticos

Por que esses fluxos de telemetria essenciais estão faltando? Raramente é por acaso; trata-se, na verdade, do resultado de escolhas arquiteturais e comerciais feitas tanto pelos provedores de plataforma quanto pelos compradores corporativos.

Em primeiro lugar, as restrições de licenciamento têm um papel enorme. Auditoria avançada, telemetria detalhada do Exchange e registro rico de eventos do SharePoint frequentemente ficam restritos a licenças de nível superior, como o Microsoft 365 E5, ou a complementos de Auditoria Avançada. Se o seu locatário está no nível E3, esses eventos simplesmente não são gerados nem retidos.

Em segundo lugar, os limites de escopo dos conectores restringem a coleta de dados. Conectores padrão normalmente puxam apenas os fluxos básicos de "OfficeActivity" e ignoram as cargas de trabalho avançadas. Em terceiro lugar, a limitação de throughput da API e os atrasos de lote podem sobrecarregar os coletores nativos nos horários de pico, causando perda de logs. Em quarto lugar, lacunas no parser significam que, mesmo que os blobs JSON brutos cheguem ao seu SIEM, campos não mapeados e mudanças silenciosas de schema fazem com que pareçam sem sentido. Por fim, controles de custo implementados por equipes atentas ao orçamento excluem discretamente categorias barulhentas sem que se compreendam as implicações para a segurança.

Equilibrando o controle de custos sem ficar às cegas

Uma das maiores objeções à ingestão de visibilidade "completa" do Microsoft 365 é o custo. Ingerir cada log gerado por um locatário grande do M365 pode esgotar o orçamento de armazenamento da sua segurança. No entanto, você não precisa escolher entre ir à falência e ficar às cegas. Você precisa filtrar com inteligência, não filtrar menos.

Comece filtrando na origem. Configure seus mecanismos de ingestão para incluir apenas operações de alto sinal, como New-InboxRule, Add-MailboxPermission, ou eventos de criação e uso de links anônimos. Deduplique e agregue eventos barulhentos e de baixo valor, como salvamentos em segundo plano de versões no SharePoint, antes que cheguem ao seu SIEM.

Implemente estratégias de armazenamento em camadas. Mantenha o armazenamento quente por um período curto (30 a 60 dias) para investigações ativas, e direcione o armazenamento frio ou de arquivo para armazenamentos de objetos mais baratos, para atender aos prazos de conformidade. Além disso, modele o volume antes de habilitar novos fluxos. Faça uma previsão de gigabytes por dia por origem e dobre essas estimativas para considerar picos de negócios, auditorias trimestrais ou períodos de descoberta jurídica.

Projetando um pipeline de ingestão resiliente

Depender de conectores de consulta direta, frágeis, é receita certa para perder alertas durante incidentes de segurança de alta pressão. Em vez disso, projete um pipeline resiliente e preparado para limitação de taxa. Um padrão robusto tem esta aparência:

• Origem: Colete dados do Log de Auditoria Unificado do M365, da Auditoria Avançada, dos logs de entrada e de risco do Azure AD, do Microsoft Information Protection (MIP), dos alertas de DLP e dos alertas de segurança do Microsoft Defender.
• Transporte: Encaminhe os dados da API do Graph ou da API de Gerenciamento para o Azure Event Hub (que atua como buffer e mecanismo de reprocessamento) antes de repassá-los ao seu SIEM.
• Processamento: Normalize e enriqueça os dados já na zona de aterrissagem, adicionando contexto do usuário, indicadores de departamento, designações de VIP, estados dos dispositivos e dados geográficos.
• Governança: Implemente verificações diárias de completude, tratadores de recuo para limites de taxa (erros 429), monitoramento de mudanças de esquema e alertas para filas de mensagens mortas (dead-letter).

Normalização e enriquecimento para dados prontos para analistas

Logs brutos do M365 são notoriamente confusos, cheios de objetos JSON aninhados e convenções de nomenclatura de campos inconsistentes entre as cargas de trabalho. Se você entregar dados brutos a um analista de Nível 1, ele passará metade do turno decodificando payloads em vez de triar ameaças.

Achate os campos principais no momento da ingestão: Actor, Target, Action, ResourcePath, LinkType (anônimo, da organização ou pessoas específicas), ExternalRecipient e LabelName. Mapeie esses campos para um esquema unificado, como o Azure Monitor Common Security Incident Model (ASIM) ou o Elastic Common Schema (ECS), para que sua engenharia de detecção abranja as cargas de trabalho de forma contínua. Por fim, enriqueça esses eventos com dados de RH (função, tipo de contrato, departamento), listas de VIPs, listas de permissões de parceiros, estados de conformidade dos dispositivos e classificações de sensibilidade.

Detecções de alto sinal para implantar agora

Quando seu pipeline estiver fluindo e seus dados estiverem normalizados, você pode implantar detecções de alto sinal que realmente capturam comportamentos sofisticados de atacantes. Aqui estão oito detecções fundamentais que você deve configurar imediatamente:

• Exfiltração via caixa de correio: Detecte uma nova regra de caixa de entrada que encaminha para fora da organização ou move mensagens para RSS/Lixo Eletrônico, ocorrendo em até uma hora após um login a partir de uma nova localização geográfica ou de um dispositivo não reconhecido.
• Acesso furtivo: Sinalize o acesso à caixa de correio de uma conta VIP por alguém que não é o proprietário, quando houver um evento Add-MailboxPermission nas 24 horas anteriores.
• Vazamento no SharePoint: Emita alerta para links de compartilhamento anônimos ou de "pessoas específicas" criados em arquivos rotulados como Confidencial ou Restrito.
• Abuso de links: Detecte um alto volume de downloads externos em uma janela de 15 minutos originados de um link de compartilhamento recém-criado, a partir de um novo IP ou ASN.
• Pivô pelo Teams: Identifique cenários em que um arquivo é compartilhado externamente e o mesmo usuário adiciona um convidado externo à equipe em até duas horas.
• Abuso do Power Automate: Sinalize um aumento repentino de três ou mais criações de fluxos por dia feitas por uma conta que não é de desenvolvedor, especificamente usando os conectores HTTP ou Outlook.
• Acúmulo gradual de privilégios: Monitore adições e remoções repetidas de funções de membro ou administrador no mesmo workspace ou site sensível dentro de uma janela de 24 horas.
• Dados desatualizados: Detecte quando os datasets de conteúdo de executivos ou finanças deixam de ser atualizados por dois ou mais ciclos, protegendo a liderança de tomar decisões com base em dados desatualizados.

Seu plano de implementação de 30 dias para fechar lacunas

Corrigir a sua postura de visibilidade no M365 não precisa levar um ano. Você pode fechar sistematicamente suas lacunas de visibilidade em apenas 30 dias:

• Semana 1: Ative a Auditoria Avançada onde for necessário, faça um inventário dos seus conectores de SIEM atuais e mapeie as categorias de eventos que estão faltando.
• Semana 2: Coloque em funcionamento o seu pipeline do Event Hub. Direcione a telemetria do Unified Audit Log, do Advanced Audit, do Azure AD e do Defender, e implemente seus filtros na origem.
• Semana 3: Normalize e enriqueça os seus fluxos de dados, reprocesse os logs críticos dos últimos 30 dias e implemente as sete detecções de alto sinal listadas acima, com janelas de supressão adequadas.
• Semana 4: Otimize os custos eliminando o ruído restante e ajustando os níveis de retenção. Adicione monitores de completude e execute um exercício de mesa purple team que teste regras de caixa de correio, compartilhamento externo e picos de fluxos.

KPIs executivos para comprovar o resultado

Quando a liderança perguntar se o orçamento de segurança investido em melhorias do pipeline valeu a pena, você precisa de métricas para comprovar o sucesso. Acompanhe estes KPIs executivos:

• Cobertura: Percentual de famílias de eventos do M365 previstas que foram ingeridas e analisadas com sucesso (meta de 95% ou mais).
• Velocidade: Tempo médio para reconhecimento (MTTA) e tempo médio para resolução (MTTR) de incidentes relacionados ao M365 (com tendência de queda).
• Ruído: Relação entre alertas e verdadeiros positivos (com tendência de alta na qualidade do sinal).
• Custo: Custo por gigabyte ingerido (com tendência de queda de cerca de 40% graças à filtragem na origem).
• Confiabilidade: Número de dias com lacunas de ingestão (meta: zero) e SLAs para mudanças de esquema (atualizações de parsers em até sete dias após uma alteração de esquema da Microsoft).

Armadilhas comuns e como corrigi-las

Até os melhores planos podem encontrar obstáculos. Fique atento a estas armadilhas comuns:

As equipes costumam dizer: "Ativamos isso", mas os logs nunca chegam de fato, porque as licenças do Advanced Audit ou as linhas de base de auditoria de caixas de correio nunca foram devidamente verificadas. Outro problema comum é que as regras do SIEM permanecem totalmente silenciosas durante os ataques, porque avaliam os eventos isoladamente, em vez de correlacionar a criação de regras, mudanças geográficas e o compartilhamento externo.

Explosões na fatura acontecem quando os pré-filtros são ignorados. Sempre pré-filtre as operações mais ruidosas e exclua os eventos de sincronização em segundo plano. A degradação dos parsers é outro problema silencioso; estabeleça uma rotina mensal de comparação de esquemas e execute testes unitários com payloads de amostra. Por fim, a fadiga dos analistas surge rapidamente quando os alertas não têm contexto. Garanta sempre que seus alertas incluam quem, o quê, onde e os rótulos de confidencialidade, além de links diretos para o Microsoft Compliance Center para análises aprofundadas.

Conclusão: pare de depender da conformidade para se proteger

A conclusão é simples: os conectores padrão do SIEM mantêm você em conformidade, mas não o mantêm protegido. Ao coletar os logs certos do Microsoft 365, normalizá-los em um esquema unificado, enriquecê-los com o contexto de negócio essencial e fazer buscas com detecções ajustadas ao comportamento real dos atacantes, você pode eliminar por completo os seus pontos cegos. É assim que o seu SIEM deixa de perder a história e passa a escrevê-la. Para se aprofundar ainda mais nessa estratégia, ouça o episódio completo em Send Critical Microsoft 365 Logs to Your SIEM e comece hoje mesmo a fechar as suas lacunas de visibilidade!