Professional Security Operations Engineer — Übungsfragen und Probeprüfung

Der Health Hub zeigt das 95. Perzentil der Differenz zwischen Last Event Time (wann das Event an der Quelle aufgetreten ist) und Last Ingested (wann SecOps es empfangen hat). Eine hohe Differenz deutet auf Latenz innerhalb der Ingestion-Pipeline von SecOps hin, während eine normale Differenz darauf hindeuten kann, dass die Quelle ältere oder historische Daten liefert (Quelle: docs.cloud.google.com/chronicle/docs/reports/data-health-monitoring-and-troubleshooting-dashboard). Diese Metrik beantwortet direkt, ob die Verzögerung bei der Ingestion ein Pipeline-Problem oder ein Problem auf Seiten der Quelle ist. Warum nicht die anderen? Die Zahl der Total Ingested Logs misst Volumen, nicht Latenz. Config Last Updated hilft dabei, Konfigurationsänderungen mit Fehlern zu korrelieren, misst aber keine Verzögerung. Parser-Fehler pro Stunde zeigen den Zustand des Parsings, nicht das Timing der Ingestion. Die Differenz zwischen Last Event Time und Last Ingested ist die eindeutige Diagnose für Latenz.

In YARA-L 2.0 werden Nullwerte (leere Strings, 0, false) NICHT automatisch für alle Felder gefiltert. Die Rules Engine filtert Nullwerte implizit nur für Platzhalter im match-Abschnitt; andere Event-Felder musst du explizit mit != "" ausschließen (Quelle: docs.cloud.google.com/chronicle/docs/detection/yara-l-best-practices). Ohne $e.principal.user.userid != "" stehen weggelassene userid-Felder standardmäßig auf "" und erzeugen falsch positive Treffer. Das ist eine dokumentierte Best Practice, um False Positives zu reduzieren. Warum nicht die anderen? Die automatische Filterung gilt NICHT generell — nur Platzhalter im match-Abschnitt bekommen den impliziten Ausschluss von Nullwerten (Quelle: docs.cloud.google.com/chronicle/docs/yara-l/match-syntax). Ein Feld in den outcome-Abschnitt zu verschieben verhindert nicht, dass in events auf leere Werte gematcht wird. Der Modifier nocase ändert die Groß-/Kleinschreibungsempfindlichkeit, nicht den Umgang mit Nullwerten.

Um den Ausfall einer Log-Quelle zu erkennen, legst du in Cloud Monitoring eine Alerting-Policy an, die die Metrik Chronicle Collector > Ingestion > Total ingested log count (oder Total ingested log size) mit einer Bedingung vom Typ Metric absence verwendet. Sie löst aus, wenn über eine festgelegte Dauer keine Daten eingehen (Quelle: docs.cloud.google.com/chronicle/docs/ingestion/ingestion-notifications-for-health-metrics). Das dokumentierte Setup: die Ingestion-Metrik auswählen, nach collector_id gruppieren, das Rolling window auf bis zu 1 Stunde setzen und Metric absence als Bedingungstyp mit einer Trigger-Absence-Zeit konfigurieren. Warum nicht die anderen? Der Pub/Sub-Backlog überwacht die Queue-Tiefe, nicht die SecOps-spezifische Ingestion. Eine auf null fallende CPU-Auslastung der Compute Engine ist unzuverlässig und zeigt nicht direkt an, dass der Log-Fluss steht. Cloud Logging-Einträge pro Sekunde messen den Durchsatz von Cloud Logging, nicht speziell den Zustand der Ingestion in SecOps.