Landkreis OSL nach Cyberangriff: Notbetrieb als Lehrstück für Verwaltungs-IT

Der Landkreis Oberspreewald-Lausitz (OSL) in Brandenburg ist seit dem 20. Oktober 2026 im IT-Notbetrieb. Anlass war ein Hinweis auf eine mögliche Kompromittierung eines IT-Clients. Die Kreisverwaltung fuhr ihre Systeme daraufhin vorsorglich herunter – und der Betrieb läuft bis heute nur eingeschränkt. Der Fall zeigt exemplarisch, wie tiefgreifend ein Cyberangriff oder dessen Verdacht die Arbeit einer Kommunalverwaltung stören kann.

Was seit dem 20. Oktober passiert ist

Nach dem Vorfall war der E-Mail-Verkehr mit der Kreisverwaltung vollständig unterbrochen – eingehende wie ausgehende Nachrichten. Antragsbearbeitung und Online-Dienste fallen aus, die Fahrzeug- und Fahrerlaubnisbehörde hat keine Sprechtage. Mit Amtshilfe der Nachbarlandkreise Dahme-Spreewald, Elbe-Elster, Spree-Neiße und der Stadt Cottbus laufen zumindest einzelne Leistungen wie Abmeldungen von Kraftfahrzeugen oder Kurzzeitkennzeichen.

Die Kommunikation läuft derzeit über Telefon und Post: Bürgerinnen und Bürger werden gebeten, Dokumente persönlich oder auf dem Postweg einzureichen. E-Mails, die seit dem 20. Oktober an den Landkreis geschickt wurden, sind nach eigenen Angaben vermutlich nicht angekommen – ohne Fehlermeldung. Ob personenbezogene Daten abgeflossen sind, kann der Landkreis nach eigener Auskunft weder bestätigen noch ausschließen.

Warum der Notbetrieb so lange dauert

Betroffene Organisationen stehen beim Wiederanlauf vor einem Dilemma: Zu früh hochgefahren, können Angreifer zurückkehren oder bleiben unentdeckt. Zu lange läuft die Verwaltung auf Analogbetrieb. Die Kreisverwaltung OSL arbeitet mit interner IT und externen Fachleuten die Systeme auf; ein schrittweiser Wiederanlauf wird angestrebt, ein Ende ist laut FAQ derzeit nicht absehbar. Das Landeskriminalamt ermittelt.

Hinzu kommt: Der Vorfall traf auf eine Woche mit einer weltweiten kritischen PHP-Sicherheitslücke (CVE-2026-109618 und CVE-2026-109619, jeweils 9,2 von 10 Punkten). Das BSI stufte die Lage auf Warnstufe 3 (Orange) ein – Kommunen wie der Landkreis Dahme-Spreewald, Bernau und Schwedt schalteten ihre Webseiten vorsorglich ab. Ob ein direkter Zusammenhang zwischen beiden Ereignissen besteht, ist nicht bekannt.

Was IT-Verantwortliche in Kommunen und KMU daraus ziehen sollten

  • Notfallplan konkret durchspielen: Ein Notfallplan nach BSI-Grundschutz nützt nur, wenn er den Analogleitbetrieb realistisch abbildet: Wer nimmt Anträge entgegen, welche Services laufen ohne IT weiter, wie kommuniziert man mit Bürgern ohne E-Mail?
  • Isolierte Wiederherstellung planen: Nach einer möglichen Kompromittierung gehören Backups und Systeme in eine Quarantäne-Infrastruktur, bevor sie produktiv gehen. Der schrittweise Wiederanlauf mit Monitoring ist Standard, nicht Kür.
  • Ersatzkommunikation definieren: Telefonnummern, Postanschrift und eine externe Statusseite (wie osl-online.de) müssen bekannt sein, bevor ein Vorfall passiert. Ein E-Mail-Ausfall ohne Fehlermeldung lässt Anfragen lautlos versanden.
  • Patch- und Abschaltentscheidung vorbereiten: Die PHP-Lücke zeigte, dass die vorsorgliche Abschaltung kritischer Webdienste eine legitime Notfallmaßnahme ist. Wer vorab weiß, welche Systeme ohne die Website lauffähig bleiben, entscheidet schneller.
  • Amtshilfe und Nachbarn einbinden: OSL löste Engpässe in der Kfz-Zulassung über Nachbarkreise. Solche Vereinbarungen entstehen nicht im Ereignisfall.

Praxis-Bezug für KMU und kleinere Verwaltungen

Kleine Kommunen und Unternehmen ohne eigene IT-Abteilung sind auf kommunale Rechenzentren oder Dienstleister angewiesen. Wichtig ist die klare Zuständigkeitsregelung: Wer entscheidet bei einem Warnhinweis des BSI über Abschaltung oder Update, wer prüft Systeme, wer kommuniziert? Der Fall OSL zeigt zudem, dass sich die Dauer eines Notbetriebs an der Aufklärung des Vorfalls orientiert – nicht an einem gewünschten Zeitplan. Resilienz bedeutet also nicht nur Schutz vor Angriffen, sondern auch die Fähigkeit, Wochen ohne reguläre IT operabel zu bleiben.

Checkliste für den Ernstfall

  • Betroffene Systeme und Versionen ermitteln (Web, Fachanwendungen, E-Mail).
  • Zuständigkeiten mit IT-Dienstleister oder Rechenzentrum schriftlich klären.
  • Sicherheitsupdates priorisiert einspielen; wo nicht möglich: Systeme vom Netz trennen.
  • Analogbetrieb definiert: Formulare, Sprechzeiten, Telefonnummern, Postanschrift.
  • Statusseite außerhalb der eigenen Infrastruktur betreiben.
  • Nach dem Vorfall: Systeme erst nach forensischer Prüfung und aus gesicherten Backups zurückbringen.

Quellen

Hinweis: Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz (KI) erstellt.

Tags

No responses yet

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert