CrowdStrike Charlotte AI

Nota da subpasta 05 - Plataformas de IA para Segurança, no Capítulo 24 (Ferramentas e Plataformas Atualizadas).
Trata do Charlotte AI como copiloto de segurança do CrowdStrike: narrativa de incidentes, geração de consultas, triagem automatizada e o papel de acelerador em threat hunting.
Dialoga com as notas de Microsoft Security Copilot 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

A entrada de modelos generativos na operação de segurança criou uma nova categoria de ferramenta, o copiloto de segurança, e o Charlotte AI é a implementação do CrowdStrike nessa categoria. O posicionamento da ferramenta é interno à plataforma Falcon: ela não é um chatbot genérico colado ao produto, e sim uma camada de assistência que atravessa os módulos de detecção, resposta, SIEM e intelligence, usando a telemetria do próprio ambiente como contexto. Esta nota abre a subpasta 05 e estabelece o padrão de análise que as notas seguintes, sobre Security Copilot e Quarterback AI, seguem: capacidades, uso em hunting, limitações e riscos.

O interesse da biblioteca em copilotos não é fashion, é operacional. O gargalo clássico do SOC não é falta de dados, é falta de tempo para interpretar dados, e o copiloto ataca exatamente esse gargalo ao converter em minutos tarefas que consumiam horas: resumir uma cadeia de detecções, traduzir uma hipótese de caça em consulta válida, redigir o primeiro rascunho do relatório do incidente. A contrapartida, confiança excessiva em respostas erradas com aparência de certeza, é o risco central que esta nota trata com o mesmo peso das capacidades.

A nota também cumpre função de vocabulário. Copiloto, nesta subpasta, significa uma camada de assistência que responde sob comando e não executa por conta própria, contraste que a nota de Quarterback AI desenvolve com a posição agêntica. Com esse vocabulário fixado, as comparações entre fabricantes seguem o mesmo eixo, e o leitor compara arquitetura de responsabilidade, e não lista de recursos.

2. O Copiloto dentro da Plataforma Falcon

O Charlotte AI foi anunciado em 2023 e consolidado ao longo de 2024 como camada transversal do Falcon, combinando modelos de linguagem de terceiros com modelos próprios treinados em dados de segurança, incluindo a telemetria e o corpus do Falcon Intelligence. A arquitetura relevante para o analista é a de contexto: as perguntas são respondidas com os dados do tenant, filtrados pelas permissões do usuário que pergunta, e a governança de dados é parte do produto, com isolamento entre clientes e controles sobre o que o modelo pode acessar. Em termos práticos, a qualidade da resposta depende diretamente da qualidade da telemetria que a plataforma coleta, e um ambiente com sensores omissos produz narrativas igualmente omissas.

A capacidade que mais mudou a operação de quem adota é o Charlotte AI Detection Triage, que automatiza a triagem de detecções de alto volume. O serviço classifica detecções, encerra as claramente benignas com justificativa registrada e prioriza o restante, com taxas de acerto publicadas pela fabricante acima da linha de base humana em triagem de volume. O efeito prático no SOC é realocação de atenção: o analista sai da fila de falsos positivos e vai para os casos que exigem julgamento, e é essa realocação, e não a redução de headcount, que a biblioteca considera o critério correto de sucesso.

A arquitetura de modelos merece uma nota de honestidade técnica. O Charlotte AI não é um único modelo, e sim um roteamento entre modelos especializados em segurança e LLMs de terceiros, com os controles de governança na frente do roteamento; para o analista, o que importa é que a resposta citável é sempre a que pode ser verificada na telemetria, e não a que soa mais confiante. Esse critério de verificação é o mesmo em qualquer copiloto da categoria, e por isso ele reaparece em todas as notas desta subpasta.

O acesso ao copiloto é distribuído pelas consoles do Falcon, incluindo Falcon Insight para XDR, Falcon Next-Gen SIEM construído sobre o LogScale e as demais experiências da plataforma. Essa distribuição importa porque o copiloto herda o contexto de cada console: na console de resposta, ele narra incidentes e sugere contenção; no SIEM, ele redige consultas; no intelligence, ele resume campanhas e liga relatórios a técnica do ATT&CK.

• Falcon Insight: narrativa de incidente, guia de resposta e consulta sobre telemetria de endpoint e identidade.
• Falcon Next-Gen SIEM: tradução de linguagem natural para a linguagem de consulta do LogScale e apoio em investigações.
• Falcon Intelligence: resumo de campanha, atores e técnicas ligados ao ambiente do próprio cliente.
• Módulos de nuvem e identidade: contexto de exposição e de credenciais para casos que atravessam o perímetro.
• Experiências de TI e segurança corporativa: apoio em perguntas que cruzam TI com segurança, como inventário e configuração.

