Professional Security Operations Engineer — Questões de prática e simulado

O Health Hub expõe o percentil 95 da diferença entre Last Event Time (quando o evento ocorreu na fonte) e Last Ingested (quando o SecOps o recebeu). Uma diferença alta sugere latência dentro do pipeline de ingestão do SecOps, enquanto uma diferença normal pode indicar que a fonte está enviando dados mais antigos ou históricos (ref.: docs.cloud.google.com/chronicle/docs/reports/data-health-monitoring-and-troubleshooting-dashboard). Essa métrica responde diretamente se o atraso na ingestão é um problema do pipeline ou da fonte. Por que não as outras? A contagem de Total Ingested Logs mede volume, não latência. Config Last Updated ajuda a correlacionar mudanças de configuração com falhas, mas não mede atraso. Erros de parser por hora indicam a saúde do parsing, não o timing da ingestão. A diferença entre Last Event Time e Last Ingested é o diagnóstico definitivo de latência.

No YARA-L 2.0, valores zero (strings vazias, 0, false) NÃO são filtrados automaticamente em todos os campos. O Rules Engine filtra valores zero implicitamente apenas para os placeholders da seção match; os demais campos de evento exigem exclusão explícita com != "" (ref.: docs.cloud.google.com/chronicle/docs/detection/yara-l-best-practices). Sem $e.principal.user.userid != "", os campos userid omitidos assumem "" por padrão e geram correspondências falso-positivas. Essa é uma boa prática documentada para reduzir falsos positivos. Por que não as outras? A filtragem automática NÃO vale para tudo — só os placeholders da seção match recebem a exclusão implícita de valores zero (ref.: docs.cloud.google.com/chronicle/docs/yara-l/match-syntax). Mover um campo para a seção outcome não impede a correspondência com valores vazios em events. O modificador nocase muda a sensibilidade a maiúsculas e minúsculas, não o tratamento de valores nulos.

Para detectar falhas em fontes de logs, crie uma política de alertas no Cloud Monitoring usando a métrica Chronicle Collector > Ingestion > Total ingested log count (ou Total ingested log size) com uma condição do tipo Metric absence. Ela dispara quando nenhum dado é recebido por uma duração determinada (ref.: docs.cloud.google.com/chronicle/docs/ingestion/ingestion-notifications-for-health-metrics). A configuração documentada: selecione a métrica de ingestão, agrupe por collector_id, defina a Rolling window em até 1 hora e configure Metric absence como tipo de condição, com um tempo de ausência para o disparo. Por que não as outras? O backlog do Pub/Sub monitora a profundidade da fila, não a ingestão específica do SecOps. A CPU do Compute Engine cair a zero é pouco confiável e não indica diretamente a parada do fluxo de logs. Entradas por segundo do Cloud Logging medem o throughput do Cloud Logging, não especificamente a saúde da ingestão do SecOps.