Microsoft Security Copilot

Nota da subpasta 05 - Plataformas de IA para Segurança, no Capítulo 24 (Ferramentas e Plataformas Atualizadas).
Trata do Security Copilot como copiloto da Microsoft integrado ao Defender XDR e ao Sentinel: resumo de incidentes, guia de resposta, KQL assistido e uso em triagem e hunting.
Dialoga com as notas de CrowdStrike Charlotte AI e de Cyware Quarterback AI da mesma subpasta, e com as notas de Elastic, Wazuh e Splunk da pasta 02.

1. Contexto e Posicionamento na Biblioteca

O Security Copilot é o copiloto de segurança da Microsoft, anunciado em 2023 e consolidado ao longo de 2024 em duas formas de consumo: as experiências embutidas nos produtos, como o Copilot no Defender XDR e no Sentinel, e o portal autônomo para usos mais abertos. A proposta é a mesma do copiloto de código que inspirou a categoria: colocar um modelo de linguagem com acesso ao contexto operacional ao lado do analista, para que o tempo que hoje se gasta lendo, correlacionando e redigindo se converta em tempo de decisão. A diferença competitiva da Microsoft está na amplitude do ecossistema, porque o copiloto fala com os produtos de identidade, endpoint, e-mail, nuvem e SIEM da mesma família.

Para esta biblioteca, a nota cumpre dois papéis. O primeiro é registrar as capacidades concretas que o copiloto entrega em triagem e hunting, com exemplos de fluxo que o analista reconhece no dia a dia. O segundo é contrapor a abordagem da Microsoft à da CrowdStrike, tratada na nota de Charlotte AI, e preparar o contraste com o agente autônomo da nota de Quarterback AI, fechando o espectro de autonomia que a subpasta 05 desenha.

A nota segue o padrão de análise da nota de Charlotte AI: capacidades primeiro, riscos com o mesmo peso e um fluxo de uso que o analista reconhece. A diferença de ecossistema produz diferenças operacionais concretas, com o Security Copilot forte onde o ambiente é Microsoft e dependente de plugins onde não é, e essas diferenças aparecem nas seções seguintes com exemplos em KQL, a linguagem que as notas de detecção da biblioteca usam nos exemplos do Sentinel.

2. Integração com o Ecossistema Microsoft

A arquitetura de integração é o que define a experiência do Security Copilot. Nas experiências embutidas, o copiloto aparece dentro das consoles de Defender XDR, Sentinel, Intune, Purview e Entra, herdando o contexto da tela em que o analista está e as permissões do seu papel. O modelo é alimentado por três fontes de contexto: os sinais do tenant, o corpus de threat intelligence da Microsoft e o conhecimento de resposta consolidado pela fabricante. As permissões seguem o RBAC dos produtos, o que significa que o copiloto não revela ao analista o que o papel dele não alcança, e a configuração correta de RBAC é, portanto, pré-requisito de segurança e não detalhe administrativo.

O provisionamento funciona por unidades de capacidade, as SCU, do inglês Security Compute Unit, que dimensionam o consumo do copiloto. O desenho de custo importa para o SOC porque o consumo escala com o uso: resumir incidentes com frequência, rodar muitas sessões de caça assistida e manter sessões longas consomem capacidade, e o programa precisa de janela e escopo de uso definidos. A extensibilidade aceita plugins que trazem dados de parceiros, o que amplia o alcance do copiloto para além do primeiro partido, com o cuidado de validar cada plugin quanto à origem dos dados que expõe.

Uma característica que difere do copiloto concorrente é o peso do contexto de identidade. Comprometimento de conta, consentimento anômalo de aplicativo e manipulação de regras de caixa são casos em que o copiloto produz narrativa de alta qualidade, porque os sinais de identidade, e-mail e endpoint do tenant chegam correlacionados dos produtos nativos. Em ambientes híbridos, o mesmo caso depende de plugins e de integração com o SIEM existente para alcançar qualidade equivalente, e o desenho de cobertura precisa refletir essa dependência desde o planejamento.

A lista abaixo resume os pontos de integração de maior valor operacional e o que cada um entrega ao fluxo do analista.