A avaliação inicial do copiloto segue um protocolo simples e barato. Escolha dez incidentes encerrados no trimestre, peça ao copiloto o resumo de cada um sem mostrar o resultado humano, e compare a narrativa gerada com o caso real, medindo acerto de escopo, de cronologia e de técnica. O exercício de uma tarde entrega a curva de confiança inicial que nenhuma demonstração de fabricante entrega, e vira evidência documentada para a decisão de escopo de uso.

3. Capacidades: Narrativa de Incidentes, Consultas e Triagem Automatizada

As capacidades de maior valor operacional se organizam em quatro grupos. A narrativa de incidentes converte uma cadeia de detecções correlacionadas em história legível, com linha do tempo, ativos afetados, execução inicial e mapeamento de técnica, entregando ao analista o ponto de partida que antes exigia meia hora de leitura de eventos. A geração de consultas converte linguagem natural na linguagem de consulta da plataforma, reduzindo a barreira de entrada para caças que antes dependiam de quem dominava a sintaxe. A triagem automatizada, descrita acima, opera como primeiro filtro da fila. O guia de resposta sugere os próximos passos técnicos associados à detecção, com comandos e checagens, sempre como proposta e não como execução.

• Narrativa de incidentes: resume a cadeia de detecções em texto com cronologia e técnica ATT&CK, e serve de rascunho direto para o relatório do caso.
• Geração de consultas: traduz a pergunta do analista em consulta da plataforma, acelerando caça e investigação pontual sem consultar manual de sintaxe.
• Triagem automatizada: classifica e encerra detecções benignas com justificativa auditável, mantendo o histórico para amostragem de qualidade.
• Guia de resposta: propõe passos de contenção e remediação associados à detecção, com o papel do humano preservado na aprovação.
• Resumo de intelligence: condensa relatórios de campanha e liga atores, técnicas e IOC ao contexto do próprio ambiente quando aplicável.

O copiloto também redige comunicações internas do caso, como o aviso ao dono do ativo e a nota para o gestor, e é nessa função que o texto fluente com conteúdo vazio aparece com mais força. A regra prática é que todo texto destinado a outra pessoa passa por revisão de conteúdo, e não apenas de forma, porque a fluência do modelo é indistinguível de competência para quem não conhece o caso.

A qualidade da resposta depende diretamente da estrutura da pergunta, e o esqueleto abaixo, com papel, contexto, tarefa, formato e restrições, é o padrão que esta biblioteca recomenda para qualquer copiloto da subpasta. Perguntas sem restrições produzem respostas genéricas, e perguntas sem formato produzem texto que exige retrabalho no momento errado do caso.

Papel: analista de resposta nivel 2 no SOC
Contexto: incidente IR-2025-0183, host WS-FIN-118, janela de 24 horas
Tarefa: resumir a cadeia de deteccoes e propor a proxima acao
Formato: narrativa curta, linha do tempo e mapeamento ATT&CK
Restricoes: nao inventar campos, citar o evento de origem de cada afirmacao

O padrão comum a todas as capacidades é que o copiloto produz rascunhos e propostas, e não verdades. A narrativa precisa ser verificada contra os eventos originais, a consulta precisa ser lida antes de executar, a justificativa da triagem precisa ser amostrada periodicamente e o guia de resposta precisa ser adaptado ao ambiente. Times que institucionalizam essa regra de consumo colhem o ganho de velocidade sem herdar os erros do modelo.

4. Uso em Threat Hunting

No hunting, o Charlotte AI funciona como acelerador do ciclo hipótese, consulta, verificação. A hipótese continua nascendo do analista, a partir de relatório de CTI, de padrão de telemetria ou de pivô de IOC, e o copiloto encurta o trecho mecânico do ciclo, que é traduzir a hipótese em consulta correta e iterar sobre o resultado. O ganho maior aparece para o analista júnior, que consegue escrever caças plausíveis sem dominar a sintaxe, e para o sênior, que economiza o tempo de lembrar nomes de campos e operadores e gasta o tempo na interpretação.

O exemplo abaixo, ilustrativo, mostra o tipo de consulta que a caça por execução suspeita de office gera a partir de uma pergunta em linguagem natural. A sintaxe segue a linguagem do LogScale usada no Falcon Next-Gen SIEM, e os nomes de campos podem variar por versão e por fonte de dados, razão pela qual a consulta gerada deve sempre ser revisada.

#event_simpleName=ProcessRollup2 event_platform=Win
| FileName=/^(rundll32|regsvr32|mshta)\.exe$/i
| in(field="ParentBaseFileName", values=["winword.exe", "excel.exe", "outlook.exe"])
| groupBy([ComputerName, FileName], function=[count()])

