Professional Security Operations Engineer — Questions d'entraînement et examen blanc

Le Health Hub expose le 95e centile de l'écart entre Last Event Time (le moment où l'événement s'est produit à la source) et Last Ingested (le moment où SecOps l'a reçu). Un écart élevé suggère une latence dans le pipeline d'ingestion de SecOps, tandis qu'un écart normal peut indiquer que la source envoie des données plus anciennes ou historiques (réf. : docs.cloud.google.com/chronicle/docs/reports/data-health-monitoring-and-troubleshooting-dashboard). Cette métrique répond directement à la question de savoir si le retard d'ingestion vient du pipeline ou de la source. Pourquoi pas les autres ? Le nombre de Total Ingested Logs mesure le volume, pas la latence. Config Last Updated aide à corréler les changements de configuration avec les pannes, mais ne mesure pas le retard. Les erreurs de parseur par heure indiquent la santé du parsing, pas le timing de l'ingestion. L'écart entre Last Event Time et Last Ingested est le diagnostic de latence définitif.

En YARA-L 2.0, les valeurs nulles (chaînes vides, 0, false) ne sont PAS filtrées automatiquement pour tous les champs. Le Rules Engine ne filtre implicitement les valeurs nulles que pour les placeholders de la section match ; les autres champs d'événement exigent une exclusion explicite avec != "" (réf. : docs.cloud.google.com/chronicle/docs/detection/yara-l-best-practices). Sans $e.principal.user.userid != "", les champs userid omis prennent la valeur "" par défaut et créent des correspondances faussement positives. C'est une bonne pratique documentée pour réduire les faux positifs. Pourquoi pas les autres ? Le filtrage automatique ne s'applique PAS partout — seuls les placeholders de la section match bénéficient de l'exclusion implicite des valeurs nulles (réf. : docs.cloud.google.com/chronicle/docs/yara-l/match-syntax). Déplacer un champ vers la section outcome n'empêche pas les correspondances sur les valeurs vides dans events. Le modificateur nocase change la sensibilité à la casse, pas la gestion des valeurs null.

Pour détecter la panne d'une source de logs, crée une règle d'alerte Cloud Monitoring qui utilise la métrique Chronicle Collector > Ingestion > Total ingested log count (ou Total ingested log size) avec une condition Metric absence. Elle se déclenche quand aucune donnée n'est reçue pendant une durée définie (réf. : docs.cloud.google.com/chronicle/docs/ingestion/ingestion-notifications-for-health-metrics). La configuration documentée : sélectionne la métrique d'ingestion, regroupe par collector_id, règle la Rolling window sur 1 heure au maximum et choisis Metric absence comme type de condition, avec un délai d'absence de déclenchement. Pourquoi pas les autres ? Le backlog Pub/Sub surveille la profondeur de file, pas l'ingestion propre à SecOps. Une CPU Compute Engine qui tombe à zéro n'est pas fiable et n'indique pas directement l'arrêt du flux de logs. Les entrées par seconde de Cloud Logging mesurent le débit de Cloud Logging, pas spécifiquement la santé de l'ingestion SecOps.