Der Hacker ist drin. Jetzt beginnt das eigentliche Sicherheitsproblem. Bei großen Cyberangriffen konzentriert sich die öffentliche Diskussion fast immer zuerst auf dieselbe Frage: Wie sind die Angreifer hineingekommen? War es Phishing, eine ungepatchte Schwachstelle, gestohlene Zugangsdaten, eine offene VPN-Appliance oder ein kompromittierter Dienstleister? Diese Frage ist technisch wichtig, aber sie beschreibt nur den Anfang eines Angriffs. Für die Bewertung der tatsächlichen Sicherheitsreife einer Organisation ist viel entscheidender, was nach dem ersten erfolgreichen Zugriff passiert. Moderne Informationssicherheit muss davon ausgehen, dass ein Initial Access irgendwann gelingt. Kein Patchmanagement ist perfekt, kein Benutzer unfehlbar, kein IAM vollständig frei von Fehlkonfigurationen und keine Software ohne Schwachstellen. Genau deshalb darf die Sicherheitsarchitektur nicht darauf beruhen, dass niemand jemals hineinkommt. Sie muss darauf ausgelegt sein, dass ein Angreifer nach einem ersten Zugriff möglichst wenig damit anfangen kann. Nach dem Initial Access beginnt die eigentliche Angriffskette. Frameworks wie MITRE ATT&CK beschreiben diese Phasen sehr klar: Discovery, Credential Access, Privilege Escalation, Persistence, Lateral Movement, Collection, Command and Control und schließlich Exfiltration oder Impact. Der kompromittierte Rechner ist also nicht das Ziel, sondern der Ausgangspunkt. Von dort versucht ein Angreifer, weitere Systeme zu identifizieren, Zugangsdaten auszulesen, Service Accounts zu finden, Gruppenmitgliedschaften zu analysieren, administrative Rechte zu erweitern, Dateifreigaben, Datenbanken und Backup-Systeme zu lokalisieren und sich möglichst geräuschlos weiter durch die Umgebung zu bewegen. Genau hier entscheidet sich der sogenannte Blast Radius. Ein kompromittiertes Benutzerkonto sollte niemals automatisch den Zugriff auf große Teile einer Organisation ermöglichen. Ein normaler Client sollte nicht beliebig Domain Controller, Backup-Systeme, Datenbanken, Managementschnittstellen und zentrale Fileserver erreichen können. Service Accounts sollten keine historischen Sonderrechte mit sich herumtragen, nur weil irgendwann einmal irgendeine Anwendung sie gebraucht hat. Und Dateifreigaben sollten nicht für tausende Benutzer sichtbar sein, nur weil niemand die Berechtigungen seit Jahren überprüft hat. Das ist der eigentliche Sinn von Zero Trust. Nicht als Produktetikett, sondern als Architekturprinzip. Vertrauen wird nicht vorausgesetzt, sondern immer wieder überprüft. Zugriff wird nach dem Prinzip Least Privilege vergeben. Administrative Rechte werden möglichst zeitlich begrenzt. Systeme dürfen nur miteinander kommunizieren, wenn es dafür einen konkreten Grund gibt. Und Identitäten werden heute mindestens genauso kritisch behandelt wie klassische Netzwerkgrenzen. Denn in modernen Infrastrukturen ist häufig nicht mehr die Firewall der eigentliche Perimeter, sondern die Identität. Active Directory, Entra ID, MFA, Conditional Access, PAM und Service Accounts sind deshalb zentrale Sicherheitskomponenten. Ein Angreifer, der Zugang zu einem normalen Benutzerkonto erhält, versucht typischerweise als Nächstes genau dort weiterzukommen. Pass-the-Hash, Pass-the-Ticket, Kerberoasting, Credential Dumping, Token Theft oder der Missbrauch schlecht abgesicherter Service Accounts sind keine exotischen Angriffsmethoden. Sie gehören seit Jahren zum Standardrepertoire professioneller Angreifer. Deshalb ist es sinnvoll, die eigene Umgebung auch aus Sicht des Angreifers zu betrachten. Werkzeuge wie BloodHound oder SharpHound zeigen beispielsweise, welche privilegierten Pfade innerhalb eines Active Directory existieren. Die entscheidende Frage ist dann nicht nur, wer formal Administrator ist, sondern ob ein normaler Benutzer über zwei oder drei Zwischenschritte faktisch administrative Rechte erreichen kann. Genau solche Angriffspfade werden in historisch gewachsenen Umgebungen häufig unterschätzt. Dasselbe gilt für die Netzwerksegmentierung. Zwei Systeme mit unterschiedlichen IP-Adressen sind noch lange nicht sinnvoll segmentiert. Entscheidend ist, welche Verbindungen tatsächlich erlaubt sind. Kann ein normaler Client per SMB auf zahlreiche Server zugreifen? Ist RDP organisationsweit verfügbar? Kann PowerShell Remoting praktisch überall verwendet werden? Sind Managementschnittstellen aus normalen Benutzersegmenten erreichbar? Kann ein Arbeitsplatzrechner direkt Backup-Systeme ansprechen? Je häufiger solche Fragen mit Ja beantwortet werden, desto größer ist der mögliche Schaden nach einem erfolgreichen Initial Access. An dieser Stelle kommen EDR-Systeme ins Spiel. Produkte wie CrowdStrike Falcon, Microsoft Defender for Endpoint oder SentinelOne sind nicht einfach bessere Virenscanner. Sie sollen Verhalten sichtbar machen. Prozessstarts, Parent-Child-Beziehungen, PowerShell-Aufrufe, Registry-Änderungen, Netzwerkverbindungen, Persistenzmechanismen und verdächtige Credential-Zugriffe erzeugen Telemetrie. Wenn plötzlich Word eine PowerShell startet, diese anschließend Credentials ausliest, danach SMB-Verbindungen zu zahlreichen Hosts aufbaut und kurz darauf große Datenmengen archiviert werden, dann ist möglicherweise keiner dieser Schritte für sich allein eindeutig. Die Kette ist es aber sehr wohl. Genau deshalb ist ein SIEM wichtig. Systeme wie Microsoft Sentinel, Splunk, QRadar oder Elastic Security führen Ereignisse aus verschiedenen Quellen zusammen. Firewall, VPN, Active Directory, Entra ID, EDR, Proxy, DNS, Mail, Server, Datenbanken und Cloud-Plattformen liefern jeweils einzelne Puzzleteile. Der Wert eines SIEM entsteht jedoch nicht dadurch, dass Milliarden Logzeilen gespeichert werden. Er entsteht erst dann, wenn daraus sinnvolle Detection-Use-Cases gebaut werden. Das ist der Unterschied zwischen Logging und Detection Engineering. Logs zu besitzen bedeutet noch lange nicht, Angriffe zu erkennen. Ein gutes SOC braucht Regeln für konkrete Verhaltensmuster: Credential Dumping, Kerberoasting, ungewöhnliche LDAP-Abfragen, Mass Enumeration, Remote Service Creation, verdächtige PowerShell-Nutzung, PsExec, RDP-Lateral-Movement, Living-off-the-Land-Techniken, ungewöhnlich große Dateizugriffe, Archivierung großer Datenbestände oder auffällige Uploads zu Cloud-Diensten. Diese Regeln müssen getestet, gepflegt und regelmäßig gegen reale Angriffstechniken überprüft werden. Genau dabei helfen Purple-Team-Übungen und Adversary Emulation. Mit Werkzeugen wie Atomic Red Team oder MITRE Caldera kann eine Organisation testen, ob vorhandene Kontrollsysteme bestimmte Angriffstechniken tatsächlich erkennen. Nicht theoretisch, sondern praktisch. Wenn eine Detection Rule auf dem Papier existiert, aber beim Test nichts auslöst, ist sie wertlos. Besonders interessant wird es bei großen Datenabflüssen. Mehrere Terabyte Daten verschwinden normalerweise nicht in einem einzigen, unsichtbaren Moment aus einem Netzwerk. Vorher müssen sie gefunden, gelesen, gesammelt, häufig kopiert, teilweise komprimiert und anschließend übertragen werden. Jeder dieser Schritte kann Spuren hinterlassen. Fileserver sehen ungewöhnlich viele Lesezugriffe. Endpunkte sehen Archivierungsprozesse. DLP-Systeme können sensible Inhalte identifizieren. Firewalls und Proxies sehen ausgehenden Verkehr. NDR-Systeme erkennen ungewöhnliche Kommunikationsmuster. NetFlow zeigt Datenmengen und Kommunikationsbeziehungen. Werkzeuge wie Zeek, Suricata, Corelight oder andere NDR-Plattformen können beispielsweise sichtbar machen, wenn ein System plötzlich über längere Zeit ungewöhnlich große Datenmengen zu einem Ziel überträgt, mit dem es zuvor nie kommuniziert hat. Auch hier gilt: Der einzelne Datenstrom muss nicht zwangsläufig verdächtig sein. Aber ein Verwaltungsserver, der plötzlich Millionen Dateien liest, große Archive erzeugt und anschließend dauerhaft hohe ausgehende Datenraten produziert, sollte mindestens Fragen auslösen. Deshalb ist Exfiltration kein einzelnes Ereignis, sondern ein Prozess. Angreifer legen häufig Staging-Verzeichnisse an, erzeugen Archive oder nutzen legitime Werkzeuge wie 7-Zip, WinRAR, rsync, rclone, SFTP oder Cloud-Storage-Dienste. Gerade weil viele dieser Tools auch regulär verwendet werden, reicht einfache Signaturerkennung nicht aus. Entscheidend ist wieder das Verhalten im Kontext. Ein weiterer oft unterschätzter Punkt ist die Datenklassifizierung. Eine Organisation kann nur schützen, was sie kennt. Wenn niemand genau weiß, welche personenbezogenen, vertraulichen oder sicherheitsrelevanten Daten in welchen Fileshares, Alt-Systemen, Mailboxen oder Dokumentenmanagementsystemen liegen, kann auch niemand sinnvolle Schutzmaßnahmen definieren. Information Protection, DLP und Data Security Posture Management helfen dabei, Daten zu klassifizieren und Zugriffsmuster zu erkennen. Das eigentliche Problem ist in vielen Organisationen nicht fehlende Verschlüsselung, sondern schlicht fehlende Übersicht. Dasselbe gilt für Berechtigungen. Least Privilege gehört seit Jahrzehnten zum Grundwissen der IT-Sicherheit und wird trotzdem regelmäßig nicht konsequent umgesetzt. Mitarbeiter wechseln Abteilungen, behalten aber alte Rechte. Projekte enden, Gruppen bleiben bestehen. Service Accounts bekommen temporär zusätzliche Privilegien, die nie wieder entfernt werden. So entstehen über Jahre Berechtigungslawinen. Regelmäßige Access Reviews, Role-Based Access Control, Just-in-Time-Administration und Privileged Access Management sollen genau dieses Problem begrenzen. Und auch Backups lösen längst nicht jedes Problem. Sie helfen bei Availability, nicht bei Confidentiality. Moderne Ransomware-Gruppen stehlen Daten häufig vor der Verschlüsselung und setzen anschließend auf Double Extortion. Ein perfektes Backup kann Systeme wiederherstellen. Es kann bereits veröffentlichte Passkopien, Bankdaten, interne Unterlagen oder Zugangsdaten nicht zurückholen. Deshalb muss Informationssicherheit immer Verfügbarkeit, Integrität und Vertraulichkeit gleichzeitig betrachten. Spätestens wenn ein Angriff erkannt wird, zeigt sich außerdem, ob Incident Response tatsächlich funktioniert oder nur dokumentiert wurde. Ein Incident-Response-Plan auf SharePoint nützt wenig, wenn im Ernstfall unklar ist, wer Systeme isolieren darf, wer externe Forensiker beauftragt, wer Behörden informiert, wer Kommunikationskanäle freigibt und wer die Entscheidung trifft, einen produktiven Dienst abzuschalten. NIST- und BSI-Modelle beschreiben solche Prozesse seit Jahren. Der entscheidende Unterschied liegt aber darin, ob sie regelmäßig geübt werden. Tabletop Exercises, technische Simulationen und klare Eskalationswege sind deshalb kein organisatorisches Beiwerk, sondern Teil der Sicherheitsarchitektur. Dasselbe gilt für Kennzahlen wie Dwell Time, Mean Time to Detect und Mean Time to Respond. Je länger sich ein Angreifer unbeobachtet in einer Umgebung bewegen kann, desto größer ist die Wahrscheinlichkeit, dass er Credentials sammelt, Persistenz aufbaut, weitere Systeme kompromittiert und sensible Daten identifiziert. Genau deshalb sollte die wichtigste Frage nach einem großen Cybervorfall nicht lauten: Wie sind die Angreifer hineingekommen? Die wichtigeren Fragen beginnen danach. Wie weit konnten sie sich bewegen? Warum konnten sie sich so weit bewegen? Welche Sicherheitssysteme hätten das erkennen müssen? Und warum wurde der Angriff nicht früher gestoppt? Erst die Antworten auf diese Fragen zeigen, wie gut eine Organisation tatsächlich aufgestellt war. Ein erfolgreicher Phishing-Angriff ist ein Sicherheitsvorfall. Ein kompromittierter Account ebenfalls. Eine ungepatchte Schwachstelle ebenso. Wenn daraus jedoch eine organisationsweite Kompromittierung mit massenhafter Datenexfiltration entsteht, reicht es nicht mehr, nur auf den Eintrittspunkt zu zeigen. Dann müssen IAM, Berechtigungen, Segmentierung, EDR, SIEM, SOC, Detection Engineering, DLP, NDR, Logging und Incident Response gemeinsam betrachtet werden. Denn der wichtigste Satz moderner Informationssicherheit lautet nicht: Niemand darf hineinkommen. Sondern: Wenn jemand hineinkommt, darf er verdammt wenig damit anfangen können.

