IT-Sicherheitsmonitoring

Ein wirksames IT-Sicherheitsmonitoring erkennt verdächtige Aktivitäten, bevor daraus ein meldepflichtiger Vorfall oder ein Notbetrieb wird. Diese Seite richtet sich an Kommunalverwaltungen und ihre IT-Dienstleister und beschreibt nicht nur Detektionsregeln, sondern den gesamten Rahmen – von der Rechtsgrundlage über das Betriebsmodell bis zu konkreten Schwellenwerten.

Die Empfehlungen orientieren sich an BSI IT-Grundschutz (insbesondere DER.1, OPS.1.1.5, DER.2.1), am BSI-Mindeststandard zur Protokollierung und Detektion (v2.1), am IT-Grundschutz-Profil Basis-Absicherung Kommunalverwaltung (koBA v4.0) sowie an den landesrechtlichen IT-Sicherheits- und Datenschutzgesetzen und den Angeboten der Landes-CERTs. Ergänzend wird auf DIN/ISO (27001/27002/27035) und OWASP Bezug genommen.

Einordnung: Der Use-Case-Katalog in Abschnitt 6 ist ein priorisierter Detektionskatalog. Er ergänzt ein Sicherheitsmonitoring-Konzept, ersetzt dieses aber nicht. Erst zusammen mit Betriebsmodell (Abschnitt 3), Datenschutzrahmen (Abschnitt 4) sowie Verantwortlichkeiten, Reaktion und Wirksamkeitsmessung (Abschnitt 7) wird daraus ein betreibbares und auditierbares Monitoring.

1. Regulatorischer und organisatorischer Rahmen

Maßgebliche Grundlagen im Überblick

• BSI IT-Grundschutz: Baustein DER.1 „Detektion von sicherheitsrelevanten Ereignissen“, ergänzt um OPS.1.1.5 „Protokollierung“ und DER.2.1 „Behandlung von Sicherheitsvorfällen“.
• BSI-Mindeststandard zur Protokollierung und Detektion von Cyberangriffen, Version 2.1 (11.11.2024): Orientierung Speicherfrist 90 Tage; sicherheitsrelevante Ereignisse ohne Personenbezug und Cyberangriffe können davon ausgenommen werden; Infrastruktur für die doppelte Speicherfrist dimensionieren.
• IT-Grundschutz-Profil „Basis-Absicherung Kommunalverwaltung“ (koBA v4.0, 2023) und das Einstiegsprojekt WiBA („Weg in die Basis-Absicherung“) – pragmatische Einstiegsrahmen für Kommunen.
• NIS2UmsuCG / BSIG-neu (in Kraft seit 06.12.2025): Risikomanagement nach § 30 BSIG, Meldepflichten 24 h / 72 h / 1 Monat – relevant für betroffene kommunale Einheiten.
• Landesrechtlicher Rahmen: Landesspezifische IT-Sicherheits-, E-Government- und Datenschutzgesetze regeln u. a. die Auswertung des Datenverkehrs kommunaler Netze und definieren die zuständigen Aufsichts- und Unterstützungsstellen.
• Anlaufstellen: Landes-CERTs/CSIRTs, kommunale Spitzenverbände, kommunale IT-Dienstleister und Zweckverbände bieten typischerweise Lagebilder, Notfall-Hotlines, Leak-Checker, Pentest-Programme und Incident-Response-Unterstützung.
• Frameworks: MITRE ATT&CK (Taktiken/Techniken), CIS Controls v8 (insbesondere Control 8 „Audit Log Management“ und Control 13 „Network Monitoring & Defense“).

2. Monitoring ist mehr als eine Regelliste – die fünf Bausteine

Detektionsregeln (siehe Abschnitt 6) sind das sichtbare Ergebnis. Damit sie wirken, müssen fünf Voraussetzungen erfüllt sein:

1. Asset- und Logquellen-Inventar: Was gibt es im Netz (Clients, Server, Fachverfahren, Netzkomponenten, OT/Gebäudeleittechnik)? Welche Systeme können was protokollieren? Ohne diese Grundlage ist Monitoring blind.
2. Protokollierungskonzept: Welche Ereignisse werden auf welcher Quelle erfasst, mit welcher Detailtiefe, welcher Zeitsynchronisation und welcher Speicherfrist (Orientierung: 90 Tage)?
3. Zentrale Sammlung & Korrelation: Logdaten in ein zentrales System (SIEM oder schlanker Log-Sammler), integritätsgeschützt und auswertbar. Auch ein einfaches Setup ist besser als verstreute Einzellogs.
4. Alarmierung & Triage: Klar definierte Alarmwege, Rufbereitschaft, Eskalationsstufen, Zuständigkeiten (IT-Betrieb, ISB, Verwaltungsleitung) – auch außerhalb der Dienstzeit.
5. Anbindung an die Vorfallsbehandlung (DER.2.1): Detektion ohne Reaktion ist wirkungslos. Notfallplan, Kommunikationsketten zu BSI, Landes-CERT, Aufsichts- und Datenschutzbehörden und – bei Auslagerung – zum Dienstleister.

3. Betriebsmodelle: Wer überwacht eigentlich?

