February 24, 2026

SIEM im Netzwerk: Logs richtig sammeln und sinnvoll auswerten

SIEM im Netzwerk ist heute einer der wichtigsten Bausteine, um Sicherheitsvorfälle frühzeitig zu erkennen, Ursachen sauber zu analysieren und Compliance-Anforderungen zu erfüllen. Firewalls, IDS/IPS, EDR, Proxy/SWG, VPN, Switches und Cloud-Plattformen erzeugen täglich enorme Mengen an Ereignissen. Ohne zentrale Sammlung und Auswertung bleiben diese Daten oft ungenutzt oder werden nur im Störungsfall manuell durchsucht. Ein SIEM (Security Information and Event Management) bringt Struktur in dieses Chaos: Es sammelt Logs aus vielen Quellen, normalisiert sie, korreliert Ereignisse und unterstützt mit Alarmierung, Dashboards und Suchfunktionen. Der Nutzen entsteht aber nicht automatisch durch „mehr Logs“. In der Praxis scheitern SIEM-Projekte häufig an fehlender Log-Qualität, falscher Priorisierung („alles loggen“) oder an fehlenden Use Cases. Dieser Artikel zeigt, wie Sie Logs im Netzwerk richtig sammeln und sinnvoll auswerten: welche Quellen wirklich wichtig sind, wie Sie Logging-Standards definieren, wie Sie Datenqualität sichern (Zeit, Felder, Parser), wie Sie Noise reduzieren und wie Sie aus Logs belastbare Erkennungsregeln und Betriebsroutinen ableiten – so, dass SIEM im Alltag hilft und nicht nur Kosten erzeugt.

Table of Contents

Was ist ein SIEM und was leistet es im Netzwerk?

Ein SIEM ist eine zentrale Plattform zur Sammlung, Speicherung, Suche, Korrelation und Alarmierung von Sicherheits- und Systemereignissen. Im Netzwerk-Kontext ist das SIEM der Ort, an dem technische Signale zusammenlaufen: Firewall-Drops, VPN-Logins, DNS-Anfragen, Proxy-Events, Switch-Port-Änderungen, WLAN-Authentifizierungen, Cloud-Audit-Logs und vieles mehr.

Log-Sammlung: Ereignisse aus vielen Quellen werden zentral ingestiert.
Normalisierung: Unterschiedliche Logformate werden in ein einheitliches Schema überführt.
Korrelation: Einzelereignisse werden zu aussagekräftigen Mustern kombiniert (z. B. „Login-Anomalie + neue Adminrechte + Datenabfluss“).
Alarmierung: Relevante Ereignisse werden priorisiert gemeldet.
Forensik und Suche: Schnelle Ursachenanalyse, Zeitachsen, Beweissicherung.

Als strukturierter Orientierungsrahmen für Sicherheitsprozesse – inklusive Detektion und Reaktion – eignet sich das NIST Cybersecurity Framework.

Warum „Logs richtig sammeln“ wichtiger ist als „mehr Logs sammeln“

Ein SIEM ist nur so gut wie seine Daten. Schlechte Datenqualität führt zu schlechten Alerts: falsche Zeitstempel, fehlende Felder, inkonsistente Hostnamen, doppelte Events oder unklare Benutzerzuordnung. Ebenso problematisch ist eine Logflut ohne Priorisierung: Dann verlieren Teams die Übersicht und ignorieren Alarme (Alarmmüdigkeit).

Qualität vor Quantität: Lieber weniger Quellen sauber integrieren als „alles halb“.
Use Case zuerst: Logs werden gesammelt, weil sie konkrete Erkennungs- und Analyseziele unterstützen.
Standardisierung: Zeit, Felder, Namenskonventionen und Parser müssen konsistent sein.

Welche Netzwerk-Logs sind im SIEM wirklich entscheidend?

In der Praxis liefern einige Quellen besonders hohen Sicherheitswert. Sie decken typische Angriffsphasen ab: Initialzugriff, Bewegung, Eskalation, Exfiltration. Für viele Umgebungen lohnt es sich, mit diesen Kategorien zu starten:

Firewall- und NAT-Logs

