Erkennung von Netzwerkangriffen

Angreifer, die den Perimeter überwunden haben, bewegen sich durch das Netzwerk, sprechen mit Command-Servern und kopieren Daten nach außen. Endpunkt-Agenten und Protokolle übersehen nicht verwaltete Geräte, IoT und verschlüsselten Verkehr. Network Detection and Response (NDR) verbindet signaturbasiertes IDS mit ML-Basislinien des normalen Verkehrs, um ein solches Verhalten sichtbar zu machen, und LLMs fassen die entstehenden Alarme inzwischen zusammen und priorisieren sie.

Problem & Nutzen

• Heute: Viele Organisationen betreiben ein signaturbasiertes IDS/IPS auf der Firewall plus ein SIEM. Signaturen erfassen bekannte Werkzeuge; sie übersehen neuartige Schadsoftware, den Missbrauch legitimer Protokolle, Living-off-the-Land-Aktivitäten und langsamen Datenabfluss („Low-and-Slow“). Die Regelabstimmung erfolgt manuell, und das Alarmvolumen ist hoch.
• KI-Nutzen: Unüberwachte Modelle lernen das Verhalten je Gerät und je Segment und melden Abweichungen. Überwachte Klassifikatoren bewerten verschlüsselte Datenflüsse und DNS (z. B. DGA, Tunneling) anhand von Metadaten, ohne die Nutzdaten zu entschlüsseln. LLMs erklären Alarme und verkürzen die Analystenzeit (siehe SEC-001).
• Warum jetzt (EU): NIS2 verlangt von wesentlichen und wichtigen Einrichtungen Maßnahmen zur Erkennung und Behandlung von Sicherheitsvorfällen, und die Meldepflichten (Frühwarnung innerhalb von 24 h) machen frühe Erkennung zu einer Compliance-Frage [1]. DORA legt Finanzunternehmen vergleichbare Pflichten auf [2].
• Einschränkung: Veröffentlichte Genauigkeiten auf Datensätzen wie CIC-IDS2017 oder UNSW-NB15 sind oft nahezu perfekt, überzeichnen aber bekanntermaßen die Leistung in der Praxis, wegen Artefakten der Datensätze und Verteilungsverschiebung; testen Sie immer mit Ihrem eigenen Verkehr [7].

Varianten

• KMU: verwalteter Erkennungsdienst oder Firewall mit eingebautem IPS und Cloud-Analytik; kein eigenes SOC.
• Enterprise / öffentlicher Sektor: NDR-Sensoren an den Engstellen von Rechenzentrum, Campus, Cloud und Außenstandorten, die SIEM/XDR speisen.
• Cloud-nativ: Analyse von Cloud-Flow-Logs und virtueller Verkehrsspiegelung in AWS, Azure und GCP.
• OT-/IoT-Segmente: passive Überwachung mit Protokollkenntnis — siehe SEC-015.
• Privatnutzung: ein IDS auf dem heimischen Router (z. B. OPNsense mit Suricata) ist möglich, aber selten nötig.

So funktioniert es

1. traffic (SPAN/TAP, cloud mirroring, flow logs)
2. sensor: protocol parsing, metadata extraction (Zeek / Suricata EVE JSON)
3. signature engine (Suricata rules) + threat-intel matching
4. feature extraction (flows, DNS, TLS fingerprints such as JA3/JA4, timing)
5. ML scoring (baseline anomalies, supervised classifiers, graph analysis of host relations)
6. correlation & enrichment (asset, identity, vulnerability context)
7. LLM summary + ATT&CK mapping
8. SOC triage (human)
9. response: block / quarantine via firewall, NAC, EDR (approval for high-impact actions)

• Signaturschicht: deterministisch, erklärbar, günstig; bleibt das Fundament.
• Verhaltensschicht: Autoencoder, Isolation Forests, Sequenz- und Graphmodelle über Flow-Merkmale; Basislinien je Entität, die über Tage bis Wochen gelernt werden.
• Verschlüsselter Verkehr: Klassifikation anhand von Handshake-Fingerabdrücken, Paketgrößen und Zeitverhalten, nicht anhand des Inhalts.
• Mensch-in-der-Schleife (Human-in-the-Loop): Analysten bestätigen Vorfälle; automatisches Blockieren beschränkt sich auf Maßnahmen mit hoher Sicherheit und geringer Reichweite; Rückmeldungen stimmen die Schwellwerte ab.

Datenaufbereitung

Die Netzwerkerkennung benötigt Verkehrs-Metadaten oder Paketmitschnitte von den Stellen, an denen der Verkehr entlangläuft: Firewall und Mirror-Ports der Switches, DNS- und Proxy-Protokolle, NetFlow/IPFIX sowie Cloud-Flow-Logs. In einem KMU liegen diese Daten in der Firewall-Appliance, manchmal nur in kurzen rollierenden Puffern, und werden selten zentral gespeichert.

Typische Lücken: kein Sensor an der richtigen Netzwerkposition, verschlüsselter Verkehr ohne Einsicht, flache Netze, in denen alles „intern“ aussieht, unbekannte Geräte (IoT, Drucker, Maschinen), fehlendes Asset-Inventar und keine saubere Basislinie, weil möglicherweise schon Infektionen vorhanden sind.

Schritte der Aufbereitung: 1. Ein Inventar der Assets und des Netzwerks aufbauen (siehe PREP-001, PREP-005) und die Segmente aufzeichnen. 2. Sensoren platzieren oder Flow-Export am Perimeter und zwischen den wichtigen Segmenten aktivieren (Suricata, Zeek, ntopng). 3. Protokolle in einen zentralen Speicher mit synchronisierter Zeit (NTP) und gemeinsamem Schema weiterleiten. 4. 2 bis 4 Wochen bekannten, unauffälligen Verkehr als Basislinie sammeln und bekannte Scanner und Administrationswerkzeuge labeln (PREP-020). 5. Festlegen, welche Nutzdaten gespeichert werden dürfen; meist nur Metadaten, bei Mitschnitten mit kurzer Aufbewahrung (PREP-025).

Grober Anteil am Aufwand: 30 bis 40 Prozent, überwiegend Sensorplatzierung und Inventar. Nutzen Sie GUIDE-003 für eine schnelle Bereitschaftsprüfung.

Umsetzungswege

Welcher Weg für wen

• KMU: Weg A. Next-Generation-Firewalls und verwaltete Erkennungsdienste mit eingebautem ML (MDR mit Hosting in der EU) decken den Standardfall ohne internes Fachwissen ab.
• Enterprise: Weg C. Netzwerktelemetrie ist sensibel und umfangreich, daher sind Cloud- oder Preise pro GB teuer; Suricata/Zeek mit eigenen Modellen lassen sich in das gemeinsame SIEM integrieren.
• Entwickler: Weg C. Suricata, Zeek und offene Datensätze auf HW1 sind der natürliche Stack für Forschung und Abstimmung.
• Öffentlicher Sektor: Weg C. Souveränitäts- und Vergaberegeln sprechen für selbst betriebene Sensoren mit offenen, prüfbaren Regeln.

Weg A — Kaufen (Standardsoftware) (für die meisten empfohlen)

• NDR-Plattformen: Darktrace, Vectra AI, ExtraHop Reveal(x), Corelight (Zeek-basiert), Cisco Secure Network Analytics, Arista NDR, Trend Micro, Fortinet FortiNDR, Palo Alto Networks, Check Point. EU-Anbieter und -Betreiber: Stormshield (FR, Netzwerksicherheit), Gatewatcher (FR, NDR), Sekoia.io (FR, SIEM/XDR), Atos/Eviden und Orange Cyberdefense mit verwalteter Erkennung.
• In die Firewall integriertes IPS: FortiGate, Palo Alto, Sophos, Stormshield; für KMU ausreichend.
• Prüfen: Datenstandort der Telemetrie in der EU, Umgang mit verschlüsseltem Verkehr, Durchsatz der Sensoren, SIEM-/SOAR-Integration, Nachweis der ATT&CK-Abdeckung, Erklärbarkeit der Erkennungen.
• Wählen Sie A, wenn: kein internes Team für Detection Engineering vorhanden ist; die meisten KMU sollten einen verwalteten Dienst mit einem 24/7-SOC bevorzugen.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Cloud-native Erkennung: AWS GuardDuty und VPC Traffic Mirroring, Microsoft Defender for Cloud / Sentinel mit Azure-Netzwerkanalytik, Google Cloud IDS (auf Basis von Palo Alto) [3].
• Pipeline: Sensorprotokolle → SIEM (Microsoft Sentinel, Elastic, Splunk, EU: Sekoia, Wazuh-gehostet) → eigene ML-Jobs und ein LLM (Endpunkte in EU-Regionen) zur Zusammenfassung von Alarmen, mit Prompts, die personenbezogene Daten minimieren.
• Wählen Sie B, wenn: Sie Cloud-first arbeiten und eigene Anreicherung benötigen.

Weg C — Selbst betreiben (Open Source)

• Sensoren: Suricata (signaturbasiertes IDS/IPS, Ausgabe als EVE JSON) [4], Zeek (Protokoll-Metadaten und Skripting) [5], Arkime (vollständiger Paketmitschnitt/Suche), Security Onion (Distribution, die diese mit Elastic bündelt) [6].
• Regeln: Emerging Threats Open, Regelsätze der Community; Erkennungen im Sigma-Stil auf den entstehenden Protokollen.
• ML: scikit-learn, PyTorch oder Elastic ML auf Zeek-/Flow-Daten; JA3/JA4-Fingerabdrücke. Optional ein kleines lokales LLM (Klasse Qwen, Llama, Mistral über vLLM/Ollama) zur Erklärung von Alarmen.
• Hardware: HW1 für Sensoren bis zu einigen Gbit/s mit abgestimmter Erfassung (AF_PACKET); das SIEM-/ML-Backend braucht in der Regel einen separaten Server. Betriebsaufwand: ein bis zwei Ingenieure in Teilzeit für Regelabstimmung und Basislinien.