• Defender XDR: resumo de incidentes, análise de scripts e arquivos, guia de resposta e consultas de caça avançada sobre telemetria de endpoint e identidade.
• Sentinel: assistência na investigação de incidentes e na redação de consultas KQL sobre o analytics workspace do time de segurança.
• Entra: contexto de identidade para casos de comprometimento de conta, consentimento anômalo de aplicativos e mudanças suspeitas de configuração.
• Intune e Purview: apoio em ações de dispositivo e em perguntas de conformidade e proteção de dados que atravessam o caso de segurança.
• Threat intelligence da Microsoft: contexto de atores, campanhas e técnicas ligado aos sinais do próprio ambiente.

3. Capacidades: Resumo de Incidentes, Guia de Resposta e KQL Assistido

O resumo de incidentes é a capacidade de entrada e a mais usada. Sobre um incidente do Defender XDR ou do Sentinel, o copiloto produz narrativa condensada com escopo, contas e ativos afetados, cronologia e mapeamento de técnica ATT&CK, entregando ao analista em segundos o que uma leitura completa de alertas entregaria em meia hora. O guia de resposta acompanha o resumo com passos sugeridos de contenção e remediação, organizados como sequência executável, e o analista mantém a aprovação de cada passo. Esses dois recursos juntos reduzem a distância entre a abertura do incidente e a primeira ação correta, que é exatamente a distância onde a maior parte do dano inicial se acumula.

O KQL assistido é a capacidade com maior impacto em hunting. A caixa de consulta do Advanced Hunting e do Sentinel aceita a descrição da hipótese em linguagem natural e devolve uma consulta KQL candidata, que o analista revisa, ajusta e executa. A qualidade da consulta gerada depende da precisão da descrição, e o erro semântico, a consulta que roda sem erro mas responde outra pergunta, é o risco dominante, o mesmo apontado na nota de Charlotte AI. Por isso a regra da biblioteca se repete: consulta gerada é rascunho, e consulta executada é rascunho revisado.

Outras capacidades complementam o fluxo do caso. A análise de script e de arquivo explica em linguagem o que um trecho ofuscado faz, com a ressalva de que o veredicto final pertence à análise técnica. A geração de relatório monta o primeiro rascunho do documento do incidente a partir da trilha, com formato adequado à gestão e não ao técnico. E as sessões de investigação aberta permitem fazer perguntas de acompanhamento sobre o caso, como buscar outros hosts com o mesmo padrão ou verificar se a conta suspeita tocou outros recursos do tenant.

A ordem de adoção sugerida segue o risco de cada capacidade, e a lista abaixo organiza os recursos da seção por esse critério.

• Resumo de incidente: menor risco, maior uso, com revisão por amostragem.
• KQL assistido: risco semântico controlado pela leitura obrigatória da consulta.
• Guia de resposta: passos sugeridos que exigem aprovação por passo em produção.
• Análise de script: explicação preliminar que nunca substitui sandbox e engenharia reversa.
• Geração de relatório: rascunho para gestão com revisão de conteúdo antes da distribuição.

4. Experiência Embutida versus Portal Autônomo

A escolha entre a experiência embutida e o portal autônomo muda o fluxo de trabalho, e a tabela abaixo resume as diferenças que o SOC sente na operação.

O desenho operacional recomendado usa as duas formas com papéis distintos. A experiência embutida atende a triagem e a resposta, onde o contexto do caso é o gatilho, e o portal atende às perguntas que atravessam produtos, como caças que combinam telemetria de endpoint com sinais de identidade. Separar os papéis evita o uso do portal como fila paralela de triagem, que é o erro de adoção mais comum em times que habilitam as duas formas no mesmo dia.

5. Uso em Triagem e Hunting

Na triagem, o fluxo típico combina resumo e guia de resposta. O incidente abre, o copiloto resume, o analista decide se o caso escala, e o guia indica os primeiros passos com os comandos prontos. Em volume, o ganho aparece na fila de incidentes de baixa complexidade, que são a maioria estatística de qualquer SOC: o resumo permite encerrar ou escalar em minutos, liberando o analista para os casos que exigem investigação de verdade. A limitação a lembrar é que o resumo herda a qualidade da correlação do produto, e incidentes mal agrupados produzem resumos mal agrupados, o que mantém a revisão humana como etapa obrigatória.