Allow/Deny an Zonenübergängen: Internet/DMZ, DMZ/LAN, User/Server, Management-Zonen.
NAT-Events: DNAT/SNAT-Zuordnungen sind für Forensik extrem wertvoll.
Threat-/IPS-Events: Signaturtreffer, Blockierungen, Anomalien (wenn NGFW/IPS integriert ist).

VPN- und Remote-Access-Logs

Authentifizierungen: erfolgreiche/fehlgeschlagene Logins, MFA-Events, neue Geräte.
Session-Daten: Quell-IP, Client, Dauer, zugewiesene IP, Gruppen/Rollen.
Anomalien: ungewöhnliche Zeiten, geografische Auffälligkeiten, Login-Spikes.

DNS-Logs

Queries und Antworten: Domain, Client, Resolver, Response Code (z. B. NXDOMAIN).
Indikatoren: ungewöhnliche TLDs, DGA-Muster, viele NXDOMAINs, seltene Domains.
Wert für IR: DNS ist oft der Schlüssel zur C2- und Exfiltrationserkennung.

Proxy/SWG- und Web-Gateway-Logs

URL/Host/Category: Welche Ziele werden besucht, welche Kategorien blockiert?
Downloads: Dateityp, Größe, Quelle – wichtig für Malware-Ketten.
Policy-Verstöße: DLP-, CASB- oder Upload-Blockierungen (wenn vorhanden).

Switch- und WLAN-Logs

Port-Events: Link up/down, MAC-Learning-Anomalien, Port-Security-Events.
802.1X/WLAN-Auth: Anmeldungen, Roaming, Fehlversuche, neue Geräte.
Netzwerkzugang: Wer war wann wo im Netz (für Forensik sehr wertvoll).

Identity- und Verzeichnisdienste

Auch wenn es keine „Netzwerkkomponente“ ist: Identität ist der wichtigste Kontext für Netzwerk-Events. Ohne Identity-Logs bleibt vieles anonym.

SSO/MFA-Events: Risky sign-ins, MFA-Fails, neue Sessions.
Gruppen-/Rollenänderungen: Neue Adminrechte sind ein High-Value-Signal.
Service Accounts: ungewöhnliche Nutzung, neue Logins, Standortabweichungen.

Für die Zuordnung typischer Angriffsphasen und Use Cases ist MITRE ATT&CK eine bewährte Referenz.

Log-Transport: Wie Logs zuverlässig ins SIEM kommen

Der Transportweg entscheidet über Zuverlässigkeit und Integrität. Im Netzwerkumfeld sind typische Wege Syslog, API-basierte Collector-Modelle oder Agents auf Systemen, die Logs weiterleiten. Die Wahl hängt von Quelle, Datenvolumen und Sicherheitsanforderungen ab.

Syslog: Standard im Netzwerkbereich; wichtig sind zuverlässige Zustellung und saubere Parsing-Regeln.
Syslog over TLS: Verschlüsselter Transport, sinnvoll bei untrusted Netzen oder Compliance-Anforderungen.
API/Connector: Für Cloud-Logs oder SaaS oft der beste Weg, inklusive strukturierter Felder.
Collector/Relay: Zentraler Log-Collector reduziert Last auf dem SIEM und ermöglicht Buffering.

Datenqualität sichern: Zeit, Normalisierung und eindeutige Identitäten

Die wichtigsten Qualitätsfaktoren im SIEM sind Zeitstempel, Feldkonsistenz und eindeutige Zuordnung. Ohne diese Grundlagen funktioniert Korrelation nicht zuverlässig.

Zeitbasis mit NTP konsistent machen

NTP überall: Firewalls, Switches, Server, Collector, SIEM müssen dieselbe Zeitbasis nutzen.
Zeitzonen-Regeln: Einheitliches Format (z. B. UTC) und korrekte Zeitzonenfelder vermeiden Verwirrung.
Drift überwachen: Zeitabweichungen erzeugen fehlerhafte Korrelation und falsche Zeitachsen.

Normalisierung und Parsing

