Quando você abre o Microsoft Sentinel no Microsoft Defender pela primeira vez, a mudança é imediata: investigações mais limpas, workflows mais conectados e analistas que navegam por incidentes com muito menos troca de contexto.
Em vez de alternar entre múltiplas filas, investigações desconexas ou alertas duplicados, os times de SOC ganham:
- Uma fila unificada de incidentes
- Uma única attack story
- Um lugar para investigar e responder
- Uma experiência conectada entre todos os sinais de segurança Microsoft
Mas as maiores melhorias acontecem nos bastidores. A migração do portal Azure para o Defender reúne correlação de incidentes, tratamento de alertas, automação e investigação de dados de forma que reduz trabalho manual, melhora a visibilidade e acelera a resposta.
TL;DR: A migração do Microsoft Sentinel para o Microsoft Defender substitui o motor de correlação Fusion pelo mecanismo nativo do Defender, unifica a fila de incidentes e simplifica o schema de alertas (AlertInfo/AlertEvidence). A arquitetura de dados subjacente (Log Analytics) permanece intacta, mas times precisam redirecionar automações da API Sentinel para a Microsoft Graph Security API, revisar workflows baseados em IDs de incidentes e designar um workspace primário para receber a correlação XDR. Para empresas brasileiras, o ganho é operacional: menos incidentes duplicados e investigações mais ricas, desde que o planejamento de retenção e governança seja ajustado.
O que muda na experiência de incidentes?
Incidentes são o centro das operações de segurança. É aqui que muitas equipes sentirão imediatamente os benefícios do Defender.
No Defender:
- A correlação não é mais feita pelo antigo mecanismo “Fusion” – agora é gerenciada pelo motor de correlação do Defender, criando alertas uma única vez a partir de dados do Defender e do Sentinel.
- A correlação é mais rica e conectada.
- Atividades relacionadas são agrupadas de forma mais eficaz.
- Analistas investigam por meio de uma attack story, em vez de alertas isolados.
O resultado é um fluxo de investigação mais eficiente: uma única campanha ou cadeia de ataque pode ser representada como um incidente único, em vez de vários registros desconexos que precisam ser manualmente consolidados.
Analistas ganham acesso a:
- Visualização da attack story
- Ativos e evidências relacionados
- Linhas do tempo de investigação
- Atividades correlacionadas
- Contexto entre domínios
- Experiências integradas de hunting
Para organizações que utilizam o data lake e os recursos de grafo do Sentinel, os analistas conseguem visualizar caminhos de propagação de ataques e entender como a atividade pode se espalhar entre ambientes. Isso reduz o tempo de investigação e melhora a clareza e a confiança durante o triage.
Gerenciamento de incidentes – lado a lado
| Aspecto | Azure portal | Defender |
|---|---|---|
| Lista de incidentes | - Seletor de intervalo de datas para filtrar incidentes - Filtrar e ordenar por status, severidade e nome do produto - Atualização automática a cada 30 segundos - Visibilidade do nome do produto (Sentinel ou Defender) e contagem de alertas |
- Lista centralizada de incidentes: incidentes do Defender com retenção de 180 dias; incidentes do Sentinel com retenção dependente das configurações do Log Analytics - Incidentes podem ser provenientes de diferentes serviços, com retenção baseada na configuração padrão de cada serviço - Para reter dados de incidentes do Defender por mais de 180 dias, é preciso estender explicitamente a retenção nas configurações do workspace Sentinel - Incidentes e alertas agora estão no menu Investigation and Response, filtráveis por serviço de origem - Página de incidentes com abas: alertas agrupados no incidente e incidentes similares - Colunas customizáveis e ordenação por pontuação de prioridade baseada em ML - Opções de exportação e cópia de link |
| Detalhes do incidente | - Aba Overview com timeline mostrando alertas e bookmarks - Entidades e incidentes similares - Insights do UEBA - Comentários e tasks para processos SOC |
- Seções para attack story, alertas, ativos, investigações, evidências e respostas; painel de detalhes sempre visível - Ações: acionar playbooks do Sentinel, exportar detalhes em PDF, mesclar ou vincular incidentes - Aba Activities indica se regras de automação ou playbooks foram executados - Um alerta pode ser promovido a incidente - Blast radius analysis (requer data lake e graph) – visualização baseada em grafo que mostra como um ataque pode se espalhar - Integração com Security Copilot otimiza investigação e resposta |
| Criação de incidentes | Criados por regras analíticas do Sentinel ou pelo Fusion a partir de bookmarks/hunting queries | - Cada workspace Sentinel é tratado como fonte de dados separada - Em configurações multi-workspace, deve-se designar um workspace primário: somente ele receberá incidentes e alertas do Defender e correlação XDR - Workspaces secundários podem continuar ingerindo tabelas do Defender, mas a correlação fica restrita aos dados locais - Fusion é substituído pela correlação no primário e nos secundários - Incidentes podem ser criados por regras analíticas, custom detections ou alertas de diferentes fontes (incluindo Sentinel); criação manual está no roadmap |
| Ações de gerenciamento | Atribuição de proprietário, status (novo/ativo/fechado), severidade, comentários, tags, investigation graph, executar playbook | Mesmas ações, mais: atualizar nome, alterar severidade, atribuir para usuários/equipes, adicionar tags, atualizar status (ativo/em andamento/resolvido), fechar com classificação de resolução, executar playbooks do Sentinel diretamente, solicitar especialistas Defender, exportar PDF, mesclar/vincular incidentes. Playbooks gerados por IA (com Security Copilot) com regras de automação aprimoradas. |
| Colaboração | Comentários (HTML/markdown), bookmarks | Activity log para rastrear comentários e auditorias; recurso de tasks com atribuições e datas de vencimento. |
| Fechamento | Classificação obrigatória (true positive, benign positive, false positive, undetermined) | Classificação de resolução obrigatória para fechamento. |
| Consultas | KQL via Log Analytics | KQL via Advanced Hunting ou exploração do data lake do Sentinel. Advanced Hunting permite consultar dados do Sentinel e do Defender em uma única experiência unificada. |
| Alertas de segurança | Visíveis como parte de um incidente | Podem ser promovidos a incidente, além de fazerem parte de um incidente. |
| Detalhes do alerta | Sub-menus do alerta a partir do incidente; detalhes incluem severidade, status, regra analítica etc.; páginas de perfil de entidade | Propriedades completas do alerta com mapeamento de táticas MITRE; entidades e evidências com ações contextuais; timeline de atividades; ferramenta de ajuste de alerta; links para incidentes correlacionados; filtro de alerta customizável com até 180 dias de histórico. |
| Attack story | Investigation graph legado que exigia mapeamento de entidades nas regras analíticas; limitado a incidentes de até 30 dias; maior troca de contexto necessária | Attack story cronológica com capacidade de replay; filtros no grafo (Preview) por severidade, status, serviço de origem e tipo de entidade; grafo do incidente com escopo completo do ataque; pivô de entidades a partir do grafo; “Go hunt” para Advanced Hunting direto em dispositivos, arquivos etc.; ações de remediação imediatas sem perder contexto. |
O que permanece igual
As propriedades dos incidentes (título, descrição, severidade, mapeamento MITRE ATT&CK, táticas e técnicas) são preservadas. Incidentes ainda agregam alertas e entidades como evidência. A criação manual de incidentes a partir de hunting queries continua suportada. Alertas e incidentes ainda podem ser criados por API ou Logic App.
A função Microsoft Sentinel Responder é o papel de privilégio mínimo necessário para um analista SOC gerenciar incidents, casos, tasks, inteligência de ameaças e regras de automação relacionadas ao gerenciamento de incidentes. Essa função mapeia para o Operador de Segurança no URBAC (Unified RBAC).
Como a correlação se torna mais conectada?
Uma das evoluções mais importantes é a substituição do Fusion pelo motor de correlação do Defender.
Essa mudança ajuda a:
- Reduzir incidentes duplicados
- Melhorar a correlação de ataques de múltiplos estágios
- Consolidar atividades relacionadas em investigações mais ricas
- Reduzir o trabalho manual de mesclagem para os analistas
O objetivo é simples: dar aos analistas menos incidentes, de maior qualidade, com mais contexto agregado.
As regras analíticas existentes continuam funcionando, enquanto as novas experiências de custom detection evoluem paralelamente.
As regras de alerta de segurança da Microsoft não são mais exibidas. No portal Azure, os alertas de segurança são detecções individuais geradas quando o Sentinel ou serviços integrados da Microsoft identificam atividade suspeita. Quando produtos Defender estão conectados ao Sentinel no portal Azure, seus alertas fluem para o Sentinel como alertas de segurança. Após habilitar o Sentinel no Defender, as regras analíticas não disparam alertas. Esses alertas de segurança podem ser vistos e consultados na tabela SecurityAlert; as regras analíticas que antes disparavam esses alertas no portal Azure não serão visíveis no Defender.
A blade de regras de detecção personalizadas no Defender exibe tanto regras analíticas quanto custom detections em uma única visualização.
Por que isso é bom: Um motor de correlação em vez de dois significa menos incidentes duplicados, menos mesclagens manuais e uma superfície de investigação (attack story + blast radius) mais rica do que o investigation graph legado que substitui.
Considerações para incidentes e correlação
- Verifique se qualquer automação SOC que fecha ou atualiza incidentes usando a API Sentinel é redirecionada para a Microsoft Graph Security API.
- IDs de incidente, AlertIDs e URLs mudarão (o Defender usa seus próprios identificadores).
- Os nomes dos incidentes são gerados automaticamente pelo motor de correlação do Defender e podem diferir dos nomes das regras analíticas do Sentinel. Atualize roteamento de triagem ou workflows de SLA que dependem do nome do incidente.
- Revise qualquer workflow que dependa de incidentes gerados pelo Fusion, já que ele é substituído pela correlação do Defender.
- No Defender, equipes podem usar tags, consultas salvas e tabelas de hunting customizadas para capturar e organizar o contexto da investigação após um exercício de hunting.
Alertas e schemas evoluem para investigações mais fáceis
À medida que o Sentinel evolui dentro do Defender, o gerenciamento de incidentes se torna mais simplificado, conectado e eficiente em termos de custo. Em vez de depender de regras analíticas separadas de “Microsoft security alerts” para gerar incidentes a partir de cargas de trabalho Defender (endpoint, identidade, aplicativos em nuvem), agora eles são automaticamente correlacionados pelo motor do Defender em uma fila unificada de incidentes.
Essa nova abordagem elimina incidentes duplicados e proporciona uma experiência de investigação mais limpa e consolidada, reunindo alertas relacionados em um único incidente. Também permite modernizar as operações ao migrar de automação em nível de alerta para workflows centrados em incidente, aproveitando as capacidades nativas de automação do Defender.
Além da simplicidade operacional, esse modelo pode ajudar a otimizar custos. Como os dados de alerta estão disponíveis sem exigir ingestão adicional no Log Analytics, as organizações podem ser mais seletivas quanto à ingestão de logs brutos e focar em cenários onde investigações mais profundas, retenção de longo prazo ou requisitos de conformidade sejam necessários.
Ações-chave para a transição
Para uma transição eficaz, as organizações devem primeiro desativar as regras analíticas legadas “Microsoft incident creation rules” e confiar nos conectores individuais do Defender para ingestão de alertas. As estratégias de automação devem ser revisadas e ajustadas, pois o tratamento de incidentes passa de múltiplos registros baseados em alertas para um modelo de incidente correlacionado único – exigindo workflows em nível de incidente.
A integração também introduz sincronização bidirecional de incidentes entre Sentinel e Defender, permitindo gerenciamento consistente de estado em ambos os ambientes, embora o foco operacional deva ser no Defender. Além disso, o novo schema de alertas separa metadados de alerta e evidências. As organizações são incentivadas a adotar as tabelas AlertInfo e AlertEvidence em vez do schema legado SecurityAlert (suportado no Advanced Hunting) para dar suporte a cenários de investigação mais ricos.
Diferenças em nível de campo – metadados do alerta
| Conceito | Azure (SecurityAlert) | Defender (AlertInfo) |
|---|---|---|
| ID do alerta | SystemAlertId | AlertId |
| Nome | AlertName | Title |
| Severidade | Severity | Severity |
| Produto / Provedor | ProviderName | DetectionSource / ServiceSource |
| Descrição | Description | Title / Description equivalente |
| Tempo | TimeGenerated | TimeGenerated |
A principal mudança aqui é a normalização dos nomes padronizada em todos os sinais do Defender.
Diferenças em nível de campo – modelagem de entidades/evidências
| Conceito | Azure (SecurityAlert) | Defender (AlertEvidence) |
|---|---|---|
| Entidades | JSON (Entities) | Linhas (1 linha por entidade) |
| Tipo de entidade | Dentro do JSON | Coluna EntityType |
| Host | Campo JSON | DeviceName, DeviceId |
| Usuário | Campo JSON | AccountName, AccountSid |
| IP | Campo JSON | IPAddress |
| Arquivo | Campo JSON | FileName, SHA256 |
A principal mudança aqui é a passagem de JSON desnormalizado para colunas fortemente tipadas, facilitando joins, filtros e agregações.
Diferenças nas consultas – antes e depois
Azure (clássico):
SecurityAlert | extend Entities = parse_json(Entities) | mv -expand Entities | where Entities.Type == "account"
Defender (recomendado):
AlertInfo | join AlertEvidence on AlertId | where EntityType == "Account"
Ao aproveitar o conector unificado do Microsoft Defender, seu SOC ganha eficiência (sem duplicidade de tratamento da mesma ameaça), clareza (um incidente é uma única campanha ou cadeia de ataque) e potencial redução de custos.
Por que isso é bom: O novo schema não é um custo de migração – é um modelo de consultas mais fácil de escrever, mais fácil de ensinar para novos analistas e evita o parsing de JSON que os engenheiros de detecção do Sentinel precisavam fazer.
Sua arquitetura de dados subjacente permanece intacta
Nesse processo, seu workspace do Log Analytics, configurações de retenção, exportação de dados e controles de governança são todos preservados.
| Aspecto | Azure portal | Defender |
|---|---|---|
| Armazenamento | Workspace do Log Analytics no Azure | Workspace do Log Analytics no Azure (inalterado) |
| Camadas de armazenamento | Analytics logs, Basic logs, Auxiliary logs, Archive | · Analytics logs, Basic logs, Auxiliary logs, Archive (inalterado) · Alterar a camada de Basic logs ou Auxiliary logs requer ir para a experiência do workspace Log Analytics no portal Azure. O data lake do Sentinel para retenção de longo prazo é opcional e fica disponível assim que o Sentinel é configurado no portal Defender · Se o workspace primário for integrado ao data lake, as tabelas Basic logs e Auxiliary logs são convertidas para a camada do data lake |
| Retenção padrão do workspace | Configurada nas configurações do workspace Log Analytics | Continua sendo configurada no portal Azure ou via CLI/API (inalterado) |
| Retenção por tabela | Configurada por tabela no Log Analytics | Gerenciamento de retenção e camada por tabela disponível diretamente no Defender |
Nota sobre disponibilidade do data lake: O data lake do Microsoft Sentinel ainda não está disponível em todas as regiões Azure. Verifique a cobertura atual no Microsoft Learn antes de planejar a integração: Disponibilidade geográfica e residência de dados no Microsoft Sentinel. Seu data lake será provisionado na mesma região do seu workspace Sentinel primário.
Content Hub e investimentos existentes continuam funcionando
O Content Hub continua sendo o mecanismo para descobrir e implantar pacotes de solução (conectores, regras analíticas, workbooks, playbooks) para o Sentinel. Mais de 450 modelos de solução da Microsoft, parceiros e contribuidores da comunidade estão disponíveis no catálogo de soluções do Sentinel.
Considerações sobre a transição:
- O Content Hub está totalmente disponível no Defender. Não é necessário voltar ao portal Azure para gerenciamento de conteúdo.
- Repositories (CI/CD para conteúdo do Sentinel) e Community continuam funcionando no Defender.
- Não há mudanças nos mecanismos de atualização de conteúdo. As soluções continuam recebendo atualizações pelo Content Hub como antes.
O que isso significa para cada persona?
| Persona | O que muda |
|---|---|
| Analista SOC | Fila única de incidentes. Attack story substitui o investigation graph legado. “Go hunt” está a um clique. Bookmarks são substituídos por tags e queries salvas. |
| Engenheiro de detecção | Regras analíticas “Microsoft security alerts” são descontinuadas. AlertInfo + AlertEvidence tornam-se o schema canônico para novas detecções e hunting queries. Lógica dependente do Fusion migra para comportamento de correlação XDR. |
| Responsável por automação/SOAR | Redirecione toda automação que atualiza incidentes para a Microsoft Graph Security API. Mude gatilhos de nível de alerta para nível de incidente. Revise workflows de SLA e roteamento que dependem de nomes de incidentes. |
| Arquiteto | Decida explicitamente qual workspace é o primário – somente ele recebe incidentes e alertas do Defender e correlação XDR. Planeje os deltas de retenção (Defender XDR 180 dias vs. Sentinel estendido). |
| Compliance / Responsável por dados | Log Analytics, retenção e controles por tabela permanecem inalterados. A integração com data lake é opcional. Documente a história de residência de dados para auditorias – a camada de armazenamento não mudou. |
Esclarecendo equívocos comuns
- “Fusion ainda roda em segundo plano.” Não. Fusion é substituído pelo motor de correlação do Defender no workspace primário.
- “Meus dados do Sentinel precisam ser migrados.” Não. O workspace do Log Analytics permanece inalterado. Armazenamento, retenção e configurações por tabela são preservados.
- “Vou perder minhas regras analíticas existentes.” As regras analíticas do Sentinel continuam funcionando e são exibidas na blade unificada de regras de detecção personalizadas, ao lado das custom detections. O roadmap as convergirá apenas quando as custom detections atingirem paridade total.
- “Os IDs de incidente permanecerão os mesmos, então meus tickets não quebrarão.” IDs de incidente e URLs mudam no Defender. Atualize qualquer integração externa de ticketing ou webhook.
- “Minhas soluções do Content Hub precisam ser reinstaladas.” Não. O Content Hub continua disponível no Defender. Soluções, repositórios e comunidade continuam funcionando.
Comece agora
- Designe seu workspace Sentinel primário e documente a decisão. Somente o primário recebe incidentes/alertas do Defender e correlação XDR.
- Faça um inventário das automações que atualizam ou fecham incidentes via API Sentinel. Marque-as para redirecionamento para a Microsoft Graph Security API.
- Identifique sistemas externos que dependem de IDs de incidente, URLs ou nomes de incidentes. Sinalize para atualização.
- Pilote uma nova query de hunting usando
AlertInfo+AlertEvidencepara familiarizar a equipe com o novo schema. - Confirme que as soluções do Content Hub e os pipelines de repositórios estão visíveis e operacionais a partir do Defender.
- Se a retenção de longo prazo estiver no roadmap, confirme se a região do workspace primário é suportada pelo data lake antes de planejar a integração: Disponibilidade geográfica e residência de dados.
Artigo originalmente publicado por Mohit_Kumar em Azure Updates – Latest from Azure Charts.
Perguntas Frequentes
-
Preciso migrar meus dados do Log Analytics para o Defender?
Não. O workspace do Log Analytics permanece inalterado. Todas as configurações de retenção, exportação e governança são preservadas. A migração é de portal e engine de correlação, não de armazenamento. -
Minhas regras analíticas do Sentinel deixarão de funcionar?
Elas continuam funcionando e são exibidas na nova blade de regras de detecção personalizadas do Defender. Apenas as regras de 'Microsoft security alerts' são descontinuadas. O roadmap prevê convergência futura com custom detections. -
Os IDs de incidentes mudam? Preciso atualizar minhas integrações?
Sim. O Defender usa seus próprios identificadores de incidente e alerta. Todas as automações que utilizam a API Sentinel devem ser redirecionadas para a Microsoft Graph Security API. Integrações com sistemas externos de ticket precisam ser atualizadas. -
O Fusion ainda roda em segundo plano?
Não. O Fusion é substituído pelo motor de correlação do Defender no workspace primário. Workflows que dependem de incidentes gerados pelo Fusion precisam ser revistos. -
O que acontece com meus playbooks e automações?
Playbooks continuam funcionando e podem ser acionados diretamente do Defender. A Microsoft recomenda migrar automações de nível de alerta para workflows centrados em incidente e reavaliar regras de SLA que usam nomes de incidentes gerados automaticamente.