No hunting, o KQL assistido encurta o ciclo hipótese, consulta, verificação. O exemplo abaixo mostra o perfil de consulta que uma hipótese de persistência via tarefa agendada criada por processo do Office gera a partir de uma descrição em linguagem natural, com os nomes de campos da telemetria de endpoint da Microsoft.

DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName =~ "winword.exe"
| where FileName in~ ("schtasks.exe", "rundll32.exe", "regsvr32.exe", "powershell.exe")
| project Timestamp, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName

A consulta acima é o tipo de artefato que o copiloto entrega em segundos e que o analista precisa ser capaz de ler. Os campos têm que existir na telemetria coletada, o filtro de processo pai precisa fazer sentido para o ambiente, e o período precisa corresponder à hipótese. O valor do KQL assistido é real, e a nota de metodologia da biblioteca sobre registro de hipótese permanece valiosa: a consulta é o meio, e o resultado precisa voltar para detecção versionada ou para o relatório de caça, seguindo o mesmo circuito das notas de Elastic e Splunk da pasta 02.

A caça com KQL assistido mantém o registro formal de hipótese. A hipótese é descrita antes da consulta, a consulta gerada é anexada ao registro com data e analista, e o resultado, positivo ou negativo, fecha o registro. O copiloto comprime o tempo entre hipótese e execução, mas o registro é o que transforma cada iteração em patrimônio do programa, e não em conversa descartável na console.

6. Limitações, Provisionamento e Custo

As limitações do Security Copilot se dividem em três famílias. As limitações de modelo são as mesmas da categoria: alucinação com fluência, dependência da qualidade do prompt e erro semântico em consultas geradas. As limitações de dados vêm do ecossistema: a resposta é tão boa quanto a telemetria que o tenant coleta, e dados de fora do primeiro partido exigem plugins validados. As limitações de operação são específicas da plataforma: custo por SCU que escala com o uso, disponibilidade regional e requisitos de residência de dados que variam por região, e a necessidade de RBAC bem desenhado, porque o copiloto opera dentro das permissões e um papel excessivamente largo se torna expoente de risco.

O ponto de provisionamento merece atenção no planejamento. A habilitação embutida no Defender XDR inclui uma cota de uso associada aos produtos, e o portal autônomo e os usos mais intensivos consomem SCU provisionadas. Times que ignoram essa mecânica descobrem o gargalo no meio de um incidente, com sessões de investigação limitadas exatamente quando mais precisam delas, e o planejamento correto é dimensionar capacidade para o pico de incidente, e não para a média de uso.

A residência de dados merece verificação documentada antes da habilitação em setores regulados. O processamento dos prompts e a origem dos sinais têm regras regionais que mudam com o tempo, e o programa que opera sob a LGPD ou sob regulação setorial precisa registrar na documentação interna onde o contexto do caso é processado e por quanto tempo é retido. É um exercício de uma reunião com o jurídico que evita um achado de auditoria no pior momento possível.

7. Exemplo de Fluxo de Uso em Incidente

O cenário: um incidente aberto no Defender XDR aponta consentimento anômalo de aplicativo OAuth e criação de regra de encaminhamento em uma caixa corporativa, padrão típico de comprometimento de conta com objetivo de exfiltração de e-mail. O fluxo abaixo descreve o uso do copiloto do início à produção do relatório.

1. Incidente aberto: consentimento OAuth anomalo e regra de caixa criada em conta do financeiro
2. Analista aciona o resumo no incidente: copiloto produz narrativa com escopo, contas e tecnica
3. Narrativa indica conta comprometida, aplicativo consentido e regra de encaminhamento ativa
4. Analista pede guia de resposta: passos sugeridos revogam consentimento e removem a regra
5. Analista pede consulta para cacar outros consentimentos anômalos nos ultimos 14 dias
6. KQL gerado sobre AuditLogs lista consentimentos concedidos no periodo
7. Analista revisa, executa e encontra dois consentimentos adicionais em contas diferentes
8. Acoes de revogacao executadas com aprovacao humana e registradas no caso
9. Relatorio executivo gerado a partir da trilha e revisado antes da distribuicao

A consulta do passo 6 tem o perfil abaixo, sobre a tabela de auditoria do Entra, e o resultado dela transforma um incidente pontual em caça de escopo ampliado.

AuditLogs
| where TimeGenerated > ago(14d)
| where ActivityDisplayName in ("Consent to application", "Add delegated permission grant")
| where Result == "success"
| project TimeGenerated, OperationName, InitiatedBy, TargetResources