Parser testen: Sind Felder wie src_ip, dst_ip, user, action, rule_id sauber extrahiert?
Schema definieren: Einheitliche Feldnamen und Typen erhöhen die Wiederverwendbarkeit von Use Cases.
Vendor-spezifische Felder mappen: Damit Regeln nicht an Produktwechseln zerbrechen.

Eindeutige Asset- und User-Zuordnung

Hostnames standardisieren: Namenskonventionen für Server, Clients, Netzwerkgeräte.
IP↔Asset-Mapping: DHCP, CMDB oder Asset Inventory integrieren.
User↔IP↔Device: VPN-/WLAN-/EDR-Kontext nutzen, um Netzwerkereignisse personell einzuordnen.

Noise reduzieren: Was Sie nicht (oder anders) loggen sollten

Ein SIEM ist schnell überfüllt, wenn Sie alle Denies, Broadcasts, Health-Checks und periodischen Hintergrundjobs ungefiltert einspeisen. Ziel ist, Signal zu erhöhen und Kosten zu kontrollieren.

Broadcast/Multicast-Noise: Häufig nicht sicherheitsrelevant, sollte gefiltert oder aggregiert werden.
Erwartete Denies: Manche Drops sind normal (z. B. Internet-Scans). Sinnvoller ist Aggregation und Schwellenwert-Alarme.
Health Checks: Load Balancer/Monitoring erzeugen viele Events; besser als „known good“ markieren oder in separate Indizes.
Doppelte Quellen: Dasselbe Event nicht mehrfach ingestieren (z. B. Firewall + Collector + Mirror-Parser).

Use Cases: Aus Logs werden verwertbare Erkennungen

Der entscheidende Mehrwert eines SIEM sind nicht Dashboards, sondern Use Cases: definierte Erkennungsregeln, die verdächtige Muster identifizieren und als priorisierte Alarme ausgeben. Gute Use Cases sind konkret, testbar und haben klare Playbooks.

Beispiele für sinnvolle Netzwerk-Use-Cases

Brute Force auf VPN/SSO: viele Fehlversuche in kurzer Zeit, anschließend erfolgreicher Login.
Ungewöhnliche Admin-Aktivität: neue Adminrechte + Login von neuer Quelle + Zugriff auf viele Systeme.
DNS-Anomalien: NXDOMAIN-Spike, ungewöhnliche TLDs, DGA-ähnliche Muster.
Beaconing: regelmäßige Verbindungen zu seltenen Zielen mit konstanten Intervallen.
Exfiltration: ungewöhnlich hohe Upload-Datenmenge aus sensiblen Zonen zu neuen Internetzielen.
Laterale Bewegung: ein Client spricht plötzlich viele Server auf Admin-Ports an (RDP/SSH/SMB).

Qualitätsmerkmale guter Alerts

Kontext: Wer? Welches Gerät? Welche Zone? Welche Regel? Welche Historie?
Priorisierung: Severity nach Risiko der betroffenen Ressource (Identity/DB/Backup höher).
Handlungsanweisung: Was soll ein Analyst jetzt konkret tun (Playbook)?
False-Positive-Prozess: Wie werden Ausnahmen dokumentiert und rezertifiziert?

Korrelationslogik: Warum einzelne Logs selten reichen

Viele echte Vorfälle bestehen aus mehreren Signalen, die einzeln harmlos wirken. Korrelation ist deshalb der Schlüssel: SIEM-Regeln sollten Ereignisse über Zeit und Quellen hinweg zusammenführen.

Identity + Netzwerk: Risky Sign-in + VPN-Login + auffälliger DNS-Traffic
Firewall + Proxy: neue Outbound-Ziele + ungewöhnliche Downloads + nachfolgende C2-Muster
EDR + Netzwerk: verdächtiger Prozessstart + neue Verbindungen zu seltenen Domains

MITRE ATT&CK hilft, solche Ketten strukturiert zu definieren, weil es typische Techniken und ihre Spuren beschreibt: MITRE ATT&CK.

Retention, Compliance und Datenschutz: Logs richtig aufbewahren