BERLIN: DAS PROBLEM SIND NICHT NUR 5,8 TERABYTE. DAS PROBLEM IST, DASS MAN EINIGE DIESER DATEN NICHT EINFACH ÄNDERN KANN. Eine technische Einordnung des Berliner Datenleaks. Beim Berliner Cyberangriff konzentriert sich die öffentliche Diskussion bislang erstaunlich stark auf die schiere Datenmenge, personenbezogene Daten, Passwörter und die Frage, wer jetzt informiert werden muss. Das alles ist wichtig. Aber es ist nicht das größte Problem. Das wirklich Beunruhigende beginnt dort, wo Berichte über Schwachstellenanalysen der Berliner Trinkwasserversorgung, Dokumente zu kritischer Infrastruktur, Notfallunterlagen und andere interne Sicherheitsinformationen zutreffen. Denn damit reden wir über eine völlig andere Klasse von Daten. Ein Passwort ist ein Secret. Ein Secret kann ich ändern. Eine Infrastruktur ist eine Struktur. Und Strukturen kann ich nicht einfach rotieren. Wenn ein Passwort veröffentlicht wird: Password Reset. Ein Token: Revoke. Ein Zertifikat: Re-Issue. Ein Key: Rotate. Ein Account: Disable. Alles unangenehm, teuer und arbeitsintensiv, aber technisch lösbar. Was aber mache ich mit einer veröffentlichten Schwachstellenanalyse eines Wasserwerks? Mit dokumentierten Abhängigkeiten, Notfallkonzepten, Zuständigkeiten, bekannten Schwachpunkten, Betriebsabläufen, Eskalationswegen oder Sicherheitskonzepten? Ich kann schlecht sagen: „Wir rotieren am Montag unsere Trinkwasserversorgung.“ Genau deshalb sind solche Informationen so sensibel. Ein professioneller Angreifer beginnt einen Angriff nicht mit dem Angriff. Er beginnt mit Reconnaissance. Er möchte wissen: Wie sieht das Ziel aus? Welche Systeme existieren? Welche Abhängigkeiten gibt es? Wer ist verantwortlich? Wo befinden sich kritische Übergänge? Welche Schutzmaßnahmen existieren? Wo wurden Schwachstellen festgestellt? Welche Prozesse greifen bei einem Ausfall? Welche Dienstleister, Mitarbeiter und Organisationseinheiten spielen eine Rolle? Normalerweise muss ein Angreifer diese Informationen mühsam zusammensuchen: OSINT, Social Engineering, Scanning, Phishing, Credential Harvesting, interne Reconnaissance nach dem Initial Access. Das kostet Zeit, erzeugt Risiko und produziert Spuren. Eine interne Schwachstellenanalyse kann einen Teil dieser Arbeit bereits erledigt haben. Für den Verteidiger. Und jetzt möglicherweise auch für den Angreifer. Das ist der eigentliche Security-Super-GAU an solchen Leaks. Die Veröffentlichung einer Schwachstellenanalyse bedeutet selbstverständlich nicht automatisch: „Jetzt kann jemand die Berliner Wasserversorgung abschalten.“ Das wäre unseriös. Wir wissen weder vollständig, welche Dokumente tatsächlich enthalten sind, noch wie aktuell sie sind oder welche darin beschriebenen Schwachstellen inzwischen beseitigt wurden. Aber genau deshalb muss jetzt Assume Compromise gelten. Nicht nur für Accounts, sondern für INFORMATION. Man muss davon ausgehen, dass relevante Dokumente kopiert, lokal gespeichert, indexiert und mit anderen Informationen korreliert werden. Und man muss davon ausgehen, dass diese Daten noch Jahre später ausgewertet werden können. Das Internet vergisst einen solchen Dump nicht. Nach der Veröffentlichung ist die Anzahl der Kopien unbekannt. Damit existiert kein realistisches Szenario mehr, in dem Berlin sagt: „Wir haben die Quelle gelöscht. Problem erledigt.“ Die Vertraulichkeit ist irreversibel verloren. Systeme kann man recovern. Veröffentlichte Information nicht. Und dann kommt ein zweites Problem hinzu: 1,44 Millionen Dateien – sofern sich diese Angabe bestätigt – sind nicht einfach 1,44 Millionen Dokumente. Sie bilden einen Datensatz. Und Datensätze lassen sich korrelieren. Ein Organigramm allein mag harmlos sein. Eine Telefonnummer ebenfalls. Ein Vertrag vielleicht auch. Setze aber Personen, Funktionen, Telefonnummern, E-Mail-Adressen, Dienstleister, Verträge, Credentials, Systeminformationen, Organisationsstrukturen, Notfallprozesse und Schwachstellenanalysen zusammen, und daraus entsteht etwas völlig anderes: INTELLIGENCE. Das ist exakt der Punkt, den die Betrachtung als bloßer „Datenschutzvorfall“ verfehlt. Ein Angreifer braucht möglicherweise kein sensationelles Geheimdokument. Die Stärke liegt in der Korrelation. Wer arbeitet wo? Wer administriert was? Wer entscheidet? Welche Unternehmen liefern welche Leistungen? Welche Fachverfahren existieren? Welche Systeme hängen zusammen? Welche Menschen besitzen privilegiertes Wissen? Wie kommunizieren Behörden miteinander? Welche Prozesse werden in einer Krise aktiviert? Damit wird auch Social Engineering erheblich gefährlicher. Die klassische Phishing-Mail lautet: „Sehr geehrter Mitarbeiter, bitte Passwort bestätigen.“ Leicht zu erkennen. Eine Mail mit realen Namen, realen Vorgängen, realer Terminologie, echten Dienstleistern und echten organisatorischen Zusammenhängen spielt in einer völlig anderen Liga. Und genau hier kommt ein Punkt ins Spiel, der in der deutschen Sicherheitsdebatte regelmäßig unterschätzt wird: DAS PERSONAL. Nicht nur Administratoren. Nicht nur SOC, CISO und IT-Security. Das gesamte Verwaltungspersonal. Jeder Mitarbeiter mit Mailkonto, Fachverfahren, Dokumentenzugriff oder Telefon ist Teil der Sicherheitsarchitektur. Security Awareness ist deshalb kein jährliches Pflichtvideo mit fünf Multiple-Choice-Fragen. Mitarbeiter müssen Phishing erkennen, ungewöhnliche Vorgänge hinterfragen, sensible Informationen richtig behandeln, Berechtigungen ernst nehmen und Auffälligkeiten sofort melden. Wenn Beschäftigte Security als lästige IT-Vorschrift behandeln, Credentials weitergeben, Anhänge sorglos öffnen, Daten lokal herumkopieren oder Warnungen ignorieren, entsteht eine Verteidigungslücke, die kein SIEM der Welt vollständig schließen kann. Technik kann menschliches Fehlverhalten begrenzen. Sie kann es nicht vollständig eliminieren. Und deshalb ist Cybersecurity immer auch Sicherheitskultur. Wenn eine öffentliche Verwaltung diese Kultur nicht vom Sachbearbeiter bis zur Behördenleitung etabliert, haben wir nicht nur ein Berliner Problem. Dann haben wir ein Problem in Deutschland. Die technische Antwort auf den Leak ist ohnehin unangenehm. Berlin kann nicht einfach ein paar Passwörter ändern und anschließend Entwarnung geben. Man muss den veröffentlichten Informationsbestand selbst als Threat-Intelligence-Quelle gegen die eigene Infrastruktur behandeln: Was weiß ein zukünftiger Angreifer jetzt über uns? Welche Informationen sind noch gültig? Welche Schwachstellen existieren noch? Welche Prozesse müssen verändert werden? Welche Trust Relationships müssen überprüft werden? Welche Architekturinformationen ermöglichen Rückschlüsse auf den Blast Radius? Welche Notfallverfahren müssen angepasst werden? Welche Informationen erleichtern Social Engineering? Und bei welchen Informationen bleibt nur eine Möglichkeit: DIE DARIN BESCHRIEBENE REALITÄT ÄNDERN. Genau dort wird es teuer. Eine Schwachstelle kann man patchen. Eine historisch gewachsene Infrastruktur möglicherweise nicht. Einen Netzwerkpfad kann man ändern. Ein Wasserwerk nicht. Credentials kann man austauschen. Physische Standorte nicht. Software kann man ersetzen. Versorgungsabhängigkeiten nur mit erheblichem Aufwand. Man muss gegebenenfalls nicht die Datei ändern. Man muss die Welt ändern, die in der Datei beschrieben wird. Und hier beginnt das politische Versagen. Deutschland führt mit erstaunlicher Ausdauer Debatten darüber, welche Kommunikation der Staat überwachen, welche Plattformen er regulieren und welche zusätzlichen digitalen Kontrollmöglichkeiten Behörden erhalten sollen. Chatkontrolle lässt grüßen. Das ist eine bemerkenswerte Prioritätensetzung für einen Staat, der gleichzeitig offenbar fundamentale Probleme damit hat, die Vertraulichkeit seiner eigenen Informationen sicherzustellen. Informationskontrolle ist nicht Informationssicherheit. Eine Suchmaschine dazu zu bringen, einen Link nicht anzuzeigen, macht einen veröffentlichten Datensatz nicht wieder geheim. Eine Plattform zur Löschung aufzufordern, rotiert keine kompromittierte Infrastrukturinformation. Wer ernsthaft nach diesen Daten sucht, braucht Berlin nicht um Erlaubnis zu fragen. Die entscheidende Sicherheitsbarriere hätte VOR der Exfiltration stehen müssen. Nicht hinterher vor der Suchmaschine. Das ist vielleicht die bitterste Erkenntnis dieses Vorfalls: Wir diskutieren politisch immer häufiger darüber, wie der Staat Informationen anderer kontrollieren kann. Dabei wäre die wesentlich dringendere Aufgabe, den Staat endlich in die Lage zu versetzen, seine eigenen Informationen zu kontrollieren. Dafür brauchen wir keine weitere paternalistische Digitalpolitik. Wir brauchen professionelle IT-Security: Asset Management, Data Classification, Least Privilege, PAM, Segmentierung, Zero Trust, EDR/XDR/NDR, SIEM, 24/7 SOC, Egress Monitoring, DLP, Lifecycle Management, Patch Management, Threat Hunting, Red Teams, Purple Teams und Incident Response. Und wir brauchen Security Awareness und Security Culture in der gesamten Verwaltung. Denn der teuerste Security-Stack hilft wenig, wenn der Mensch davor glaubt, Sicherheit sei ausschließlich Aufgabe der IT. Security scheitert daran, dass Legacy-Systeme weiterlaufen, Verantwortlichkeiten zerfasern, Budgets fehlen, bekannte Risiken akzeptiert werden, niemand abschalten will und Mitarbeiter nicht verstehen, dass sie selbst Teil der Verteidigung sind. Die größte Lehre aus Berlin lautet deshalb nicht: „Wir müssen verhindern, dass Menschen die veröffentlichten Daten finden.“ Das ist nach einer Veröffentlichung dieser Größenordnung weitgehend vorbei. Die Lehre lautet: WIR MÜSSEN VERHINDERN, DASS DER NÄCHSTE DATENBESTAND ÜBERHAUPT DAS NETZ VERLÄSST. Und bei KRITIS muss zusätzlich gelten: Informationen, die einem Angreifer helfen könnten, kritische Infrastruktur zu verstehen, dürfen niemals denselben Blast Radius besitzen wie gewöhnliche Verwaltungsdaten. Need-to-know muss technisch erzwungen werden, nicht in einer Richtlinie stehen. Segmentierung muss existieren, nicht in PowerPoint. Logging muss ausgewertet werden, nicht nur gespeichert. Alerts müssen Konsequenzen haben, nicht nur Tickets erzeugen. Mitarbeiter müssen wissen, warum das alles wichtig ist. Und Management muss Risiken tragen, nicht nur Administratoren. Denn wenn sich die Berichte über die veröffentlichten KRITIS-, Schwachstellen- und Notfallinformationen bestätigen, hat Berlin nicht einfach Dateien verloren. Dann hat Berlin potentiell Wissen darüber verloren, wie Teile des Staates funktionieren, wie sie geschützt werden, wo ihre Schwächen liegen und wie sie sich im Notfall verhalten. Ein Passwort kann man ändern. Einen Staat kann man nicht mal eben rotieren. Und eine Sicherheitskultur kann man nicht installieren. Man muss sie aufbauen. Vielleicht sollte ein Staat, bevor er die Chats seiner Bürger kontrollieren möchte, zunächst beweisen, dass er seine eigenen Daten kontrollieren kann. Und damit kommen wir zum politischen Schluss dieses Desasters. Die derzeit Verantwortlichen haben beim Schutz elementarer staatlicher Infrastruktur offensichtlich keinen Grund zur Selbstzufriedenheit. Sollte ihnen nun eine Regierung folgen, die ihre Prioritäten weiterhin stärker bei Regulierung, Kontrolle und paternalistischer Digitalpolitik setzt als beim Aufbau einer robusten, professionellen Sicherheitsarchitektur, wird sich das Problem nicht lösen. Es wird nur unter anderem politischen Vorzeichen weiterverwaltet. Das wäre vielleicht die bitterste Pointe: Die einen haben es versäumt, den Staat digital verteidigungsfähig zu machen. Und die nächsten könnten denselben Fehler wiederholen, weil sie Sicherheit erneut mit Regeln, Zuständigkeiten und Kontrolle verwechseln. Cybersecurity interessiert sich aber nicht für Parteiprogramme. Ein ungepatchtes System bleibt ungepatcht. Eine schlechte Segmentierung bleibt schlecht. Ein ungeschulter Mitarbeiter bleibt ein Angriffspunkt. Ein unerkannter Datenabfluss bleibt ein Datenabfluss – ganz gleich, welche Farbe die Senatorin oder der Senator im Parteibuch trägt. Wenn Deutschland nicht endlich begreift, dass digitale Souveränität zuerst bedeutet, die eigene Infrastruktur, die eigenen Daten und die eigenen Mitarbeiter verteidigungsfähig zu machen, dann wird Berlin nicht der letzte Fall dieser Größenordnung gewesen sein. Dann werden wir weiter über Datenschutz reden, während unsere Daten gestohlen werden. Über Regulierung, während unsere Systeme veralten. Und über Informationskontrolle, während andere längst unsere Informationen kontrollieren. Die Zukunft könnte tatsächlich düster werden. Nicht weil die Angreifer unbesiegbar wären. Sondern weil wir ihnen seit Jahren dabei helfen, indem wir Security verwalten, statt sie zu betreiben.