Weg D — Eigenes Training

Lohnt sich für große Netze mit besonderen Protokollen oder für die Forschung. Erfordert über Wochen gelabelten unauffälligen Verkehr sowie gelabelte Angriffs- oder Red-Team-Daten; öffentliche Datensätze dienen nur der Methodenentwicklung [7]. Planen Sie wegen Drift ein kontinuierliches Nachtrainieren ein.

Stand der Technik (2026)

• Hybride Erkennung (Signaturen + Verhalten + Bedrohungsinformationen) ist in kommerziellem NDR Standard; Anbieter ergänzen generative KI-Assistenten für Untersuchung und Hunting in natürlicher Sprache.
• Forschungsrichtungen: Graph Neural Networks über Kommunikationsgraphen von Hosts, Transformer-Modelle auf Flow-Sequenzen, selbstüberwachtes Vortraining auf Verkehr, Federated Learning über Standorte hinweg.
• Verschlüsselung (TLS 1.3, QUIC, verschlüsseltes DNS) verlagert die Erkennung auf Metadaten und Fingerabdrücke; Entschlüsselung an Gateways bringt Datenschutz- und Rechtslasten mit sich.
• Grenzen und Fehlerbilder: Fehlalarme durch neues, aber legitimes Verhalten (Migrationen, Backups); Vergiftung der Basislinie durch Angreifer, die während des Trainings präsent sind; gezielte Umgehung von ML-Klassifikatoren; Concept Drift; Benchmark-Datensätze, die die Produktion nicht abbilden; blinde Flecken, wo keine Sensoren stehen; ML-Werte, die Analysten nicht erklären können.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack: SIEM/XDR und Alarm-Triage (SEC-001), UEBA (SEC-005), Schadsoftware-Analyse (SEC-003), Bedrohungsinformationen (SEC-008), OT-/IoT-Überwachung (SEC-015) teilen Protokoll-Pipelines, Werkzeuge zur Anomalieerkennung und Anreicherungsdaten.
• Compliance: SEC-009 ordnet die Erkennungsabdeckung den Kontrollen von NIS2/DORA/ISO 27001 zu.
• Hardware: Sensoren auf HW1; die optionale LLM-Triage kann sich einen HW2-Server mit anderen SEC-Anwendungsfällen teilen.

Aufwand, Kosten & Kennzahlen

• Weg A: Wochen bei SaaS/verwalteten Diensten; Lizenz in der Regel nach Durchsatz oder Anzahl der Sensoren plus Sensor-Hardware.
• Weg B: 2–4 Monate für Integration und Abstimmung.
• Weg C: 3–6 Monate bis zu stabiler Erkennungsqualität; die Kosten sind überwiegend Personalzeit.
• Kostentreiber: Platzierung und Durchsatz der Sensoren, Speicher für die Aufbewahrung von Metadaten/PCAP, Abstimmungsaufwand.
• Kennzahlen: mittlere Zeit bis zur Erkennung und Reaktion, Trefferquote der geprüften Alarme, Fehlalarme je Analystin/Analyst und Tag, Abdeckung der ATT&CK-Techniken (durch Purple-Team-Übungen validiert), Anteil der überwachten Segmente und Cloud-Konten, Paketverlustrate der Sensoren.

Menschen & Veränderung

Die Netzwerkanalyse berührt den Verkehr aller Beschäftigten, kündigen Sie sie daher an, auch wenn das Ziel die Angriffserkennung ist.

