Active Directory Sicherheit Teil 3: Audit Policy und Event Monitoring

Teil 3 meiner Serie Active Directory Sicherheit beschäft sich mit der Audit Policy und dem Event Monitoring zur Erkennung von möglichen Angriffsversuchen.

Audit Policy Settings

Eine Policy zum Audit von sicherheitsrelevanten Vorgängen im AD sollte für jedes Computer Objekt implementiert sein. Schadsoftware breitet sich oftmals von Clients aus, sodass auch diese im Audit-Scope sind. Dementsprechend ist eine Group Policy zu konfigurieren und allen OUs mit Computer Objekten zuzuweisen.

  • Computer Configuration\Policies\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Account Logon\
    • Audit Credential Validation: Success & Failure
  • Computer Configuration\Policies\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Account Management\
    • Audit Application Group Management: Success & Failure
    • Audit Computer Account Management: Success & Failure
    • Audit Other Account Management Events: Success & Failure
    • Audit Security Group Management: Success & Failure
    • Audit User Account Management: Success & Failure
  • Computer Configuration\Policies\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Detailed Tracking\
    • Audit PNP Activity: Success
    • Audit Process Creation: Success
  • Computer Configuration\Policies\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Logon/Logoff\
    • Audit Account Lockout: Success & Failure
    • Audit Group Membership: Success
    • Audit Logoff: Success
    • Audit Logon: Success & Failure
    • Audit Other Logon/Logoff Events: Success & Failure
    • Audit Special Logon: Success
  • Computer Configuration\Policies\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Object Access\
    • Audit Removable Storage: Success & Failure
  • Computer Configuration\Policies\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Policy Change\
    • Audit Policy Change: Success & Failure
    • Audit Authentication Policy Change: Success
    • Audit Authorization Policy Change: Success
  • Computer Configuration\Policies\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Privilege Use\
    • Audit Sensitive Privilege Use: Success & Failure
  • Computer Configuration\Policies\Windows Settings\Security Settings\Advanced Audit Policy Configuration\System\
    • Audit IPsec Driver: Success & Failure
    • Audit Other System Events: Success & Failure
    • Audit Security State Change: Success & Failure
    • Audit Security System Extension: Success & Failure
    • Audit System Integrity: Success & Failure
Event Monitoring

Jetzt wo wir mir Hilfe der Audit Policy entsprechende Log-File Einträge generieren, ist der nächste Schritt, diese auch auszuwerten. Um Event Logs sinnvoll auszuwerten, kommt man um eine professionelle SIEM Lösung kaum herum und besonders kleine Firmen scheuen die Kosten. Trotzdem gehe ich im Folgenden etwas näher darauf ein, da es für diese Zielgruppe kostengünstige Alternativen gibt.

Die mit der Audit Policy generierten AD Events sollten regelmäßig (wöchentlich) analysiert werden, um Kompromitierungen und Abnormalitäten im Domain Netzwerk zu erkennen.

Hier mal ein paar typische Beispiele für Indikatoren von Angriffsversuchen:

  • Änderungen an hoch privilegierten AD Gruppen (Enterprise Admins, Domain Admins und Schema Admins)
  • Anzahl gesperrter User Accounts
  • Anzahl fehlgeschlagener Anmeldeversuchen
  • Anzahl von Account Sperrungen
  • Aktivitäten privilegierter Benutzer
  • Logon/Logoff Events
  • Nutzung lokaler Administrator Konten

Stellt sich die Frage, wie man die Masse an Events auswertet? Wie oben schon erwähnt, kommt man in großen Firmen um eine professionelle SIEM Lösung zur zentralen Log Analyse nicht herum. Beispiele für solche Lösungen sind Splunk, ManageEngine ADAudit Plus und RSA NetWitness.

In kleineren Unternehmen, die für solch eine Implementierung keine Budget haben, gibt es zumindest die Möglichkeit, Windows Event Forwarding (WEF) zu nutzen und auf einem zentralen Server bereitzustellen. Details dazu findet ihr hier, daher möchte ich nur kurz darauf eingehen, was WEF ist – und was nicht.

WEF ist eine Builtin Möglichkeit, mittels sog. Subscriptions die Events eines Windows Computers an die Event Logs eines anderen Windows Server, den sog. Windows Event Collector (WEC) weiterzuleiten.
Das ist dann auch schon die große Einschränkung, denn z.B. ein zentrales Logging von Nicht-Windows System (Switches, Firewalls, etc.) wie bei SIEM Lösungen ist nicht möglich. Wem Windows Logging jedoch ausreicht, hat hiermit zumindest schon mal eine Basis für ein zentrales Security Event Management.
Auch sonst gibt es noch ein paar kleine Einschränkungen, die in o.g. Artikel erläutert werden, aber im realen Leben sind diese meiner Meinung nach irrelevant. Bis man z.B. WEF Client Limits oder WEF Event Limits erreicht, sollte man definitiv schon lange das Budget für eine SIEM Lösung in die Hand genommen haben.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.