Log-Aufbewahrung ist nicht nur eine Kostenfrage, sondern auch Compliance- und Datenschutzthema. Sie sollten definieren, welche Daten wie lange gespeichert werden, wer Zugriff hat und wie Sie Integrität sicherstellen.

Retention nach Zweck: Kurzfristig für schnelle Suche, längerfristig für Forensik/Compliance.
Zugriffskontrolle: RBAC, Audit Trails, getrennte Admin-Rollen.
Datenminimierung: Nur speichern, was erforderlich ist; sensible Inhalte vermeiden oder pseudonymisieren.
Integrität: Manipulationsschutz und nachvollziehbare Audit Logs.

Für organisatorische Leitlinien und Sicherheitsgrundschutz ist das BSI eine hilfreiche Anlaufstelle.

Betriebsroutine: SIEM im Alltag nutzbar halten

Ein SIEM wird schnell wertlos, wenn niemand Regeln pflegt, Parser überprüft und Alerts regelmäßig bewertet. Ein kleiner, konsequenter Betriebskalender verhindert genau das.

Tägliche Routine

Top-Alerts prüfen: echte Incidents vs. False Positives
Neue Quellenfehler erkennen: Collector down, Parser broken, Zeitdrift
„High Value“-Zonen priorisieren: Identity, DMZ, Backup, Admin-Zugänge

Wöchentliche Routine

Regel-Tuning: Schwellenwerte, Ausnahmen, neue Use Cases
Dashboards prüfen: sind KPIs sinnvoll oder reine „Zahlenwände“?
Lessons Learned aus Tickets: welche Alerts waren nützlich, welche nicht?

Monatliche/Quartalsweise Routine

Log-Quellen-Review: neue Systeme integrieren, alte abschalten
Parser-Health: Feldmapping, Normalisierung, Schema-Updates
Use-Case-Portfolio: Abdeckung gegen aktuelle Bedrohungen, Anpassung an neue Anwendungen

Typische Fehler in SIEM-Projekten (und wie Sie sie vermeiden)

„Alles loggen“ ohne Use Cases: führt zu Kosten und Alarmmüdigkeit; besser priorisieren.
Keine Zeitkonsistenz: ohne NTP sind Korrelationen unzuverlässig.
Parser nicht getestet: Events kommen an, sind aber nicht auswertbar.
Keine Ownership: Niemand fühlt sich für Regelpflege, Ausnahmen und Datenqualität verantwortlich.
Zu viele Low-Value-Alerts: lieber wenige, hochwertige Use Cases mit klaren Playbooks.
Keine Integration von Identity: Netzwerk-Events ohne Nutzer-/Gerätebezug verlieren Wert.

Praktische Checkliste: SIEM im Netzwerk richtig aufbauen

Use Cases definiert (z. B. VPN-Bruteforce, DNS-Anomalien, Exfiltration, laterale Bewegung)
Priorisierte Logquellen angebunden (Firewall/NAT, VPN, DNS, Proxy/SWG, Identity, Switch/WLAN)
NTP überall aktiv, einheitliche Zeitbasis und Zeitzonenstrategie
Normalisierung/Parsing getestet (src/dst IP, user, action, rule, bytes, device, zone)
Noise-Strategie umgesetzt (Aggregation, Filter, getrennte Indizes, Schwellenwerte)
Alert-Qualität gesichert (Kontext, Severity, Playbooks, False-Positive-Prozess)
Retention, RBAC und Audit Trails definiert (Compliance und Datenschutz berücksichtigt)
Betriebsroutine etabliert (täglich/wöchentlich/quartalsweise Reviews und Tuning)

Weiterführende Informationsquellen

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

Netzwerkdesign & Topologie-Planung
Router- & Switch-Konfiguration (Cisco IOS)
VLAN, Inter-VLAN Routing
OSPF, RIP, EIGRP (Grundlagen & Implementierung)
NAT, ACL, DHCP, DNS-Konfiguration
Troubleshooting & Netzwerkoptimierung
Packet Tracer Projektentwicklung & Dokumentation
CCNA Lern- & Praxisunterstützung

Lieferumfang:

Konfigurationsdateien
Packet-Tracer-Dateien (.pkt)
Netzwerkdokumentation
Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.