A disciplina metodológica permanece do lado humano. As notas de metodologia de hunting da biblioteca, construídas sobre PEAK e TaHiTI, insistem que a caça começa com hipótese registrada e termina com resultado alimentando detecção ou relatório, e o copiloto não muda esse contrato. O que ele muda é a taxa de iteração: hipóteses que exigiam meia hora de construção de consulta passam a ser testadas em minutos, e o limite do programa passa a ser a qualidade das perguntas, e não a velocidade de digitação.

Na prática, a caça com copiloto mantém o registro formal de hipótese. A hipótese é escrita 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.

Há ainda um uso secundário que merece registro: a revisão crítica da consulta gerada é, ela mesma, exercício de aprendizado. O analista júnior que compara a consulta proposta com a que escreveria manualmente absorve nomes de campos, operadores e padrões de agregação da linguagem, e o copiloto funciona como tutor implícito. A condição é não pular a comparação, porque o atalho sem leitura produz dependência sem aprendizado.

5. Limitações e Riscos: Confiança Excessiva

O risco dominante do copiloto é a confiança excessiva, e ele tem uma mecânica específica que o torna mais perigoso que o erro comum de ferramenta. O modelo erra com fluência, produzindo narrativas plausíveis, consultas sintaticamente corretas e semanticamente erradas e generalizações sobre o ambiente que ninguém verificou, tudo em texto bem escrito que transmite autoridade. O analista cansado, sob pressão de incidente, é o consumidor ideal desse tipo de erro, e por isso a mitigação precisa ser processual, e não apenas uma nota de rodapé sobre IA.

Duas limitações técnicas merecem registro direto. A primeira é que o copiloto não substitui a engenharia de detecção: regra bem escrita, testada e versionada continua sendo o ativo que protege a frota, e o copiloto acelera o caminho até ela, mas não a substitui. A segunda é que a resposta do modelo depende do contexto disponível no tenant, e perguntas sobre o que a plataforma não coleta produzem respostas confiantes sobre dados inexistentes, o que reforça a necessidade de caças de cobertura que as notas de telemetria da biblioteca descrevem.

A amostragem de fechamentos automáticos merece método específico. Uma amostra semanal de cinco a dez por cento dos encerramentos, revisada por um segundo analista e registrada com veredito de concordância ou discordância, produz a curva de qualidade que o programa precisa. Discordâncias recorrentes concentradas em um tipo de detecção são o sinal de que a regra de triagem automática daquele tipo deve ser suspensa até revisão.

O custo de licenciamento e o consumo do copiloto variam por pacote e mudam rápido o suficiente para não caber em nota de biblioteca. O que cabe é o critério: o ganho medido nas métricas de triagem e de caça precisa pagar a conta, e a medição precisa existir antes da expansão de uso. Copiloto sem linha de base medida é despesa com aparência de capacidade.

6. Uso Recomendado por Tarefa: Onde o Copiloto Ajuda e Onde Atrapalha

A decisão de onde usar o copiloto se faz por tarefa, e não por entusiasmo com a ferramenta. A tabela abaixo consolida o padrão de operação, com a contribuição do copiloto e o papel que o humano mantém em cada tarefa, e serve de guia para a adoção incremental que a nota recomenda.

O padrão da tabela é o mesmo em todas as linhas: o copiloto comprime o trecho mecânico, e o humano preserva o julgamento. As tarefas com contribuição de rascunho, resumo e consulta, são de adoção imediata; as tarefas em que o erro tem consequência direta em produção, contenção e veredicto técnico, são de adoção tardia, com processo de revisão maduro e registro de quem aprovou.

A tabela também funciona como contrato de treinamento. O analista novo aprende a usar o copiloto começando pelas linhas de cima, com revisão sistemática, e só desce para as linhas de decisão quando a revisão dele já captura os erros típicos do modelo. Em programas sem esse degrau, a ferramenta chega antes da disciplina, e o resultado é a confiança excessiva que a seção anterior descreveu.

7. Exemplo de Interação Típica Descrita

O cenário: uma sequência de detecções de execução suspeita acende em um host do setor financeiro, e o analista de turno precisa decidir em minutos se o caso escala. A interação abaixo descreve o padrão típico de uso, passo a passo, com o papel de cada lado.

1. Entrada: sequencia de deteccoes de execucao suspeita no host WS-FIN-118
2. Analista pergunta: resuma a atividade suspeita nas ultimas 24 horas e proponha a proxima acao
3. Copiloto correlaciona os eventos e devolve narrativa com linha do tempo e tecnica ATT&CK
4. Narrativa aponta documento do Office que lancou powershell com linha ofuscada e tocou IP externo
5. Analista pergunta: gere a consulta para cacar o mesmo padrao em toda a frota nos ultimos 7 dias
6. Copiloto devolve consulta com filtro de processo pai e filho, pronta para revisao
7. Analista le a consulta, executa e encontra mais dois hosts com o mesmo padrao
8. Copiloto sugere contencao por isolamento de rede dos tres hosts, com justificativa
9. Analista aprova a contencao, anexa narrativa e consulta ao caso e escala para o IR

