Die Ereignisanzeige zeigt eine Klartextbeschreibung, SCOM sieht XML mit Codes und nummerierten Parametern. Wer das versteht, baut zuverlässige Ereignisregeln – auch für Security-Monitoring.
Viele Unternehmen betrachten Operations Manager als reine Alarmierungssoftware: Gesammelt wird nur, was auch alarmiert werden soll. Mit dem gestiegenen Sicherheitsbewusstsein rücken aber auch das Sammeln und Auswerten von Ereignissen in den Fokus. Dabei stolpern Einsteiger – und nicht nur die – immer wieder über dieselben drei Fallstricke.
Fallstrick 1: Mensch und Maschine sehen unterschiedliche Ereignisse
Die Ereignisanzeige (eventvwr) ist für Menschen gemacht. Sie zeigt eine aufbereitete Beschreibung mit Klartext. SCOM dagegen arbeitet mit der XML-Darstellung des Ereignisses.
Beispiel Ereignis 4624 (erfolgreiche Anmeldung): In der Ansicht steht beim Feld Identitätswechselebene ein lesbarer Wert. Im XML steht stattdessen ein Platzhalter-Code wie %%1832.
Eine Regel, die in der Beschreibung nach dem Klartext sucht, wird deshalb nie auslösen. Prüfen Sie Filterwerte immer in der Registerkarte Details › XML-Ansicht.
Fallstrick 2: Die Ereignisquelle ist eine andere als gedacht
Ein weiteres Szenario aus unseren Trainings: Die angezeigte Quelle entspricht nicht dem Wert, den SCOM erwartet – etwa weil im XML der vollständige Providername steht (z. B. Microsoft-Windows-Security-Auditing) statt einer Kurzform.
Kein komplexer Fehler, aber einer, der Stunden kosten kann. Auch hier hilft der Blick in die XML-Ansicht: Maßgeblich ist das Attribut Name im Element Provider.
Fallstrick 3: Auf die Beschreibung filtern
SCOM bietet standardmäßig keine Möglichkeit, die komplette Ereignisbeschreibung als Kriterium zu verwenden – und das aus gutem Grund: Textvergleiche über die gesamte Beschreibung sind ineffizient und sollten vermieden werden. Fast alle Ereignisse sind parametrisiert. Diese Parameter nutzen Sie gezielt.
Beispiel Ereignis 4634 (Abmeldung): Die Daten liegen im XML unter EventData als benannte Felder.
SCOM spricht diese Felder über ihre Position an: TargetUserSid ist Parameter 1, TargetUserName ist Parameter 2. In der Regel filtern Sie dann zum Beispiel auf:
| Parametername | Operator | Wert |
|---|---|---|
Params/Param[2] | Gleich | svc_backup |
EventDisplayNumber | Gleich | 4634 |
Die Position ermitteln Sie, indem Sie im XML die Felder unter EventData durchzählen – oder mit Werkzeugen wie Log Parser bzw. PowerShell (Get-WinEvent liefert die Werte über .Properties[n], wobei die Zählung dort bei 0 beginnt).
Tipp
Testen Sie Filterkriterien zuerst mit PowerShell: Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4634} -MaxEvents 5 | ForEach-Object { $_.Properties[1].Value } zeigt Ihnen sofort, welcher Wert im zweiten Parameter steht.
Heute
Diese Grundlagen gelten in allen Operations-Manager-Versionen. Für umfangreiches Security-Monitoring mit hohen Ereignisvolumina eignen sich allerdings spezialisierte Lösungen besser: die Audit Collection Services (ACS) von SCOM, Windows Event Forwarding oder ein SIEM wie Microsoft Sentinel. SCOM bleibt ideal für gezielte Alarme auf einzelne sicherheitsrelevante Ereignisse.