TL;DR
Este artigo analisa a transição do Microsoft Sentinel para o Microsoft Defender, mostrando como analytics rules, playbooks e hunting evoluem sem exigir reescrita — mas com ganhos reais em velocidade, automação e alcance cross-platform. Para empresas brasileiras, o principal ponto é que a migração expande o ferramental, não o reduz, e exige planejamento na adoção de custom detections para dados Defender e na manutenção de regras legadas para fontes não-Defender.
Detecção e Automação Reimaginadas no Microsoft Defender: O Que Muda para Times de Segurança no Brasil
Co-authored with Lizet Pena, Caroline Mutua, Alvin Kua and Marco Sudahl
How analytics rules, playbooks, workbooks, and hunting evolve in Defender—and why the new toolbelt makes detection engineering faster, automation richer, and hunting genuinely cross-platform.
Se você constrói detecções profissionalmente, a migração para o Defender representa uma das mudanças mais significativas no seu fluxo de trabalho nos últimos anos — e, para a maioria dos times, é uma mudança bem-vinda. Suas analytics rules existentes não desaparecem. Seus playbooks não precisam ser reescritos. Suas workbooks continuam funcionando exatamente como hoje. O que muda é o escopo do que você pode detectar, automatizar e investigar a partir de uma única experiência.
Esse escopo agora inclui endpoint, identidade, e-mail, cloud apps e dados do Sentinel juntos — permitindo que analistas consultem múltiplas fontes de dados em uma única experiência KQL, investiguem a partir de uma única fila de incidentes e automatizem com ações de resposta mais ricas. Custom detections introduzem detecções em near-real-time com ações de resposta nativas do Defender. Security Copilot pode ajudar a gerar playbooks a partir de prompts em linguagem natural. Advanced hunting agora abrange dados do Defender e do Sentinel juntos, expandindo dramaticamente o que os hunters podem explorar. Realize threat hunting de ponta a ponta com hunts. O resultado não é um toolset menor ou uma substituição forçada do que existe hoje. É um toolset expandido.
Neste post, vamos percorrer as principais mudanças em detection engineering, automação, hunting, workbooks e case management — incluindo onde os investimentos existentes permanecem inalterados, onde a experiência melhora e como escolher a ferramenta certa para o cenário certo daqui para frente.
O que este post cobre
- Detection: analytics rules e custom detections convergem em uma experiência compartilhada
- Automation: playbooks são aprimorados
- Workbooks: mesmo canvas, contexto investigativo mais rico
- Hunting: de hunting focado em Sentinel para advanced hunting cross-platform
- Case management: investigações finalmente ganham um workspace durável
- Uma nota rápida sobre watchlists
- Implicações por persona, misconceptions comuns e um checklist prático "faça esta semana"
Detection: Analytics rules e custom detections convergem
Detection engineering está mais flexível no Defender.
As equipes ainda têm acesso às familiares scheduled analytics rules e detecções estilo SIEM, e agora ganham acesso a custom detections — um modelo de detecção mais rápido e moderno, projetado para telemetria do Defender e resposta em near-real-time.
Tipos de regras no Sentinel:
- Scheduled query rules – detecções tradicionais baseadas em KQL que executam em schedule
- Microsoft security rules – detecções gerenciadas pela Microsoft para serviços Defender e outros produtos Microsoft de segurança
- Anomaly rules – detecções comportamentais baseadas em ML
- Threat intelligence rules – detecções alimentadas por matching de indicadores
- Custom detections – detecções modernas alimentadas por advanced hunting queries, com execução em near-real-time e ações de resposta nativas
Uma das maiores mudanças arquiteturais é a aposentadoria da regra Fusion em favor do mecanismo de correlação do Defender. Em vez de gerenciar o Fusion separadamente, os analistas agora se beneficiam da correlação diretamente dentro do processamento de incidentes do Defender.
Ao mesmo tempo, a experiência de regras fica mais simples. O Defender exibe tanto as analytics rules do Sentinel quanto as custom detections juntas em uma única visualização.
O que muda após o onboarding no Defender
Várias mudanças operacionais importantes acontecem automaticamente:
- Fusion é substituído pelo mecanismo de correlação do Defender
- Microsoft incident creation rules vinculadas a produtos Defender não são mais exibidas separadamente
- Alertas relacionados são consolidados em incidentes mais ricos dentro do Defender
- Analytics rules e custom detections aparecem juntas em uma experiência
Isso também muda como as organizações devem pensar sobre detecções daqui para frente.
Historicamente, os alertas de segurança da Microsoft frequentemente fluíam para o Sentinel como alertas individuais gerados por produtos Microsoft. No Defender, esses alertas são correlacionados nativamente em uma única fila de incidentes, reduzindo incidentes duplicados e simplificando investigações.
Por que custom detections são importantes a longo prazo
Custom detections desbloqueiam novas capacidades para detection engineering no Defender. Elas oferecem:
- Detecções streaming mais rápidas e em near-real-time
- Ações de resposta embutidas
- Visibilidade cross-platform
- Eficiências de custo para telemetria do Defender
- Uma experiência de criação simplificada integrada com advanced hunting
À medida que a paridade de funcionalidades melhora, a maioria das organizações construindo novas detecções em telemetria do Defender provavelmente padronizará em custom detections daqui para frente.
Isso não significa que analytics rules desaparecem. Elas continuam críticas para:
- Casos de uso SIEM cross-vendor
- Firewall e telemetria de rede
- Ambientes OT
- Cenários de SaaS e logs customizados
- Correlação ampla entre fontes não-Defender
O resultado é flexibilidade prática: suas analytics rules e detecções existentes continuam rodando em uma interface de regras que abrange ambos os mundos, então você pode usar o melhor mecanismo para a fonte de dados e caso de uso que está resolvendo.
O que muda após o onboarding no Defender
| Change | Detail |
|---|---|
| Fusion disabled | A regra de detecção avançada de ataques multi-estágio (Fusion) não é mais suportada. Suas funções são substituídas pelo mecanismo de correlação do Defender. O Defender correlation também está disponível em workspaces secundários, mas apenas no escopo de dados do Sentinel nesses workspaces. |
| Microsoft incident creation rules | As regras de alerta de segurança Microsoft não são mais exibidas. No Microsoft Sentinel no portal Azure, alertas de segurança são detecções individuais geradas quando o Sentinel ou serviços de segurança Microsoft integrados identificam atividade suspeita ou maliciosa. Quando produtos Microsoft 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 analytics rules não disparam alertas. Esses alertas de segurança podem ser vistos e consultados na tabela SecurityAlert. |
| Unified rules view | A blade de custom detection rules em Advanced Hunting no Defender exibe tanto as analytics rules do Sentinel quanto as custom detections em uma única visualização. |
Considerações de transição
- Assim que o Fusion for desabilitado automaticamente, verifique se a correlação XDR está gerando incidentes multi-estágio no Defender com alertas de várias fontes, e pare de depender de customizações ou automações específicas do Fusion.
- O mecanismo de correlação XDR não se limita a fontes de dados Defender e Sentinel.
- Reforce os mapeamentos de entidade (accounts, hosts, IPs) em suas analytics rules para maximizar a qualidade da correlação, e monitore o volume de incidentes pós-transição para incidentes menos numerosos, porém mais consolidados e ricos.
Quando o conector Defender é habilitado no Sentinel (portal Azure), o conector substitui automaticamente essas regras e fornece integração bidirecional. Você ainda pode usar uma automation rule com o nome do produto que gerou o alerta.
Por que isso é bom: Dois modelos de detecção, uma visualização de regras. Você não escolhe um lado, mas sim a ferramenta certa: custom detections para sinais nativos do Defender com resposta near-real-time e analytics rules para casos de uso SIEM cross-vendor. A convergência está no roadmap, não é um corte forçado.
Custom detections versus analytics rules
| Use when… | Custom detections (Defender) | Analytics rules (Sentinel) |
|---|---|---|
| Data source | Telemetria Defender (endpoint, identidade, e-mail, cloud apps) além das tabelas Sentinel | Logs não-Defender, cross-vendor e customizados ingeridos no Sentinel |
| Speed/workflow | Detecções mais rápidas, near-real-time, com ações de resposta nativas. Veja custom detection rules. | Detecções SIEM após ingestão, automação via playbooks/automation rules |
| Detection logic | KQL, dentro dos limites do schema Defender | KQL com flexibilidade total do Sentinel |
Quando custom detections são melhores
- Sua detecção é baseada em sinais Defender (endpoint/identity/email/cloud)
- Você quer detecções mais rápidas com ações de resposta XDR embutidas
- Você opera principalmente no Defender
- Recomendado como detecção padrão para sinais Defender e Sentinel
Quando analytics rules do Sentinel são melhores
- Você precisa de dados não-Defender (firewalls, SaaS, OT, custom logs)
- Você precisa de correlação KQL cross-source/cross-vendor em SIEM
- Você está construindo casos de uso SIEM clássicos
Automação e SOAR: Playbooks aprimorados, não aposentados
No Azure Sentinel (portal legado), playbooks são logic apps que automatizam ações de resposta, tipicamente acionados por automation rules na criação de incidentes ou alertas. Isso fornece capacidades robustas de SOAR (Security Orchestration, Automation, and Response), mas exige que os analistas gerenciem os triggers e a execução dos playbooks a partir da interface Azure.
Mudanças no Defender: No Defender, o uso de playbooks é aprimorado e ligeiramente redefinido (Generate playbooks using AI in Microsoft Sentinel | Microsoft Learn).
Comparação
| Capability | Azure portal | Defender |
|---|---|---|
| Manual triggers | Playbooks podem ser executados manualmente em incidents, alerts e entities a partir da página de incidentes do Sentinel. Execução manual é uma forma comum de testar ou realizar remediação orientada por analista. | Playbooks podem ser executados manualmente em incidents e alerts na fila de incidentes do Defender. Execução manual ainda é suportada, mas ações manuais em nível de entidade são cada vez mais tratadas por experiências nativas do Defender. |
| Built-in response actions | Ações nativas limitadas. Remediação tipicamente depende de playbooks (logic apps) para isolar dispositivos, desabilitar usuários, abrir tickets ITSM ou enviar notificações. | Ações de resposta nativas robustas do Defender disponíveis diretamente no incidente (ex.: isolamento de dispositivo, contenção de usuário, ataque disruption). Reduz a necessidade de playbooks customizados para cenários comuns de contenção. |
| Automation rule compatibility | Automation rules disparam playbooks na criação/atualização de incidentes ou criação de alerts. Separação clara entre alerts Sentinel e incidents. | Automation rules disparadas por incidente se aplicam a incidentes unificados (Sentinel + Defender). Regras disparadas por alerta atuam apenas em alerts de origem Sentinel. |
| AI and automation | Sem experiência nativa com Security Copilot. Lógica de playbook é autorada manualmente em logic apps. | Security Copilot aumenta investigações e resposta. Playbook generator (preview) permite criação assistida por IA de playbooks a partir de prompts em linguagem natural. |
Principais considerações de transição
- Revise e ajuste suas automation rules
- Aproveite as ações embutidas do Defender
- Teste os playbooks
- Atraso leve na automação (até ~5-10 minutos entre criação do incidente e execução da automation rule)
- Estratégia de automação dupla
Resumo
Todos os playbooks existentes continuam rodando na infraestrutura do Azure Logic Apps (a definição do playbook em si não é migrada). O Defender expõe esses playbooks e permite acioná-los, mas você ainda vai projetar e editar playbooks no designer de logic apps do portal Azure — os triggers e ações disponíveis permanecem inalterados. Nenhuma reescrita é necessária, mas você deve adaptar como e quando os triggers e ações dos playbooks são invocados para alinhar com o novo modelo unificado de incidentes. Os playbooks continuam sendo parte central do seu kit SOAR, e agora são aprimorados pelo uso on-demand e pela integração de IA que está por vir.
Por que isso é bom: Zero migração de playbooks. Seu investimento em SOAR segue exatamente como está, e as novas ações de resposta nativas do Defender (isolamento de dispositivo, contenção de usuário, ataque disruption) cobrem os cenários de contenção mais comuns de forma nativa, permitindo que seus playbooks customizados foquem nos workflows de orquestração e cross-tool que realmente precisam deles.
Workbooks: Mesmo canvas, melhores surroundings
Workbooks fornecem visualizações e dashboards interativos para investigação, monitoramento e relatórios sobre dados do Microsoft Sentinel. Com a mudança para o Defender, os workbooks continuam sendo um ativo central de análise, enquanto a experiência ao redor melhora através de integração mais estreita com incidentes unificados, hunting e visibilidade cross-produto.
Comparação
| Capability | Azure portal | Defender |
|---|---|---|
| Authoring and storage | Workbooks são criados, editados e armazenados no Azure (Log Analytics/Sentinel). Experiência completa de autoria no portal Azure. | Mesmos workbooks e armazenamento (sem duplicação). A autoria ainda acontece principalmente no Azure; o Defender foca no consumo e na navegação. |
| Access and navigation | Acessado diretamente do Microsoft Sentinel → Workbooks. Context switching necessário entre Sentinel e outras ferramentas de segurança. | Workbooks são descobertos e acessíveis no Defender junto com incidentes e hunting. Reduzido context switching ao mover de um incidente para análise visual. |
| Data scope and context | Visualiza fontes de dados do Sentinel conectadas ao workspace. Consciência limitada do contexto gerado pelo Defender XDR. | Workbooks se beneficiam de sinais unificados Sentinel + Defender disponíveis no mesmo fluxo de investigação. Melhor alinhamento com incidentes e entidades unificados. |
| Incident and investigation integration | Usado como auxílio de investigação paralelo; analistas correlacionam manualmente insights de workbooks com incidents. | Workbooks complementam a fila de incidentes unificada, permitindo pivot mais rápido de incidents para dashboards e hunting views. |
| Feature parity and enhancements | Conjunto completo de funcionalidades para criação e customização de workbooks. | Nenhuma regressão funcional. Melhorias incrementais na experiência através de navegação unificada e visibilidade cross-produto. |
Considerações principais
- Nenhuma migração é necessária
- O Azure continua sendo a fonte de verdade para autoria
- Fluxo investigativo mais forte
- Não substituído pelo Copilot
- Modelo de acesso consistente
- Compartilhamento mais amplo (opcional)
Melhores práticas
- Padronize workbooks chave
- Projete para pivot
- Reutilize, não duplique
- Combine com hunting
- Revise periodicamente
Por que isso é bom: Zero migração de workbooks. Cada dashboard, cada visualização, cada camada de relatório que você construiu continua funcionando e ganha surroundings melhores: descobertos a partir de incidentes, emparelhados com hunting, contextualizados por entidades unificadas.
Hunting: De focado em Sentinel para cross-platform advanced hunting
Hunting e advanced hunting ambos suportam detecção e investigação de ameaças, mas diferem em escopo e uso. Hunting no Microsoft Sentinel foca em logs do Sentinel e é melhor para investigações KQL hipótese-driven dentro do Sentinel. A retenção dos dados usados para hunting segue as configurações de log do Sentinel. Advanced hunting no Microsoft Defender oferece uma experiência unificada através de dados do Sentinel e do Defender XDR, permitindo queries cross-platform, remediação em tempo real e automação. Os dados do Defender são tipicamente retidos por 30 dias, com retenção mais longa disponível através do data lake do Sentinel. Em resumo, hunting é melhor para investigações focadas no Sentinel, enquanto advanced hunting é construído para análise e resposta mais amplas e cross-platform.
O que muda
- Queries e funções do Sentinel se tornam view-only no Defender (podem executar, mas não editar diretamente)
- Editar requer retornar ao portal Azure durante o período de transição
- Grande vantagem: Advanced hunting no Defender permite consultar ambas as tabelas Sentinel e Defender XDR em uma única query
- Histórico de queries mostra todas as consultas executadas em ambas as fontes de dados
Benefícios do advanced hunting
- Cross-platform hunting: Uma única query KQL abrange endpoint (Defender for Endpoint), email (Defender for Office 365), identidade (Defender for Identity) e fontes de dados Sentinel
- Schema unificado: Todas as tabelas acessíveis em um editor de query com browser de schema
- Saved Sentinel queries disponíveis: Suas queries de hunting existentes permanecem acessíveis
- Custom detections: Converta queries de hunting em regras de detecção (Defender XDR custom detections para tabelas Defender; Sentinel analytics rules para tabelas Sentinel)
Comparação
| Feature | Hunting (Sentinel) | Advanced hunting |
|---|---|---|
| Data scope | Apenas logs Sentinel | Sentinel + Defender XDR |
| Portal | Sentinel | Defender |
| Retention | Baseado em configurações Sentinel | 30 dias (Defender), retenção maior via Sentinel |
| Actions | Criar rules/incidents | Remediação em tempo real + custom detections |
| Complexity | Focado em Sentinel | Queries cross-platform |
Por que isso é bom: Uma query KQL, quatro superfícies de detecção. Threat hunters agora abrangem endpoint, identidade, email, cloud apps e Sentinel em uma única query — com ações de resposta em tempo real a um clique de distância. Queries Sentinel salvas seguem adiante; o canvas ficou maior.
De incident-centric a case-centric investigation
As mudanças em detecção, automação e hunting que acabamos de percorrer convergem na mesma pergunta: uma vez que o SOC tem um conjunto mais rico de incidentes, hunts cross-platform e contenção automatizada rodando, onde o trabalho investigativo de longa duração realmente vive? No portal Azure, o incidente sempre foi o topo da pilha de trabalho — não havia nada acima dele para organizar uma investigação de campanha de várias semanas, um hunt proativo ou uma caça a IoCs em múltiplos incidentes. As equipes recorriam a páginas do OneNote, threads de email e tickets externos. O Defender fecha essa lacuna com uma nova primitiva: o case.
Case management no Defender é um workspace nativo e focado em segurança para trabalho de SecOps que abrange múltiplos incidentes — incluindo campanhas multi-incident, threat hunting, rastreamento de IoCs e threat-actors, e backlogs de ajuste de detecção.
Cases estão disponíveis apenas no Defender e exigem uma conexão com workspace Sentinel. Veja Manage security operations cases natively in Microsoft Defender.
Comparação
| Capability | Azure portal | Defender (cases) |
|---|---|---|
| Multi-incident container | Não disponível; incidente é o item de trabalho de nível superior | Cases vinculam nativamente múltiplos incidentes e IoCs |
| Workflow and status | Status fixos de incidente (New/Active/Closed) | Status customizáveis de case definidos por admins SOC |
| Task tracking | Não disponível | Tarefas embutidas com owner, prioridade, data de vencimento e status |
| Collaboration | Comentários em incidentes individuais | Comentários rich-text, attachments (até 10 por comentário) e audit log completo |
| Linking | Não disponível | Vincular cases a incidentes e a indicadores de threat intel (preview) |
| Access control | RBAC do Microsoft Sentinel | RBAC unificado do Defender ou roles Sentinel |
Service limits
- 100.000 cases por tenant
- 500 GB de attachments por tenant
- 100 incidentes vinculados por case
Transition considerations
- Desenvolva diretrizes sobre quando os analistas devem criar um case (ex.: campanhas multi-incidente ou threat hunts proativos)
- Se você usa sistemas de ticketing externos (ServiceNow, JIRA) para rastreamento multi-incidente, determine como os cases se complementam ou integram com eles
Por que isso é bom: Investigações finalmente têm um lar acima do incidente. Campanhas multi-incidente, hunts e caças a IoCs param de viver em páginas do OneNote e tickets externos, e passam a viver junto aos dados de segurança — com seus próprios status, tarefas, comentários e audit trail. Nada no seu workflow de incidente atual muda; cases simplesmente dão uma camada durável para o trabalho que costumava cair entre as rachaduras.
Uma nota rápida sobre watchlists
Nem tudo nesta transição está mudando — e isso é uma feature, não uma falha. Watchlists são um bom exemplo: uma primitiva que já fazia bem seu trabalho e que simplesmente segue adiante inalterada na experiência unificada.
Sem mudanças. Watchlists continuam sendo uma feature do Azure Sentinel para tabelas de lookup semi-estáticas e customizadas.
| Aspect | Azure portal | Defender |
|---|---|---|
| Surrounding context | Blade standalone do Sentinel | Unificado com incidents, hunting e entity pages do Defender |
Transition considerations
- Watchlists podem ser acessadas na seção de configuração e através de watchlist queries junto com dados Defender XDR
- Você pode fazer upload de uma watchlist criada a partir de um CSV ou outra fonte
Por que isso é bom: Suas watchlists existentes continuam funcionando, seu KQL continua funcionando, e o contexto ao redor ficou mais rico — a mesma tabela de lookup agora se junta contra entidades e incidents do Defender junto com dados Sentinel. Zero migração, alcance ampliado.
O que isso significa para cada persona
| Persona | O que muda |
|---|---|
| Detection engineer | Dois motores, uma visão de regras. Use custom detections para sinais Defender (mais rápidos, ações de resposta nativas); mantenha analytics rules para SIEM cross-vendor. Mapeamentos de entidade fortes são mais importantes que nunca. |
| SOAR/Automation owner | Zero migração de playbooks — logic apps ficam onde estão. Reaponte automation rules para incidentes unificados. Use as ações de resposta nativas do Defender para contenção de rotina. |
| Threat hunter | Seu canvas KQL agora é cross-platform. Queries Sentinel salvas seguem adiante (view-only no Defender durante transição; edite no Azure). "Convert hunt to detection" vira parte do loop diário. |
| SOC analyst | Workbooks estão onde o incidente vive. Hunting está a um clique do triage via "Go hunt". Ações de resposta embutidas reduzem os hops de playbook. |
| Architect | Decida sua política de detecção por fonte: dados Defender → custom detections; SIEM cross-vendor → analytics rules; firewalls/SaaS sem detecções nativas → Sentinel. Planeje um período de automação dupla. |
Esclarecendo misconceptions comuns
- "Minhas analytics rules serão deletadas." Não. As analytics rules do Sentinel continuam funcionando e aparecem na blade unificada.
- "Preciso reescrever meus playbooks." Não. Todos os playbooks continuam no Azure Logic Apps.
- "Custom detections substituem completamente analytics rules hoje." Ainda não. A convergência só acontece quando alcançarem paridade total.
- "Meus workbooks precisam ser recriados no Defender." Não. Mesmos workbooks, mesmo armazenamento.
- "Fusion ainda está rodando." Não. O Fusion foi substituído pelo mecanismo de correlação XDR.
- "Advanced Hunting e Hunting são a mesma coisa." São complementares. Hunting é focado em Sentinel; advanced hunting abrange Sentinel + Defender XDR.
Faça esta semana
- Faça um inventário das suas analytics rules por source
- Confirme mapeamentos de entidade (accounts, hosts, IPs) nas suas rules ativas
- Pilote uma custom detection em dados Defender com ação de resposta embutida
- Revise suas automation rules: quais disparam em nome do incidente, quais no nome da regra, quais acionam playbooks
- Valide que todos os playbooks existentes permanecem acionáveis da fila de incidentes unificada
- Execute uma query advanced hunting que una tabelas Defender XDR com tabelas Sentinel
- Se você usa Security Copilot, habilite a experiência embarcada e a integração Microsoft Sentinel
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
Perguntas Frequentes
-
Preciso reescrever meus playbooks ao migrar para o Defender?
Não. Todos os playbooks existentes continuam rodando na infraestrutura do Azure Logic Apps. O Defender apenas os expõe e aciona; a edição ainda acontece no portal Azure. Nenhuma reescrita é necessária.
-
Custom detections substituem completamente as analytics rules no Defender?
Ainda não. A Microsoft está convergindo os dois modelos, mas custom detections só alcançam paridade total quando suportarem todas as fontes. Hoje, analytics rules continuam essenciais para dados não-Defender, firewalls, SaaS e ambientes OT.
-
O que acontece com minhas workbooks após a migração?
Nada. As workbooks permanecem no Azure (Log Analytics/Sentinel) sem migração. O Defender melhora o consumo e a navegação, mas a criação e edição continuam no portal Azure. Nenhum dashboard precisa ser recriado.
-
Fusion ainda está ativo no novo modelo?
Não. A regra Fusion foi substituída pelo mecanismo de correlação do Defender (XDR). Verifique se a correlação XDR está gerando incidentes multi-estágio e descarte qualquer automação personalizada que dependia do Fusion.
-
Hunting e Advanced Hunting são a mesma coisa?
São complementares. Hunting foca em Sentinel logs (hipótese-driven), enquanto Advanced Hunting abrange Sentinel + Defender XDR em uma única query KQL, com ações de remediação em tempo real. Ambos coexistem, mas com escopos diferentes.