Die wichtigste Vorfrage vor jeder Tool- und Regelauswahl: Wie wird die kommunale IT betrieben? Kommunale IT-Organisation lässt sich entlang eines Sourcing-Kontinuums in vier Modelle einordnen – von weitgehend eigenständig bis vollständig in einen überregionalen Dienstleister integriert. Mit jedem Modell verschiebt sich, wer das Monitoring technisch erbringt und welche Aufgabe der Kommune verbleibt. Eine Konstante gilt jedoch über alle vier Modelle: die Kommune bleibt verantwortliche Stelle und behält die Steuerungsverantwortung, auch wenn der Betrieb ausgelagert ist.

Modell	Wer betreibt das Monitoring?	Schwerpunkt der kommunalen Aufgabe
1 – Teileigenständig	Eigener IT-Bereich, selektiver Zukauf	Aufbau & Betrieb in Eigenregie, gezielter Zukauf von Spezialleistungen (z. B. MDR)
2 – Eigener Dienstleister	Eigene IT-Tochter (GmbH/AöR)	Steuerung der Tochter über Eigentümerrolle & Leistungsvereinbarung
3 – Teil-integriert (Co-Sourcing)	Überregionaler Dienstleister und Kommune/Tochter	Klare Schnittstellen, lückenlose Verantwortungsabgrenzung
4 – Voll-integriert	Überregionaler Dienstleister (nahezu vollständig)	Vertragliche Steuerung, Transparenz & Restpflichten als verantwortliche Stelle

3.1 Modell 1 – Teileigenständige Kommune

Ein eigener IT-Bereich von nennenswertem Umfang erbringt wesentliche Leistungen selbst (Hardware, systemnahe Software, Betrieb von Software) und kauft selektiv Leistungen privater oder überregionaler kommunaler Dienstleister hinzu. Typisch für größere Städte oder Kommunen, die einem überregionalen Dienstleister nur mittelbar angeschlossen sind. Das Monitoring muss hier überwiegend selbst aufgebaut oder als Managed Service zugekauft werden. Ein eigenes 24/7-SOC ist für die meisten Kommunen weder personell noch wirtschaftlich darstellbar – realistisch ist ein hybrider Ansatz:

• Quick Wins in Eigenregie: Asset-/Logquellen-Inventar, Canary Files in sensiblen Verzeichnissen (z. B. Backup-Shares), OpenCanary-Honeypots im internen Netz, Härtung der Windows-Eventlog-Erfassung, Schwachstellenscans.
• EDR/MDR als gezielter Zukauf: 24/7-Endpoint-Detektion durch einen externen Anbieter – der kürzeste Weg zu wirksamer Erkennung ohne eigenes SOC. Entspricht der für dieses Modell typischen Ausprägung „selektiver Zukauf wesentlicher Leistungen“.
• Zentrale Logsammlung: Auch eine schlanke Lösung (z. B. Wazuh, Graylog, Elastic) ist besser als keine. Wichtig: Zeitsynchronisation, Integritätsschutz, dokumentierte Speicherfrist.
• Nicht-Windows-/Nicht-M365-Umfeld berücksichtigen: Linux-auditd, Firewall-/VPN-Logs, Logs der Fachverfahren, Druck-/Dateiserver – diese Quellen werden in vielen Vorlagen vergessen.
• Alarmkette und Rufbereitschaft: Wer wird wann alarmiert? Welche Eskalation greift bei Verdacht auf Ransomware?
• Dienstvereinbarung mit dem Personalrat: Protokollierung kann Verhaltens- und Leistungskontrolle berühren – frühzeitig regeln (vgl. Abschnitt 4).

3.2 Modell 2 – Kommune mit eigenem Dienstleister

Eine abgesonderte kommunale IT-Tochter (meist GmbH oder AöR) übernimmt die wesentlichen IT-Leistungen samt Rechenzentren, Netzen und Softwarebetrieb; in der Kernverwaltung verbleiben kleinere Einheiten zur Bündelung der Nutzerinteressen oder als Einkaufsfunktion. Der Zukauf erfolgt über die Tochter, nicht über die Kernverwaltung. Das Monitoring liegt damit operativ bei der Tochter – die Kommune steuert über ihre Eigentümerrolle und über Leistungsvereinbarungen.

• Steuerung über zwei Hebel: gesellschaftsrechtliche Eigentümerrolle (Aufsichtsgremien, Weisung) und Leistungs-/Service-Vereinbarung. Sicherheits- und Detektionsanforderungen gehören in beide.
• Monitoring-Leistungskatalog der Tochter: Welche Detektionsebenen (Perimeter, Endpoint, SIEM) betreibt die Tochter, mit welcher Abdeckung (Geschäftszeit vs. 24/7)? Schriftlich fixieren.
• Reporting an die Kommune: regelmäßige Security-Reports und Kennzahlen (MTTD/MTTR, Alarm-/Vorfallzahlen) an die ISB-Funktion der Kommune.
• Auch konzerninterne Auslagerung ist Auftragsverarbeitung: AVV nach Art. 28 DSGVO, Speicherorte, Löschfristen und Mandantentrennung gelten auch gegenüber der eigenen Tochter.
• Eigenständige Drittleistungen der Tochter im Blick behalten: kauft die Tochter ihrerseits zu (Subunternehmer), muss die Detektions- und Meldekette bis zum Subdienstleister durchgängig sein.

3.3 Modell 3 – Teil-integrierte Kommune (Co-Sourcing)