O exemplo ilustra a mecânica que a nota de Charlotte AI descreveu de forma equivalente: o copiloto acelera resumo, guia e consulta, e o analista mantém a revisão da consulta, a aprovação das ações e a decisão de escopo. O ganho mensurável no fluxo está nos passos 2 e 6, que comprimem minutos ou horas de leitura e redação em segundos, liberando a atenção do analista para os passos 7 e 8, onde o julgamento decide o resultado do caso.

O passo 4 do fluxo, a regra de encaminhamento criada na caixa comprometida, merece caça própria, porque regras de caixa são o mecanismo de persistência silenciosa do comprometimento de e-mail. A consulta abaixo, ilustrativa, lista criações e alterações de regras de caixa com encaminhamento externo nos últimos 14 dias.

OfficeActivity
| where TimeGenerated > ago(14d)
| where Operation in ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules")
| where Parameters has "ForwardTo" or Parameters has "ForwardingSmtpAddress"
| project TimeGenerated, UserId, ClientIP, Parameters

8. Erros Comuns e Pontos de Atenção

• Consumir o resumo do incidente sem verificar os alertas originais, herdando agrupamentos e interpretações do produto sem revisão.
• Executar KQL gerado sem leitura, aceitando a consulta que roda limpa e responde outra pergunta.
• Habilitar o copiloto para papéis com permissões largas, transformando a ferramenta em amplificador de superexposição.
• Ignorar o consumo de SCU até esgotar a capacidade em pleno incidente, com sessões limitadas no pior momento possível.
• Pressupor residência e retenção de dados sem conferir a configuração regional da organização, tema sensível para setores regulados.
• Esperar cobertura de fornecedores terceiros sem plugins, e concluir que o copiloto é fraco quando o problema é a integração ausente.
• Delegar o veredicto de análise de script ao copiloto, que explica e sugere, mas não substitui a análise técnica em sandbox.
• Pular a revisão do relatório gerado antes da distribuição, entregando à gestão um documento com afirmações não verificadas.
• Usar o portal autônomo como fila paralela de triagem, criando dois registros de verdade para o mesmo incidente.
• Assumir que o copiloto enxerga dados de fornecedores terceiros sem plugin configurado, e escalar casos com base em contexto incompleto.

9. Integração com o Restante da Biblioteca

Dentro da subpasta 05, esta nota é a contraparte do Charlotte AI no ecossistema Microsoft, com as mesmas regras de consumo de rascunho e revisão, e prepara o contraste com o Quarterback AI, que assume execução sob guardas em vez de apenas sugerir. As consultas KQL assistidas conectam diretamente às notas de detecção da pasta 02, e o fluxo de incidente do exemplo mapeia nos passos de detecção, análise e contenção do NIST SP 800-61. Para times com frota mista, a recomendação prática da biblioteca é decidir o copiloto por ecossistema, Charlotte no ambiente dominado por Falcon e Security Copilot no ambiente dominado por Microsoft, e padronizar as regras de verificação igual para os dois, porque o risco de confiança excessiva é da categoria, e não de um fornecedor específico.

A recomendação de adoção é tratar o copiloto como projeto com dono e métricas, e não como recurso a habilitar. Defina o papel mínimo de RBAC para uso, monitore o consumo de SCU desde a primeira semana, institua a amostragem de resumos e consultas e publique para o time as regras de uso, incluindo o que nunca se pergunta ao copiloto e o que nunca se executa sem revisão. O resultado esperado é o mesmo que a nota de Charlotte AI descreve: o tempo recuperado na triagem e na redação reinvestido nas investigações e nas caças que exigem julgamento, que é onde a capacidade humana do SOC tem valor irrecuperável.

O critério de coerência que fecha a nota vale para toda a subpasta: o copiloto acelera a passagem do sinal ao registro, e a qualidade final continua dependendo do que a biblioteca ensina nas notas de base. Consulta correta depende de telemetria coberta, resposta correta depende de processo de IR claro, e auditoria confiável depende de trilha registrada, que são exatamente os assuntos das notas de detecção e de resposta a incidentes. O copiloto que mais valoriza uma biblioteca de estudos é o que devolve o analista a essas notas com pergunta melhor.