• Betriebsrat: ja. Netzwerküberwachung ist objektiv geeignet, Verhalten zu überwachen (§ 87 Abs. 1 Nr. 6 BetrVG, BAG), auch wenn nur Angriffe im Fokus stehen. Vereinbaren Sie in einer Betriebsvereinbarung die Analyse nur von Metadaten, die Aufbewahrung, Zugriffsrechte und den Ausschluss individueller Leistungsbeurteilung; § 90 Abs. 1 Nr. 3 verlangt rechtzeitige Unterrichtung. In öffentlichen Stellen ist der Personalrat beteiligt.
• Datenschutzbeauftragte(r): IP-Adressen und DNS-Abfragen sind personenbezogene Daten; klären Sie Rechtsgrundlage, Aufbewahrung und AVV (Art. 28 DSGVO). Eine DSFA ist meist nur erforderlich, wenn Paketinhalte oder umfangreiches Profiling Einzelner im Spiel sind.
• IT und IT-Sicherheit planen Sensorplatzierung, Alarm-Triage und Reaktions-Playbooks; die Geschäftsleitung entscheidet über Budget und Zuständigkeiten (intern oder MDR).
• KI-Kompetenz: Unterstützen Sie die Personen, die Alarme bearbeiten (Art. 4 KI-Verordnung), mit kurzen Schulungen zu Fehlalarmen und Abstimmung.
• Pilot: Beginnen Sie in einem Segment (z. B. Servernetz), bevor Sie unternehmensweit ausrollen.
• Typische Sorgen: „Lesen Sie meinen Verkehr mit?“ und Alarmmüdigkeit. Antworten Sie mit einer klaren Erklärung zum Datenumfang und einer Abstimmungsphase; Blockaden bleiben zunächst von Menschen freigegeben.

Siehe GUIDE-004, GUIDE-005 und GUIDE-011.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): in der Regel minimales Risiko; ein Anomalie-Detektor für Sicherheit ist kein Anwendungsfall nach Anhang III. Ausnahme: KI als Sicherheitskomponente bei der Verwaltung und dem Betrieb kritischer digitaler Infrastruktur kann nach Anhang III Nr. 2 hochriskant sein — klären Sie mit der Rechtsabteilung, ob das System Infrastruktur steuert. Würde man die Netzwerküberwachung nutzen, um Verhalten oder Emotionen von Beschäftigten abzuleiten, entstünden eigene Probleme (Art. 5 verbietet Emotionserkennung am Arbeitsplatz). KI-Kompetenz (Art. 4) gilt [8].
• DSGVO: IP-Adressen, DNS-Abfragen und URLs sind personenbezogene Daten. Rechtsgrundlage meist berechtigtes Interesse (Art. 6 Abs. 1 lit. f), gestützt durch Erwägungsgrund 49 zur Netzsicherheit; dokumentieren Sie eine Interessenabwägung, minimieren Sie die Erfassung von Nutzdaten, legen Sie Aufbewahrungsfristen fest und führen Sie eine DSFA durch, wo die Überwachung umfangreich ist [9]. In Deutschland gelten für die Überwachung von Beschäftigten und die Privatnutzung die Mitbestimmung des Betriebsrats (§ 87 BetrVG) und das Fernmeldegeheimnis nach TTDSG/TDDDG.
• NIS2 / DORA / ISO 27001: Pflichten zur Erkennung und zur Meldung von Vorfällen [1][2].
• Risiken und Gegenmaßnahmen: Alarmmüdigkeit (abstimmen, priorisieren), Datenschutzrisiko durch Entschlüsselung (Umfang begrenzen, Zugriffskontrolle), Telemetrie der Anbieter, die die EU verlässt (vertragliche und regionale Kontrollen), Umgehung von Modellen (mehrschichtige Verteidigung), Übermaß an Automatisierung (Freigabeschranken beim Blockieren).

Erste Schritte

1. Netzwerk-Engstellen und Cloud-Konten erfassen; entscheiden, wo Sensoren oder Flow-Logs die beste Sichtbarkeit liefern.
2. Mit Suricata plus Zeek (oder einer Testversion eines verwalteten NDR) im passiven Modus auf einem Segment beginnen; ins SIEM protokollieren.
3. Basislinien 2–4 Wochen lernen lassen; Alarme prüfen und labeln; Regeln und Schwellwerte abstimmen.
4. Eine Purple-Team- oder Atomic-Red-Team-Übung durchführen, um die ATT&CK-Abdeckung zu messen.
5. Dokumentation zu DSFA/Betriebsrat abschließen und die Aufbewahrung festlegen, dann automatisierte Reaktion für risikoarme Maßnahmen ergänzen.

Quellen

1. Directive (EU) 2022/2555 (NIS2) — https://eur-lex.europa.eu/eli/dir/2022/2555/oj
2. Regulation (EU) 2022/2554 (DORA) — https://eur-lex.europa.eu/eli/reg/2022/2554/oj
3. Google Cloud IDS documentation — https://cloud.google.com/intrusion-detection-system/docs
4. Suricata documentation — https://docs.suricata.io/
5. Zeek documentation — https://docs.zeek.org/
6. Security Onion documentation — https://docs.securityonion.net/
7. Engelen et al., "Troubleshooting an Intrusion Detection Dataset: the CICIDS2017 Case Study" — https://intrusion-detection.distrinet-research.be/WTMC2021/Resources/wtmc2021_Engelen_Troubleshooting.pdf
8. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
9. Regulation (EU) 2016/679 (GDPR), recital 49 — https://eur-lex.europa.eu/eli/reg/2016/679/oj
10. MITRE ATT&CK — https://attack.mitre.org/