Ein überregionaler kommunaler Dienstleister erbringt wesentliche Leistungen (Rechenzentrum, Speicher, Fachanwendungen), während im Zuständigkeitsumfeld der Kommune – direkt oder über eine Tochter – nennenswerte Leistungen verbleiben (z. B. Netze, Software, Support). Dieses Co-Sourcing ist die häufigste, aber auch riskanteste Konstellation für das Monitoring, weil die Detektionsverantwortung auf zwei Parteien verteilt ist und an der Schnittstelle Lücken entstehen.

• Gemeinsame Verantwortungsmatrix (RACI) über die Schnittstelle hinweg: Für jede Detektionsebene und jedes Asset ist festzulegen, wer detektiert, triagiert, reagiert und meldet. Keine „Niemandsland“-Systeme.
• Korrelation über beide Welten: Idealerweise fließen die Logs beider Seiten in eine gemeinsame Auswertung – oder es gibt einen definierten Austausch von Alarmen an der Schnittstelle.
• Wechselseitige Meldepflichten: verbindliche Eskalations-/Meldefristen in beide Richtungen (Dienstleister → Kommune und Kommune → Dienstleister), in Stunden, nicht Tagen.
• Gemeinsame Übungen: mindestens eine jährliche Tabletop-Übung über die Schnittstelle hinweg, um die Verantwortungsabgrenzung praktisch zu prüfen.
• Lokale Eigenleistung nicht vernachlässigen: Für die selbst betriebenen Komponenten gelten die Empfehlungen aus Modell 1 (EDR, Logsammlung, Canary Files).

3.4 Modell 4 – Voll-integrierte Kommune

Die Kommune ist an einem überregionalen kommunalen Dienstleister beteiligt und bezieht von ihm nahezu alle wesentlichen Funktionen; in der Verwaltung verbleibt im Wesentlichen eine Einkaufs- bzw. Beauftragungsfunktion. Hier verschiebt sich der Schwerpunkt vollständig von der technischen Umsetzung zur vertraglichen Steuerung. Die Detektionsleistung wird über Leistungsschein/SLA gesteuert, nicht selbst erbracht.

Steuerungsfragen, die im Leistungsschein / Vertrag verbindlich geregelt sein müssen

• Leistungsumfang Detektion: Welche Ebenen überwacht der Dienstleister tatsächlich – nur Perimeter (Firewall/Anti-Spam), auch Endpoint (EDR), auch Logkorrelation (SIEM)? Wird 24/7 überwacht oder nur zu Geschäftszeiten?
• Verantwortungsmatrix (RACI): Wer detektiert, wer triagiert, wer reagiert, wer meldet? Wo endet die Verantwortung des Dienstleisters, wo beginnt die der Kommune?
• Meldepflichten Dienstleister → Kommune: Verbindliche Eskalations- und Meldefristen bei sicherheitsrelevanten Ereignissen (Stunden, nicht Tage). In bestehenden Verträgen oft unterspezifiziert – aktiv nachverhandeln.
• Reporting und Transparenz: Regelmäßige Security-Reports, Kennzahlen (MTTD/MTTR, Anzahl Alarme/Vorfälle), Zugriff auf die eigenen Logdaten.
• Audit- und Kontrollrechte: Nach Art. 28 DSGVO, einschließlich Subunternehmer und Fernzugriffe; ggf. Vor-Ort-Audits oder unabhängige Prüfberichte (SOC 2, ISO 27001).
• AVV und Datenflüsse: Welche Logdaten verlassen die Kommune? Speicherort, Löschfristen, Verschlüsselung, Mandantentrennung.
• Klumpenrisiko bedenken: Fällt der zentrale Dienstleister aus, sind potenziell viele Kommunen gleichzeitig betroffen. Notfallvorsorge und Wiederanlauf-Szenarien gehören in den Vertrag.
• Exit-/Transitionsklauseln: Rückgabe von Logs und Konfigurationen in nutzbarem Format, Vermeidung von Vendor-Lock-in.

Restpflichten der Kommune – in allen ausgelagerten Modellen (2–4)

• Funktion des ISB als Steuerungsstelle – inhaltlich, nicht nur formal.
• Eigenes Asset-Inventar (auch wenn der Dienstleister eines führt – Vier-Augen-Prinzip).
• Nutzung der Angebote von Bund und Land: Lagebilder, Leak-Checker, Pentest-Programme und Incident-Response-Unterstützung durch BSI, Landes-CERTs und kommunale Spitzenverbände.
• Eigener Notfallplan inkl. Schnittstelle zum Dienstleister, mit Übungen.
• Meldewege nach außen (BSI, Landes-CERT, Aufsichtsbehörden, Datenschutzbehörde) – diese kann der Dienstleister vorbereiten, aber nicht für die Kommune übernehmen.

4. Datenschutz, Mitbestimmung und Beschäftigtenrechte

Protokollierung und Detektion erzeugen personenbeziehbare Daten und können potenziell Verhaltens- und Leistungskontrolle ermöglichen. DER.1 fordert ausdrücklich die Wahrung der Persönlichkeits- und Mitbestimmungsrechte. Vor dem Aufbau eines Monitorings sind daher zu klären:

• Rechtsgrundlage der Verarbeitung (DSGVO, BDSG, Landes-IT-Sicherheitsgesetz, Landesdatenschutzgesetz, Personalvertretungsrecht).
• Zweckbindung: Detektion und Vorfallsanalyse – keine Verhaltens- oder Leistungsbewertung.
• Datenminimierung & Pseudonymisierung dort, wo möglich.
• Speicher- und Löschfristen (Orientierung: 90 Tage; verlängert nur bei nachweislichem Cyberangriff oder ohne Personenbezug).
• Beteiligung des Personalrats nach Landespersonalvertretungsrecht – idealerweise über eine Dienstvereinbarung Protokollierung.
• Information der Beschäftigten (Transparenzpflicht).
• Datenschutz-Folgenabschätzung prüfen, ggf. Beteiligung des Datenschutzbeauftragten.

5. Priorisierung – das Minimal-Set zuerst

Wer ohne SIEM startet, sollte sich nicht an 27 Use-Cases verzetteln. Empfohlene Reifegradstufen:

Stufe 1 – Minimal-Set (auch ohne SIEM)

• EDR auf allen Clients und Servern mit zentralem Alarming.
• Schutz und Monitoring der Backups (Löschversuche, Schattenkopien, GPO-Änderungen).
• Canary Files in sensiblen Verzeichnissen.
• Monitoring von RDP-/VPN-Anmeldungen und fehlgeschlagenen Logins.
• Überwachung der Funktionsfähigkeit der Sicherheitsdienste (AV/EDR/Firewall-Agent).
• E-Mail-Security: Quarantänequoten und Anomalien beobachten.

Stufe 2 – Aufbaustufe

• Zentrale Logsammlung mit Korrelation (SIEM oder schlanker Sammler).
• OpenCanary-Honeypots im internen Netz.
• Schwachstellen-Scans (intern und perimeter) und Reaktion auf Befunde.
• Threat-Intel-Feeds an Firewall und SIEM anbinden.
• AD-/Identity-Monitoring (Privilegieneskalation, neue GPOs, Trusts).
• DNS-Monitoring (Anfragen an bekannte Malware-Domains, DGA-Muster).

Stufe 3 – Vollausbau

• SIEM mit Use-Case-Bibliothek nach MITRE ATT&CK.
• UEBA/Verhaltensbaselines.
• NDR/NetFlow-Auswertung (East-West-Traffic).
• SOAR-Playbooks für wiederkehrende Reaktionsmuster.
• Threat Hunting und periodische Purple-Team-Übungen.

6. Detektions-Use-Cases

Die folgenden Use-Cases sind als Bibliothek zu verstehen, nicht als Reihenfolge: Welche davon umgesetzt werden, hängt vom Reifegrad und Betriebsmodell ab. Schwellenwerte sind Startwerte und müssen durch organisationsspezifische Baselines angepasst werden.

🔐 Benutzer- & Anmeldeereignisse

1. Anomalie bei fehlgeschlagenen Logins (User-ID)
   • Bedingung: ≥6 fehlgeschlagene Anmeldeversuche in 5 Minuten bei einer Benutzer-ID
   • Verstärkung der Alarmstufe, wenn:
     • kein erfolgreicher Login danach erfolgt
     • Zeitpunkt außerhalb üblicher Arbeitszeiten liegt (z. B. 18–6 Uhr)
     • Anmeldeversuche von unbekannter oder geolokal auffälliger IP erfolgen
   • Tool: SIEM, UEBA, IAM
2. Anomalie bei fehlgeschlagenen Logins (IP-basiert)
   • Bedingung: ≥10 fehlgeschlagene Anmeldeversuche von einer IP in 3 Minuten
   • Verstärkung der Alarmstufe, wenn:
     • auf mehrere verschiedene Benutzerkonten gezielt wird
     • IP-Adresse aus unbekanntem oder verdächtigem Bereich stammt
     • Versuche mit ungewöhnlichem Protokoll oder Port erfolgen
   • Tool: SIEM, IDS, UEBA
3. Neues Admin-Konto oder Privilegieneskalation
   • Bedingung: Neuer Benutzer wird einer privilegierten Gruppe hinzugefügt (Eventlog 4728/4732/4756)
   • Tool: IAM, SIEM, UEBA
   • Optional: Nur Alarm, wenn durch Nicht-Admin ausgelöst

📧 E-Mail-Security-Monitoring

E-Mail ist nach BSI-Lagebild der wichtigste Initial-Vektor (Phishing, Malware-Anhänge). Daher gehört E-Mail-Monitoring zwingend in das Minimal-Set.

4. Verdächtige Anhänge / URL-Klicks
   • Bedingung: Klicks auf in Sandbox als bösartig erkannte URLs; Quarantäne-Treffer bei Anhängen mit Office-Makros, ISO/IMG, OneNote, HTML-Smuggling
   • Tool: Mail-Gateway, Sandbox, SIEM
5. Massen-Spam-/Phishing-Wellen auf die Organisation
   • Bedingung: Sprunghafter Anstieg der Quarantäne-/Block-Quote über Baseline
   • Tool: Mail-Gateway, SIEM
6. SPF/DKIM/DMARC-Anomalien
   • Bedingung: Häufung von DMARC-Fails auf eigene Domain (Spoofing) oder auf häufig genutzte Absender (Lieferanten)
   • Tool: DMARC-Auswertung, SIEM
