SOC-Betrieb: Wenn Reports zum Leak werden - Versionsgeschichte

Thomas.will: /* SOC-Betrieb: Wenn Reports zum Leak werden */

2026-06-28T11:30:56Z

SOC-Betrieb: Wenn Reports zum Leak werden

Thomas.will: /* SOC-Betrieb: Wenn Reports zum Leak werden */

2026-06-28T11:30:38Z

SOC-Betrieb: Wenn Reports zum Leak werden

Thomas.will am 28. Juni 2026 um 11:29 Uhr

2026-06-28T11:29:50Z

Thomas.will: /* Diskussionsfragen (für den Unterricht) */

2026-06-28T11:22:46Z

Diskussionsfragen (für den Unterricht)

Thomas.will: /* Lücke 1 – Senderseite (Offboarding-/Config-Hygiene) */

2026-06-28T11:21:04Z

Lücke 1 – Senderseite (Offboarding-/Config-Hygiene)

Thomas.will: /* Ausgangslage */

2026-06-28T11:20:45Z

Ausgangslage

Thomas.will: /* Ausgangslage */

2026-06-28T11:00:38Z

Ausgangslage

Thomas.will: /* Ausgangslage */

2026-06-28T10:54:41Z

Ausgangslage

Thomas.will: /* Ausgangslage */

2026-06-28T10:50:03Z

Ausgangslage

Thomas.will: Die Seite wurde neu angelegt: „= SOC-Betrieb: Wenn Reports zum Leak werden = ''Fallstudie für den Kurs '''Cybersec-2 / SOC'''. Realer Vorfall, zu Lehrzwecken anonymisiert. Dient als Einsti…“

2026-06-28T10:42:18Z

Die Seite wurde neu angelegt: „= SOC-Betrieb: Wenn Reports zum Leak werden = ''Fallstudie für den Kurs '''Cybersec-2 / SOC'''. Realer Vorfall, zu Lehrzwecken anonymisiert. Dient als Einsti…“

Neue Seite

= SOC-Betrieb: Wenn Reports zum Leak werden =

''Fallstudie für den Kurs '''Cybersec-2 / SOC'''. Realer Vorfall, zu Lehrzwecken anonymisiert. Dient als Einstieg in die Kapitel Offboarding-Hygiene, Asset-/EOL-Lifecycle und Datenklassifizierung.''

Ein wöchentlicher '''Sophos Executive Report''' einer Sophos-UTM-9-Firewall landet seit Jahren in einem Postfach – adressiert an einen Dienstleister, der den Kunden seit rund '''8 Jahren nicht mehr betreut'''. Aufgefallen ist es niemandem, denn die Mail wurde die ganze Zeit als '''Spam''' einsortiert.

Der Fall ist deshalb so wertvoll, weil '''beide Seiten''' Sicherheitshygiene versäumt haben: die '''Senderseite''' (der Ex-Kunde) ''und'' die '''Empfängerseite''' (wir).

== Ausgangslage ==

;Was ankommt
:Ein Sophos Executive Report, Typ ''weekly'', mit vollständigem Posture-Überblick der Perimeter-Firewall.
;Empfänger
:Ein ehemaliger Dienstleister, dessen Vertragsverhältnis vor ca. 8 Jahren endete.
;Reaktion bisher
:Keine – die Mail wurde serverseitig als Spam klassifiziert und nie gesichtet.

{| class="wikitable"
|+ Auszug aus dem Report (anonymisiert)
! Feld !! Wert (anonymisiert) !! Aussagekraft für einen Angreifer
|-
| Organization || Kunde-XY || Zuordnung Firma ↔ Infrastruktur
|-
| Country / City || DE / <Ort> || Geo-/Standortkontext
|-
| Serial || S1B0xxxxxxxx || eindeutige Geräteidentität, Lizenz-/Asset-Mapping
|-
| License ID || 16xxxxx || Lizenz-/Vertragsstatus
|-
| Hostname || chantal.kunde.example || Naming-Convention, internes Schema
|-
| Firmware Version || '''9.724-2''' || exakte Version → direkter CVE-Lookup
|-
| Uptime || 67 Tage || Patch-/Reboot-Verhalten, Wartungsfenster
|-
| Traffic / Connections || 225 GB / 4,4 Mio. || Lastprofil, Geschäftszeiten ableitbar
|-
| Blocked by Firewall / IPS || 1,7 Mio. / 0 || Schutzniveau, IPS-Status
|}

{{Hinweis|Das ist kein Newsletter, sondern '''Aufklärungsmaterial'''. Allein Hostname + Firmware-Version genügen für einen gezielten CVE-Abgleich. Ein solcher Report ist daher als '''vertraulich''' zu klassifizieren – auf beiden Seiten der Leitung.}}

== Lücke 1 – Senderseite (Offboarding-/Config-Hygiene) ==

