APRENDER. PRATICAR. EVOLUIR.Define o contrato antes da query
Num serviço fictício de fundos, o SOC recebe eventos de autenticação através de uma fila. O analista quer correlacionar falhas com um sucesso posterior. Antes de contar linhas, identifica o produtor, o tenant, a identidade estável do utilizador, o identificador do evento, o resultado e os dois tempos disponíveis. Um nome apresentado no ecrã pode mudar ou existir em vários tenants. Uma linha recebida também pode ser apenas uma nova entrega de um evento antigo. No laboratório, o parser exige strings não vazias, um resultado conhecido e timestamps com offset explícito. Três entradas inválidas ficam em quarentena com o motivo; não são convertidas silenciosamente em sucessos ou falhas. Esta é uma política didática escolhida para os dados sintéticos, não um contrato universal de qualquer fornecedor.
Evento distinto e entrega repetida
Delta tem uma única falha entregue três vezes antes do sucesso. A query sobre linhas brutas atinge o limiar de três; a query sobre eventos distintos não o atinge. A identidade do evento tem de respeitar o âmbito do produtor: dois sistemas podem emitir o mesmo número local sem se referirem ao mesmo acontecimento. O laboratório conserva três IDs diferentes no mesmo segundo e o mesmo ID local em três fontes distintas. Remover duplicados apenas pelo timestamp destruiria atividade legítima. O agrupamento do exemplo elimina cópias com o mesmo payload normalizado e conserva a primeira observação. Payloads contraditórios com o mesmo ID exigiriam uma política adicional; não se deve escolher silenciosamente a versão mais conveniente. Guarda também contagens de entregas e rejeições para diagnosticar a ingestão.
A cronologia tem mais de um relógio
O tempo do evento descreve o que o relógio de origem registou; o tempo observado descreve quando o ponto de recolha o viu. Um timestamp observado por um collector não é necessariamente a hora final de indexação no SIEM. No caso late, as falhas ocorreram antes do sucesso mas chegaram muito depois. Aos 100 segundos ainda não sustentam o alerta; uma análise retrospetiva após a chegada já as encontra. Correlacionar só pelo tempo observado coloca essas falhas depois do sucesso e perde a sequência. Não apagues o tempo original para fazer a regra funcionar. Conserva os dois tempos, a origem e a interpretação usada. Define ainda uma política de reprocessamento e de alertas repetidos; o simples replay integral do laboratório não implementa essas funções de produção.
Qualidade temporal e âmbito da identidade
No caso clock, três falhas têm tempo de origem posterior à observação. Essa latência negativa justifica investigar relógios, parsing e transformação; não prova adulteração. Normalizar um offset explícito para UTC resolve a representação, mas não corrige um relógio errado. A janela didática inclui exatamente os 300 segundos anteriores ao sucesso; 301 segundos ficam fora. Testar a fronteira evita discutir resultados sem definir inclusividade. Noutro caso, falhas do utilizador shared em funds-a são combinadas com um sucesso em funds-b quando o join usa apenas o nome. A correção mantém tenant e identidade no predicado. Acrescentar mais fontes só aumenta a confiança se a equipa souber como relacionar as identidades e medir a qualidade dos tempos.
Prática e entrega à operação
Executa o script e explica primeiro a diferença entre raw e events. Prevê o resultado de retirar o tenant e de trocar event_time por observed_time. Confirma quais os casos que mudam e porquê. Depois testa o que o pipeline publica: JSON deve preservar uma string com quebra de linha sem fabricar outro registo físico, e o token sintético fica excluído por uma lista explícita de campos. Isso não valida todos os consumidores de logs nem todos os tipos de segredo. Para entregar o serviço a APS, regista versão do parser, chaves de correlação, relógio escolhido, atrasos conhecidos, rejeições, retenção e procedimento de replay. A ausência de alerta num dispositivo sem telemetria tem de aparecer como lacuna de cobertura, não como prova de segurança.
# Original local exercise, no network or production logs:
python3 content/labs/securityx-detection-evidence/run.py \
--output /tmp/securityx-detection.json
# Compare completeAlerts with earlyAlerts and inspect quarantined.
# Source time and observation time are retained separately.
Três entregas da mesma falha parecem três tentativas. A desduplicação correta retira o alerta de delta; um join sem tenant cria outro alerta indevido.
Armadilhas comuns
Contar linhas como tentativas; desduplicar só pela hora; juntar nomes entre tenants; substituir o relógio sem registo; ocultar eventos rejeitados.
Tópicos relacionados: Deteção e qualidade · Resposta a incidentes
A correlação depende de eventos identificáveis, tempo interpretável e cobertura observável.
Referência: OWASP Logging Cheat Sheet · CAS-005 / SecurityX V5; objectives 3.0; launched 2024-12-17