7. Verdächtige Weiterleitungsregeln in Postfächern
   • Bedingung: Neue automatische Weiterleitung an externe Adressen
   • Tool: Mailserver-/Groupware-Audit, SIEM

💻 System- & Dateiüberwachung

8. Ausführung von PowerShell / Cmd-Skripten
   • Bedingung: PowerShell mit Base64-/EncodedCommand-Parameter,  -NoProfile -ExecutionPolicy Bypass, Remote-Download (IEX (New-Object Net.WebClient).DownloadString)
   • Tool: EDR, SIEM, UEBA, PowerShell Script Block Logging (Event 4104)
   • Optional: Nur auf normalen Arbeitsplätzen alarmieren, Admin-Workstations whitelisten
9. Änderung kritischer Systemdateien
   • Bedingung: Änderung an Systemdateien erkannt per Hash-Abweichung
   • Tool: FIM, EDR, SIEM
10. Löschen oder Manipulation von Logdateien
    • Bedingung: Eventlog-Clear (Event 1102 im Security-Log, Event 104 im System-Log), Beendigung des Eventlog-Diensts, Manipulation der Audit-Policy
    • Tool: SIEM, EDR, FIM
    • Korrelation mit vorherigen verdächtigen Aktionen ist hier besonders aussagekräftig

🌐 Netzwerk- & Kommunikationsereignisse

11. Erlaubter Verbindungsversuch zu bekannter Malware-IP/-Domain
    • Bedingung: Firewall/Proxy/DNS-Resolver erlaubt Verbindung zu Indikator aus Threat-Intel-Feed
    • Tool: SIEM, Firewall, DNS-Logs, Threat Intelligence, NDR
12. DNS-Anomalien (DGA, ungewöhnliche TLDs, hohe NXDOMAIN-Quote)
    • Bedingung: Auffällige Muster im DNS-Verkehr eines Clients (Indikator für C2-Kommunikation)
    • Tool: DNS-Resolver-Logs, NDR, SIEM
13. Verbindung zu ungewöhnlich vielen Zielen (laterale Bewegung)
    • Bedingung: ≥100 Verbindungen zu unterschiedlichen internen IPs in 1 Minute
    • Tool: NDR, NetFlow, SIEM, UEBA
14. Externer Upload von ausführbaren Dateien auf Webserver
    • Bedingung: Upload von .exe, .php, .jsp, .aspx, Web-Shell-Mustern
    • Tool: WAF, FIM, IDS/IPS, SIEM
15. Firewall-Drop-/Reject-/Deny-Ereignisse von externer IP
    • Bedingung: ≥15 wiederholte Blockierungen aus derselben Quelle
    • Tool: Firewall, IDS/IPS, SIEM

🕸️ Web-, API- und Fachverfahrens-Monitoring

Kommunale Fachverfahren, Bürgerportale und Web-Anwendungen sind ein eigener Angriffsvektor, den reine Infrastruktur-Logs nicht abdecken. Über das bloße Erkennen externer Datei-Uploads hinaus sind nach OWASP mindestens die folgenden Anwendungsereignisse zu protokollieren und auszuwerten:

16. Authentifizierungs- und Autorisierungsfehler in Web-/Fachanwendungen
    • Bedingung: Häufung fehlgeschlagener Logins, Zugriffe auf nicht autorisierte Ressourcen (Access-Control-Fails), Privilege-Escalation-Versuche in der Anwendung
    • Tool: Anwendungs-Logs, WAF, API-Gateway, SIEM
17. Serverseitige Eingabevalidierungs-Fehler
    • Bedingung: Häufung serverseitig abgewiesener Eingaben – Indikator für SQL-Injection-, XSS- oder Path-Traversal-Versuche
    • Tool: Anwendungs-Logs, WAF, SIEM
18. Token-/Session-Anomalien
    • Bedingung: ungültige/abgelaufene Token, Session-Fixation, parallele Sessions desselben Kontos von verschiedenen Standorten
    • Tool: Anwendungs-Logs, API-Gateway, SIEM
19. Administrative Konfigurationsänderungen in der Anwendung
    • Bedingung: Änderung von Rollen, Rechten, Schnittstellen oder Sicherheitseinstellungen im Fachverfahren
    • Tool: Anwendungs-Audit-Log, SIEM
20. Sicherheitsrelevante WAF-/API-Gateway-Ereignisse und Backend-TLS-Fehler
    • Bedingung: WAF-Blockmeldungen über Schwellwert, fehlschlagende Backend-TLS-Verbindungen (mögliche Manipulation/MitM)
    • Tool: WAF, API-Gateway, Reverse Proxy, SIEM

Hinweis zur Nummerierung: Die Use-Cases sind als thematische Bibliothek organisiert; die laufenden Nummern dienen nur der Orientierung innerhalb des jeweiligen Blocks.

🦠 Malware-Erkennung & Signaturen

16. Malware auf mehreren Hosts erkannt
    • Bedingung: Gleiche Signatur ≥5 Geräte in 30 Minuten
    • Tool: EDR, SIEM, Sandbox
17. Einzelhost erkennt bekannte Malware
    • Bedingung: Positivscan durch AV/EDR
    • Tool: EDR, SIEM, Malware-Analyse

🗂 Backup- & Wiederherstellungsüberwachung