O detalhe que faz a interação funcionar está nos passos 6 e 9. No passo 6, o copiloto entrega rascunho e o analista exerce a função de revisor, o que evita a falha semântica silenciosa de consulta errada rodando com sucesso. No passo 9, a ação de contenção permanece sob aprovação humana, e o copiloto não executa nada por conta própria, o que é a fronteira que separa copiloto de agente, tema que a nota de Quarterback AI desta subpasta desenvolve em contraste direto.

Vale registrar o que a interação não mostra. O copiloto não descobriu o padrão sozinho, ele condensou detecções que o produto já tinha correlacionado, e a qualidade da narrativa reflete a qualidade do agrupamento do incidente. Em incidentes mal agrupados, o mesmo prompt devolve narrativa confusa, e a resposta correta é corrigir o agrupamento no produto, e não insistir no prompt até o texto parecer claro.

A leitura do fluxo por tarefa confirma a tabela da seção anterior: o copiloto dominou o trecho mecânico, e o analista manteve a revisão da consulta, a autorização da contenção e a decisão de escala. O caso fechou em minutos com narrativa verificável anexada, e a consulta do passo 7 virou detecção versionada no SIEM, que é o destino correto de toda caça que confirma hipótese.

8. Erros Comuns e Pontos de Atenção

• Consumir a narrativa do incidente sem verificar os eventos originais, propagando a interpretação do modelo para o relatório e para a decisão.
• Executar consultas geradas sem leitura prévia, aceitando a combinação perigosa de sintaxe correta e semântica errada.
• Automatizar fechamento de detecções sem amostragem periódica dos resultados, deixando o erro sistemático invisível por semanas.
• Perguntar ao copiloto o que a telemetria não cobre e tratar a resposta confiante como fato, em vez de tratar como indício de gap de cobertura.
• Colar dados sensíveis de outros contextos nas perguntas, contornando a governança que a plataforma oferece e cria obrigações.
• Medir o sucesso do copiloto por número de interações, e não por métricas de resultado como tempo de triagem e taxa de acerto de fechamento.
• Deixar de treinar caças manuais periódicas, criando dependência total da ferramenta e erosão silenciosa de habilidade do time.
• Esperar que o copiloto execute contenção por conta própria, confundindo a fronteira do copiloto com a de um agente autônomo.
• Usar o copiloto como buscador de documentação durante incidente, gastando a janela crítica em perguntas que a fonte oficial responde melhor.
• Permitir prompts livres colando dados de outros casos no contexto, criando exposição que a governança da plataforma não cobre.

9. Integração com o Restante da Biblioteca

Dentro do Capítulo 24, esta nota estabelece o modelo copiloto que as notas seguintes contrastam: o Security Copilot implementa a mesma ideia no ecossistema Microsoft, com forças próprias em resumo de incidentes e KQL assistido, e o Quarterback AI ocupa a posição à direita no espectro de autonomia, executando cadeias de ação sob guardas em vez de apenas sugerir. Fora da subpasta, as consultas geradas pelo Charlotte pousam no contexto das notas de Elastic, Wazuh e Splunk da pasta 02, que tratam da engenharia de detecção onde o resultado da caça se transforma, e as narrativas de incidente alimentam os casos de IR estruturados segundo o NIST SP 800-61. As metodologias de hunting da biblioteca, com PEAK e TaHiTI, permanecem o quadro em que o copiloto opera, com a hipótese humana no centro e o modelo acelerando o trecho mecânico do ciclo.

A recomendação de adoção é começar pelas duas capacidades de menor risco e maior retorno mensurável, que são a triagem automatizada com amostragem de qualidade e a geração de consultas com revisão obrigatória, e só depois expandir para narrativa de incidentes em relatórios formais. Meça desde a primeira semana o tempo médio de triagem e a taxa de acerto dos fechamentos automáticos, trate esses números como linha de base e exija que qualquer expansão do uso do copiloto justifique o ganho sobre eles. É com essa disciplina de medição que o copiloto se mantém na posição correta, acelerador do analista, e não fonte paralela de verdade que ninguém audita.

Um último critério une esta nota às demais da subpasta: o copiloto não muda o destino do resultado, apenas a velocidade do caminho. A consulta de caça que confirma hipótese precisa virar regra versionada, a narrativa precisa entrar no caso formal, e o IOC precisa alcançar o TIP, destinos que as notas de SIEM e de TIP da biblioteca tratam em detalhe. Times que medem o copiloto por número de interações perdem de vista esse destino, e é por ele que a ferramenta deve ser cobrada.