In 8 Jahren hat niemand die Report-Empfängerliste der Firewall angefasst. Das ist das sichtbare Symptom – die eigentliche Frage lautet:

;Wenn die Empfängerliste nie aufgeräumt wurde …
:… was ist dann mit Admin-Accounts, VPN-Profilen, RADIUS-/LDAP-Bindings, Firewall-Objekten und API-Tokens aus der gemeinsamen Zeit?
;Kernaussage
:Ein vergessener Report-Empfänger ist ein '''Indikator''' für fehlendes Offboarding, nicht das eigentliche Problem.

=== Asset- und EOL-Lifecycle ===

Die Box läuft auf Sophos '''UTM 9.724-2'''.

;End-of-Life
:Sophos UTM 9 auf SG-Hardware erreicht am '''30.06.2026''' das endgültige End-of-Life: danach keine Firmware-Updates, keine Security-Patches, kein Hersteller-Support.
;Renewals
:Seit dem 01.01.2026 sind keine regulären Lizenz-Verlängerungen mehr möglich.
;Bewertung
:Eine ungepflegte Perimeter-Firewall, die unmittelbar vor dem EOL steht und weiterläuft, während niemand auf sie schaut. Routing/NAT funktionieren weiter – die Schutzwirkung (Web-/Mail-Filter, IPS) verfällt mit ausbleibenden Signaturen schleichend.

== Lücke 2 – Empfängerseite (das Signal im Rauschen) ==

Der Report kam jahrelang an – und wurde nie gesehen, weil der '''Spam-Filter''' ihn weggefiltert hat.

;Lektion
:Ein sicherheitsrelevantes Artefakt verschwand im Rauschen. Das ist im Kleinen genau das, was im SOC im Großen passiert: ''alert fatigue'' und ''misclassification'' führen dazu, dass echte Signale untergehen.
;Übertragung auf den SOC-Betrieb
:Reports und Alerts sind selbst ein '''Asset''', das klassifiziert, geroutet und überwacht werden muss. Ein Alert, den niemand liest, ist kein Schutz, sondern eine ''falsche Sicherheit''.
;Anschluss an unser Lab
:Im Wazuh-Stack routen wir Alerts gezielt an die <code>soc</code>-Mailbox (Roundcube). Genau hier gilt: Wenn diese Mails im Spam landen oder ungelesen bleiben, ist die gesamte Detection-Kette wertlos – egal wie gut Decoder und Rules sind.

== DSGVO-Einordnung ==

;Status
:Wir sind '''ungewollter Dritt-Empfänger''' von Betriebsdaten einer fremden Organisation – ohne Rechtsgrundlage.
;Konsequenz
:Stillschweigend wegfiltern ist kein sauberer Umgang. Der korrekte Weg ist eine kurze, sachliche Benachrichtigung des Verantwortlichen und anschließendes Austragen/Filtern.

== Handlungsempfehlung ==

;1. Benachrichtigen
:Kurze Mail an den Verantwortlichen: „Wir empfangen weiterhin eure Sophos-Executive-Reports, bitte aus den Empfängern entfernen. Hinweis nebenbei: UTM 9 läuft am 30.06.2026 aus – Migration einplanen.“
;2. Dokumentieren
:Vorfall (anonymisiert) als Lessons-Learned festhalten.
;3. Filtern/Austragen
:Bei Reaktion: Austragung bestätigen lassen. Bei Nicht-Reaktion: Filterregel mit Begründung dokumentieren – nicht kommentarlos löschen.

== Offboarding-Checkliste (Kunden-Sicht) ==

''Was beim Vertragsende eines Dienstleisters abgearbeitet werden muss:''

* Report-/Notification-Empfänger entfernen
* Admin- und WebAdmin-Accounts deaktivieren/löschen
* VPN-Profile (Site-to-Site & Remote) prüfen und entziehen
* RADIUS-/LDAP-/SSO-Bindings des Dienstleisters auflösen
* API-Tokens / Service-Accounts rotieren
* Firewall-Objekte & Regeln mit Bezug zum Dienstleister bereinigen
* Geteilte Secrets (PSK, Zertifikate, Passwörter) rotieren
* Asset im Lifecycle führen → EOL-Termine überwachen

== Lernziele ==

;Offboarding-Hygiene
:Wer räumt nach Vertragsende auf? Welche Zugänge überleben Jahre, weil sie niemand kennt?
;Asset-/EOL-Management
:Warum eine EOL-Firewall am Perimeter ein konkretes Risiko ist – nicht nur ein Compliance-Häkchen.
;Datenklassifizierung
:Warum ein „harmloser“ Wochenreport vertraulich ist und wie viel Recon-Wert in scheinbaren Routinedaten steckt.
;Signal vs. Rauschen
:Warum ein Alert, den niemand liest, keinen Schutz bietet – Brücke zum Wazuh-/SOC-Alerting.