18. Löschversuch eines Backups
    • Bedingung: Backup-Datei oder -Ordner wird gelöscht oder verschoben
    • Tool: SIEM, Backup-Software-Logging, FIM
    • Optional: Sofort-Alarm bei externem Benutzer oder außerhalb Wartungszeit
19. Löschen von Schattenkopien oder Systemwiederherstellungspunkten
    • Bedingung: Aufruf von vssadmin delete shadows, wmic shadowcopy delete, oder bcdedit /set {default} recoveryenabled No; Ereignis-ID 33 (SystemRestore)
    • Tool: EDR, SIEM, Sysmon (Event 1: ProcessCreate), Windows Eventlog
20. Änderung an Gruppenrichtlinien (GPO)
    • Bedingung: GPO wird geändert, insbesondere neue Ausnahmen oder Deaktivierung sicherheitsrelevanter Einstellungen
    • Tool: SIEM, GPO-Monitoring, Eventlog 5136/4739

🖥 Serverseitige Systemereignisse

21. SMB-Authentifizierungsfehler (Event-ID 551 im Log Microsoft-Windows-SMBServer/Security)
    • Bedingung: Häufung fehlgeschlagener SMB-Anmeldungen – Hinweis auf SMB-Brute-Force oder NTLM-Relay-Versuche
    • Hinweis: Im klassischen Security-Eventlog steht Event 551 historisch für „User initiated logoff“ – nicht verwechseln. Maßgeblich ist hier das SMBServer/Security-Log
    • Tool: Windows Eventlog, SIEM, EDR
22. MSTSC-Aufruf trotz Sperrung
    • Bedingung: Prozess mstsc.exe wird gestartet, obwohl RDP durch Richtlinie deaktiviert ist
    • Tool: EDR, Application Control, SIEM
23. Ausfall von Sicherheitsdiensten
    • Bedingung: Antiviren-, EDR-, Firewall- oder Patch-Agent ist deaktiviert oder beendet
    • Tool: EDR, Monitoring, SIEM
    • Optional: Sofortmeldung bei dauerhaftem Ausfall > 2 Minuten

Hinweis: Klassische Verfügbarkeitsindikatoren wie Disk-Fehler (Event 7) oder NTFS-Fehler (Event 55) sind Betriebs-/Verfügbarkeitsmonitoring und werden hier nicht weiter aufgeführt – auch wenn sie über das Systemmonitoring beobachtet werden sollten.

🧪 Erweiterte Angriffserkennung & Täuschungstechniken

24. Verbindungsversuche auf Honeypot-Dienste
    • Bedingung: Verbindungsversuch auf simulierte Netzwerkdienste (z. B. HTTP, FTP, SSH, SMB, MySQL, Redis, Telnet, SNMP), die auf produktiven Systemen nicht genutzt werden
    • Schwellenwert: Jeder Versuch gilt als verdächtig
    • Tool: Honeypot (z. B. OpenCanary), SIEM zur Auswertung
    • Optional: Eskalationsstufen je nach Diensttyp (z. B. SMB oder SSH höher gewichtet)
25. Zugriff auf Canary Files
    • Bedingung: Zugriff (Lesen, Ändern, Löschen) auf überwachte Köderdateien (z. B. Admin-Anmeldedaten.txt, KeePass.kdbx) in sensiblen Verzeichnissen
    • Schwellenwert: Jeder Zugriff ist verdächtig
    • Tool: SIEM, FIM, EDR, Script-basierte FileWatcher
26. Verdächtige Nutzung von RDP
    • Bedingung: RDP-Login von ungewohnten IPs (Event 4624 Logon-Type 10), zu ungewöhnlichen Zeiten oder mit ungewöhnlichen Benutzerprofilen
    • Tool: SIEM, IDS/IPS, Windows Eventlog (4624/4625)
    • Optional: Korrelation mit Geodaten und vorherigem Verhalten
27. Auslesen von Anmeldedaten (LSASS-Zugriff)
    • Bedingung: Zugriff auf LSASS-Prozess oder verdächtige Speicher-Dumps (z. B. Mimikatz, Procdump, MiniDumpWriteDump)
    • Tool: EDR, SIEM, Sysmon (Event 10: ProcessAccess), Windows Defender Credential Guard
28. Active-Directory-Aufklärung (Recon)
    • Bedingung: Auffällige Abfragen über LDAP/SAMR, Tools wie BloodHound, Kerberoasting-Indikatoren (Event 4769 mit auffälliger Häufung)
    • Tool: SIEM, EDR, ATA/Defender for Identity-Äquivalent, AD-Audit

🔎 Schwachstellen- und Angriffsflächenmonitoring

29. Neue kritische Schwachstelle auf einem Asset
    • Bedingung: CVSS ≥ 9,0 oder BSI-Warnstufe Rot auf einem internen System
    • Tool: Schwachstellenscanner (z. B. Greenbone/OpenVAS, Nessus), Asset-Inventar, BSI-CERT-Warnmeldungen
30. Unbekannte exponierte Dienste am Perimeter
    • Bedingung: Externer Scan/Attack-Surface-Monitoring meldet offenen Port oder Dienst, der nicht im Inventar steht
    • Tool: External Attack Surface Management, Pentest-Programme der Landes-CERTs / kommunalen Spitzenverbände

🕵️ Leak- und Darknet-Monitoring

31. Treffer im Leak-Monitoring
    • Bedingung: Dienst- oder Mitarbeitenden-Zugangsdaten der Kommune tauchen in Leak-Datenbanken auf
    • Tool: Leak-Checker-Angebote von BSI und Landes-CERTs, kommerzielle Leak-Monitoring-Dienste, HaveIBeenPwned (für Mailadressen)
32. Erwähnung der Kommune in Darknet-/Ransomware-Leak-Sites
    • Bedingung: Name, Domain oder IP der Kommune erscheint in Datenleck-Plattformen einschlägiger Ransomware-Gruppen
    • Tool: Threat-Intel-Anbieter, eigenes Monitoring (vgl. kommunaler-notbetrieb.de)

⚠️ Allgemeine Verhaltenserkennung

33. Anwendung startet/stoppt mehrfach ungewöhnlich
    • Bedingung: ≥5 Starts/Stops in 10 Minuten
    • Tool: Monitoring, SIEM
34. IDS meldet ≥10 Warnungen pro Minute von einer IP
    • Bedingung: Nur bei „High Severity“-Signaturen
    • Tool: IDS, SIEM

7. Vom Use-Case zum Betrieb: Verantwortung, Reaktion und Wirksamkeit

Eine Detektionsregel ist erst dann betriebsreif, wenn klar ist, wer auf sie reagiert und wie ihre Wirksamkeit gemessen wird. Die folgenden Festlegungen sollten für jeden eingesetzten Use-Case dokumentiert sein – das ist der Unterschied zwischen einer Ideensammlung und einem auditierbaren Monitoring.

7.1 Pflichtangaben pro Use-Case

• Fachlicher Owner (verantwortet Sinn und Schwellenwerte der Regel) und technischer Owner (verantwortet Logquelle und Regelbetrieb).
• Alarm-Schweregrad und zugeordnete Reaktionszeit (z. B. kritisch / hoch / mittel mit jeweiliger Zielzeit bis zur Bearbeitung).
• Eskalationsweg (an wen wird wann übergeben – inkl. Rufbereitschaft und, bei Auslagerung, Schnittstelle zum Dienstleister).
• Datenschutzbewertung (Personenbezug der Logquelle, Rechtsgrundlage, Speicherfrist – vgl. Abschnitt 4).
• Testverfahren und Review-Turnus (wie und wie oft wird geprüft, ob die Regel noch greift und nicht zu viele Fehlalarme erzeugt).
• Dokumentation von Änderungen an Regel und Whitelist (nachvollziehbar, versioniert).

7.2 Kennzahlen zur Wirksamkeit

Wirksamkeit lässt sich nicht an der Zahl der Regeln ablesen, sondern an Abdeckung und Reaktionsfähigkeit. Empfohlenes Mindest-Set:

Kennzahl	Was sie zeigt
Abdeckung kritischer Logquellen (in %)	Ob die wichtigsten Systeme überhaupt im Monitoring angekommen sind
MTTD / MTTA / Zeit bis Eindämmung	Reaktionsfähigkeit statt bloßer Regelanzahl
Fehlalarmquote je Use-Case	Tuning-Bedarf und Akzeptanz im Fachbetrieb
Anteil Use-Cases mit Owner und Runbook	Revisionsfestigkeit und Betreibbarkeit
Anteil Post-Incident-Reviews mit umgesetzten Lessons Learned	Verankerung kontinuierlicher Verbesserung
Web-/API-Security-Logging-Abdeckung	Schließung der häufig größten Detektionslücke

Ergänzend gehören zu einem reifen Monitoring: eine Liste der kritischen Assets, die aktiv zu protokollieren sind; standardisierte Logformate; Schutz gegen Log-Manipulation; Zeitquellensynchronisation; sowie Post-Incident-Reviews mit dokumentierten Lessons Learned.

8. Zielarchitektur

Die Use-Cases entfalten ihre Wirkung erst in einer durchgängigen Verarbeitungskette von der Logquelle bis zur Reaktion. Das Zielbild gliedert sich in vier Schichten – unabhängig davon, ob diese im Eigenbetrieb oder beim Dienstleister liegen:

1. Quellen: AD / IAM / Verzeichnisdienste · Windows-Eventlog / Endpoint-Telemetrie / EDR · Firewall / VPN / DNS / Proxy / IDS · Webserver / WAF / API-Gateway / Fachverfahren · Backup- und Storage-Audit-Logs · Honeypots / Canary Files.
2. Sammlung: Forwarder / Syslog / Agenten → Normalisierung und Zeitsynchronisation → Anreicherung mit Asset- und Identitätskontext.
3. Analyse: zentrales Log-Management / Data Lake → SIEM-Korrelation und Regeln, angereichert um Threat Intel, Baselines und Whitelists.
4. Betrieb: Cases / Tickets / Playbooks → Bearbeitung durch kommunalen IT-Betrieb oder Shared Service / IT-Dienstleister / MDR → Steuerung und Eskalation an ISB/CISO, Leitung und DSB.

Für die Toolauswahl ist weniger die „beste Plattform“ entscheidend als die Passung zum Betriebsmodell (Abschnitt 3). Open-Source-Werkzeuge (z. B. Wazuh, Security Onion, OpenCanary, Velociraptor) sind attraktiv, wenn ein kompetenter Dienstleister oder Zweckverband den Betrieb übernimmt; Cloud- und kommerzielle Plattformen sind sinnvoll, wenn bereits passende Lizenz- und Betriebsökosysteme bestehen. Die teuerste Komponente sind selten einzelne Regeln, sondern zentrale Speicherung, Retention, Dienstabdeckung und Personalbindung.