== Diskussionsfragen (für den Unterricht) ==

* Welche der gelisteten Report-Felder wären für einen gezielten Angriff am wertvollsten – und warum?
* Was würdet ihr aus dem Report über die Geschäftszeiten und das Wartungsverhalten ableiten?
* Wie verhindert ihr im eigenen SOC, dass ein echter Alert wie hier im Spam verschwindet?
* Welche Offboarding-Schritte fehlen in der Checkliste oben für eure Umgebung?

[[Kategorie:Cybersec-2]]
[[Kategorie:SOC]]
[[Kategorie:Lessons Learned]]

← Nächstältere Version		Version vom 28. Juni 2026, 11:30 Uhr
Zeile 1:		Zeile 1:
	= SOC-Betrieb: Wenn Reports zum Leak werden =		= SOC-Betrieb: Wenn Reports zum Leak werden =
−	[[Datei:Firewall23.png]]	+	[[Datei:Firewall23.png\|600px]]

← Nächstältere Version		Version vom 28. Juni 2026, 11:30 Uhr
Zeile 1:		Zeile 1:
	= SOC-Betrieb: Wenn Reports zum Leak werden =		= SOC-Betrieb: Wenn Reports zum Leak werden =
−	[[Datei:~~Firewall~~.png]]	+	[[Datei:Firewall23.png]]

← Nächstältere Version		Version vom 28. Juni 2026, 11:29 Uhr
Zeile 1:		Zeile 1:
	= SOC-Betrieb: Wenn Reports zum Leak werden =		= SOC-Betrieb: Wenn Reports zum Leak werden =
		+	[[Datei:Firewall.png]]
		+

	''Fallstudie für den Kurs '''Cybersec-2 / SOC'''. Realer Vorfall, zu Lehrzwecken anonymisiert. Dient als Einstieg in die Kapitel Offboarding-Hygiene, Asset-/EOL-Lifecycle und Datenklassifizierung.''		''Fallstudie für den Kurs '''Cybersec-2 / SOC'''. Realer Vorfall, zu Lehrzwecken anonymisiert. Dient als Einstieg in die Kapitel Offboarding-Hygiene, Asset-/EOL-Lifecycle und Datenklassifizierung.''

@@ Zeile 202: / Zeile 202: @@
 :Warum ein Alert, den niemand liest, keinen Schutz bietet – Brücke zum Wazuh-/SOC-Alerting.
 [[Kategorie:Cybersec-2]]
 [[Kategorie:SOC]]
 [[Kategorie:Lessons Learned]]

@@ Zeile 51: / Zeile 51: @@
 == Lücke 1 – Senderseite (Offboarding-/Config-Hygiene) ==
-In 8 Jahren hat niemand die Report-Empfängerliste der Firewall angefasst. Das ist das sichtbare Symptom – die eigentliche Frage lautet:
+In den Jahren hat niemand die Report-Empfängerliste der Firewall angefasst. Das ist das sichtbare Symptom – die eigentliche Frage lautet:
 ;Wenn die Empfängerliste nie aufgeräumt wurde …

@@ Zeile 20: / Zeile 20: @@
 :Ein Sophos Executive Report, Typ ''weekly'', mit vollständigem Posture-Überblick der Perimeter-Firewall.
 ;Empfänger
-:Ein ehemaliger Dienstleister, dessen Vertragsverhältnis vor ca. 8 Jahren endete.
+:Ein ehemaliger Dienstleister, dessen Vertragsverhältnis vor Jahren endete.
 ;Reaktion bisher
 :Keine – die Mail wurde serverseitig als Spam klassifiziert und nie gesichtet.

@@ Zeile 1: / Zeile 1: @@
 = SOC-Betrieb: Wenn Reports zum Leak werden =
@@ Zeile 38: / Zeile 46: @@
 | Blocked by Firewall / IPS || 1,7 Mio. / 0 || Schutzniveau, IPS-Status
 |}
 == Lücke 1 – Senderseite (Offboarding-/Config-Hygiene) ==

@@ Zeile 39: / Zeile 39: @@
 |}
-{{Hinweis|Das ist kein Newsletter, sondern '''Aufklärungsmaterial'''. Allein Hostname + Firmware-Version genügen für einen gezielten CVE-Abgleich. Ein solcher Report ist daher als '''vertraulich''' zu klassifizieren – auf beiden Seiten der Leitung.}}
+{{Vorlage:Hinweis|Das ist kein Newsletter, sondern '''Aufklärungsmaterial'''. Allein Hostname + Firmware-Version genügen für einen gezielten CVE-Abgleich. Ein solcher Report ist daher als '''vertraulich''' zu klassifizieren – auf beiden Seiten der Leitung.}}
 == Lücke 1 – Senderseite (Offboarding-/Config-Hygiene) ==