9. Umsetzungsfahrplan

Der Fahrplan priorisiert, was auf Basis dieser Empfehlungen am schnellsten Wirkung zeigt – Identität, Endpoint, Backup und dokumentierte Reaktion – bevor Netzwerk-, Web- und Täuschungsmaßnahmen systematisch ausgebaut werden:

Phase	Maßnahmen	Orientierung
Fundament	Geltungsbereich, Rollen, Datenschutzkonzept; kritische Logquellen priorisieren und anbinden	Voraussetzung für alles Weitere
Quick Wins	Login-, Admin-, PowerShell- und Backup-Use-Cases; Alarmstufen, Ticketing und Eskalationswege	Hoher Nutzen bei geringem Aufwand
Ausbau	Web-/API-Logs, Firewall, VPN und IDS integrieren; Honeypots, Canary Files und Kontextanreicherung	Setzt Fundament voraus
Verstetigung	KPI-Dashboard, Tuning, Review und Tests; Shared Service oder MDR anbinden	Dauerhafte Wirksamkeit sichern

10. Hinweise zur Umsetzung

• Reife vor Tiefe: Lieber zehn gut gepflegte und alarmierende Use-Cases als 30 papierne Regeln.
• Baselines & dynamische Schwellenwerte: Statische Schwellen sind Startpunkte. Tatsächlich wertvoll werden Regeln erst über organisationsspezifische Baselines (idealerweise ML-gestützt).
• Whitelisting für bekannte Administratoren, Skripte, Scanner, Patch-Server und Service-Accounts – sonst ertrinkt die Triage in Fehlalarmen.
• Korrelation und Kontext sind wichtiger als Einzelereignisse: Ein LSASS-Zugriff allein ist möglicherweise legitim, in Kombination mit PowerShell-Base64 und Schattenkopien-Löschung ist es ein Vorfall.
• MITRE ATT&CK-Mappung: Jede Regel sollte mindestens einer ATT&CK-Technik zugeordnet sein – das macht Lücken sichtbar.
• Übung: Detektion und Reaktion regelmäßig üben (Tabletop, Red-Team-/Purple-Team-Ansätze, Übungsangebote von BSI, Landes-CERTs und kommunalen Spitzenverbänden).

11. Referenzen

• BSI IT-Grundschutz-Kompendium: Bausteine DER.1, OPS.1.1.5, DER.2.1
• BSI-Mindeststandard zur Protokollierung und Detektion von Cyberangriffen, Version 2.1
• BSI – Top 10 Ransomware-Maßnahmen (Detektion)
• BSI SiSyPHuS Win10 – Empfehlung zur Konfiguration der Protokollierung
• IT-Grundschutz-Profil Basis-Absicherung Kommunalverwaltung (koBA v4.0) sowie BSI-Projekt WiBA – Weg in die Basis-Absicherung
• BSI – FAQ NIS-2 für Land und Kommune
• BSI – Lageberichte zur IT-Sicherheit in Deutschland
• MITRE ATT&CK für Enterprise (attack.mitre.org) und CIS Controls v8
• DIN EN ISO/IEC 27001 / 27002 (ISMS, Logging, Monitoring, Zeitsynchronisation) und ISO/IEC 27035 (Incident Management)
• OWASP – Logging Cheat Sheet, „Logging & Monitoring Failures“ (Top-10 A09) sowie OWASP-Leitfäden zu API-/REST-Sicherheit
• DIN SPEC 27076 – CyberRisikoCheck (niedrigschwelliger Einstieg für kleinere Organisationen)

📘 Glossar der verwendeten Abkürzungen

• AVV: Auftragsverarbeitungsvertrag (Art. 28 DSGVO)
• BSI: Bundesamt für Sicherheit in der Informationstechnik
• BSIG: BSI-Gesetz
• DER.1 / OPS.1.1.5 / DER.2.1: IT-Grundschutz-Bausteine (Detektion / Protokollierung / Vorfallsbehandlung)
• EDR: Endpoint Detection and Response
• FIM: File Integrity Monitoring
• IAM: Identity and Access Management
• IDS/IPS: Intrusion Detection/Prevention System
• ISB: Informationssicherheitsbeauftragter
• koBA: kommunale Basis-Absicherung (IT-Grundschutz-Profil)
• MDR: Managed Detection and Response
• CERT / CSIRT: Computer Emergency Response Team / Computer Security Incident Response Team
• MITRE ATT&CK: Wissensbasis gegnerischer Taktiken und Techniken
• MTTD/MTTR: Mean Time to Detect / Mean Time to Respond
• NDR / NTA: Network Detection & Response / Network Traffic Analysis
• NIS-2 / NIS2UmsuCG: EU-Richtlinie und deutsches Umsetzungsgesetz
• SIEM: Security Information and Event Management
• SOAR: Security Orchestration, Automation and Response
• SOC: Security Operations Center
• UEBA / UBA: User (and Entity) Behavior Analytics
• WiBA: Weg in die Basis-Absicherung (BSI-Einstiegsprojekt)