Erken­nung,
Meldung

Eindäm­mung,
Siche­rung

Analyse,
Bewer­tung

Wieder­her­stel­lung,
Rück­füh­rung

Nach­be­ar­bei­tung,
Doku­men­ta­tion

Digi­ta­li­sie­rung – Vernet­zung – Bildung

Cyber­an­griffe erkennen, melden und Maßnahmen ergreifen

  • Verdäch­tige Akti­vi­täten erkennen

Beob­ach­tung Mögli­cher Hinweis auf
Uner­klär­li­cher Stopp oder Neustart einer Maschine Mani­pu­la­tion von SPS/Steuerung
Benutzer meldet selt­sames Verhalten auf seinem HMI Schad­soft­ware oder Fern­zu­griff
Uner­war­tete Pass­wort­ab­fragen in der SCADA-Ober­fläche Phis­hing oder Session-Hijacking
Netz­werk­über­las­tung oder plötz­li­cher Daten­ver­kehr ins Internet Daten­ab­fluss (Exfil­tra­tion), Botnet-Akti­vität
Anti­virus-/EDR-Warnung mit Bezug zu OT-Kompo­nenten Schad­code im ICS-Netz­werk
Fern­war­tungs­zu­gang aktiv außer­halb geplanter Zeit­fenster Miss­brauch von Zugangs­daten

  • Im Ernst­fall melden – An wen?

Wichtig: Alle Mitar­bei­tenden sollten wissen, wo und wie sie einen Vorfall melden können – z. B. über eine Notfall­nummer oder ein Melde­for­mular.

Meldung durch Ansprech­partner intern Mögliche externe Kontakte
Produk­ti­ons­mit­ar­beiter IT-Sicher­heits­be­auf­tragter, OT-Leitung, Werks­lei­tung Hersteller von Auto­ma­ti­sie­rungs­technik
IT-Admin Infor­ma­tion Secu­rity Team, CISO CERT-Bund, BSI, ggf. LKA
Betriebs­lei­tung Krisen­stab, Geschäfts­füh­rung Aufsichts­be­hörden (z. B. Daten­schutz)

  • Erste Maßnahmen zur Eindäm­mung

Maßnahme Wann und warum
Netz­werk­ver­bin­dung trennen (z. B. betrof­fene Steue­rung vom Netz trennen) Um Ausbrei­tung eines Angriffs zu verhin­dern
System nicht ausschalten Spei­cher­ab­bilder für foren­si­sche Analyse bewahren
Sicht­bare Auffäl­lig­keiten doku­men­tieren (z. B. Fotos, Screen­shots, Logs) Beweise sichern und Analyse erleich­tern
Zugangs­daten blockieren (z. B. kompro­mit­tiertes Benut­zer­konto) Um weiteren Zugriff zu verhin­dern
Infor­mierte Mitar­bei­tende briefen (keine Systeme selb­ständig berei­nigen!) Um Fehler oder Beweis­mit­tel­ver­lust zu vermeiden

Digi­ta­li­sie­rung – Vernet­zung – Bildung

Cyber­an­griffe eindämmen und sichern

  • Systeme sicher isolieren

Ziel: Verhin­dern, dass sich der Angriff auf andere Systeme oder Netz­seg­mente ausbreitet – ohne wich­tige Beweise zu verlieren.

Maßnahmen Aufgabe
Logi­sche Tren­nung vom Netz­werk Trenne betrof­fene Systeme (z. B. HMI, SPS, Server) vom Produk­ti­ons­netz­werk, z. B. durch:
  • Port-Deak­ti­vie­rung auf Switch
  • VLAN-Tren­nung oder ACL-Anpas­sung
  • Deak­ti­vieren von WLAN, VPN oder Fern­war­tungs­zu­gängen
Keine physi­sche Abschal­tung, außer wenn die Anla­gen­steue­rung Menschen gefährden kann Herun­ter­fahren kann RAM-Inhalte und vola­tile Daten löschen.
Besser: Strom­ver­sor­gung aufrecht­erhalten, Netz­ver­bin­dung trennen.
Isolie­rung in virtu­ellen Umge­bungen Snapshot erstellen und VM in Quaran­täne-Netz verschieben

  • Daten schützen und sichern

Ziel: Sicher­stellen, dass keine zusätz­li­chen Daten verän­dert, gelöscht oder über­tragen werden – gleich­zeitig kriti­sche Produk­ti­ons­daten bewahren.

Maßnahmen Aufgabe
Backup der betrof­fenen Systeme erstellen System-Images (Block-basiert) sichern.
Daten­banken (z. B. Histo­rian, Produk­ti­ons­daten) sichern.
Wichtig: Backup offline auf externem Medium (kein Netz­werk-Share) sichern.
Siche­rung aktiver Logdaten System- und Ereig­nis­pro­to­kolle (Windows/Linux Logs, SCADA Logs, Fire­wall-Logs) sichern.
Expor­tieren Sie voll­stän­dige Logfiles inkl. Zeit­stempel und ggf. Syslog/Netflow.
Zugriffs­pro­to­kolle sichern VPN-Logs, Fern­war­tungs­pro­to­kolle, Benut­zer­an­mel­dungen sichern.
Produk­ti­ons­da­ten­bank (MES, ERP, SCADA) klonen Bei Verdacht auf Mani­pu­la­tion, die Produk­ti­ons­da­ten­banken klonen.

  • Foren­sisch rele­vante Infor­ma­tionen sichern

Ziel: Digi­tale Spuren sichern, um die Angriffs­me­thode, das Ausmaß und den Angreifer nach­voll­ziehen zu können.

Wichtig zu beachten: Keine aktiven Berei­ni­gungen oder Neuin­stal­la­tionen vor der foren­si­schen Siche­rung!
– Zugriff auf betrof­fene Systeme auf ein kleines, geschultes Team beschränken
– Beweis­si­che­rung ist Voraus­set­zung für eine Straf­an­zeige oder Versi­che­rungs­leis­tung

Maßnahmen Aufgabe
RAM-Inhalte sichern (Memory Dump) Tools: z. B. FTK Imager, Belka­soft RAM Capturer
Nur von geschultem Personal durch­führen lassen
Fest­plat­ten­si­che­rung (Imaging) Sektor-genaue Kopie der Fest­platte (z. B. mit dd, Clone­zilla, FTK Imager)
Erstellen von Hash­werten (z. B. SHA256) zur Inte­gri­täts­prü­fung
Netz­werk­ver­kehr mitschneiden (falls möglich) z. B. mit Wireshark, tcpdump, Port-Mirro­ring auf Switch akti­vieren
Geräte- und Benut­zer­kon­fi­gu­ra­tion sichern Konfi­gu­ra­tionen von Fire­walls, Swit­ches, PLCs etc. expor­tieren
Mani­pu­la­ti­ons­si­chere Doku­men­ta­tion führen Zeit­punkt, Maßnahmen, betei­ligte Systeme und Personen doku­men­tieren
Beweise kenn­zeichnen und in gesi­cherten Bereich über­führen

Digi­ta­li­sie­rung – Vernet­zung – Bildung

Cyber­an­griffe bewerten und analy­sieren

  • Angriff tech­nisch bewerten

Hinweis: Alle Bewer­tungen, Entschei­dungen und Maßnahmen sollten doku­men­tiert werden – idea­ler­weise im zentralen Vorfall­be­richt. Nutzen Sie struk­tu­rierte Vorlagen und ein einheit­li­ches Proto­kol­lie­rungs­system.

Schritt Maßnahme Ziel
1. Angriffs­ka­te­gorie bestimmen Handelt es sich um Malware, Ransom­ware, Phis­hing, unau­to­ri­sierten Zugriff, Insider-Angriff o. Ä.? Erkennen, welcher Typ Bedro­hung vorliegt
2. Angriffs­pfad rekon­stru­ieren Welche Systeme wurden zuerst kompro­mit­tiert? Wie brei­tete sich der Angriff aus? (z. B. über VPN, Fern­war­tung, SMB) Ursache und Ausbrei­tung verstehen
3. Betrof­fene Systeme iden­ti­fi­zieren Liste aller kompro­mit­tierten oder verdäch­tigen Systeme inkl. IP, Host­name, Funk­tion (z. B. SPS, HMI, Server) erstellen Angriffs­fläche eingrenzen
4. Indi­ka­toren für Kompro­mit­tie­rung (IoCs) erfassen Hash­werte von Malware, verdäch­tige IPs, Domains, Dateien, Prozesse Für Abgleich und weitere Detek­tion
5. Foren­si­sche Daten sichern und analy­sieren Logfiles, Spei­cher­ab­bilder, Netflow-Daten analy­sieren Angriffs­muster nach­weisen und doku­men­tieren

Praxis­bei­spiel: 
Ein Angreifer nutzt kompro­mit­tierte Fern­war­tungs­daten eines Maschi­nen­her­stel­lers, um über ein VPN Zugang zum SCADA-Netz­werk zu erhalten. Über schlecht segmen­tierte Netze breitet sich ein Remote Access Trojan (RAT) aus.
Die Bewer­tung ergibt: Der Angriff hatte Zugriff auf Bedien­sta­tionen, aber keine Mani­pu­la­tion von SPS-Logik.

  • Auswir­kungen auf Produk­ti­ons­pro­zesse einschätzen

Maßnahmen Beschrei­bung
Status­prü­fung der betrof­fenen Anlagen Welche Maschinen standen? Wurden Produk­ti­ons­daten gelöscht oder verän­dert? Gibt es Anzei­chen für physi­sche Prozess­ab­wei­chungen?
Abgleich mit Produk­ti­ons­pro­to­kollen Vergleich der realen Produk­ti­ons­daten mit Soll­werten / Histo­rien­werten (z. B. aus MES/SCADA)
Gespräch mit Betriebs- oder Schicht­lei­tung Subjek­tive Beob­ach­tungen zu auffäl­ligem Verhalten sammeln (z. B. unge­wöhn­liche Alarme oder Bedie­ner­füh­rung)
Veri­fi­ka­tion der Rezep­turen / Konfi­gu­ra­tionen Stimmt z. B. die SPS-Logik noch mit der frei­ge­ge­benen Version überein?
Bewer­tung betrieb­li­cher Risiken Gefahr für Produkt­qua­lität, Anla­gen­ver­füg­bar­keit, Arbeits­si­cher­heit?

Praxis­bei­spiel: 
Ein Produk­ti­ons­pro­zess lief weiter, jedoch wurden die Char­gen­pro­to­kolle einer Abfüll­an­lage mani­pu­liert. Die physi­ka­li­sche Dosie­rung war korrekt, die Doku­men­ta­tion aber unbrauchbar – mit Folgen für Rück­ver­folg­bar­keit und Quali­täts­si­che­rung.

  • Melde­pflichten prüfen

Prüf­kri­te­rium Bewer­tung
Sind perso­nen­be­zo­gene Daten betroffen? (z. B. Mitar­bei­ter­daten, Kunden­in­for­ma­tionen) Wenn ja → Prüfung Melde­pflicht nach DSGVO (Art. 33)
Sind kriti­sche OT-Systeme oder KRITIS-Anlagen betroffen? Melde­pflicht nach BSIG / NIS2 prüfen
(Meldeweg: BSI, natio­naler CERT)
Vertrags­re­le­vante Infor­ma­tionen oder Geschäfts­ge­heim­nisse betroffen? Ggf. Meldung an Rechts­ab­tei­lung / Kunden­ver­träge beachten
Interne Melde­pflichten erfüllt? (z. B. Geschäfts­füh­rung, Daten­schutz, Betriebsrat) Internes Reporting sicher­stellen
Fristen einge­halten? DSGVO: 72 Stunden ab Kennt­nis­nahme,
BSI: ohne schuld­haftes Zögern

Digi­ta­li­sie­rung – Vernet­zung – Bildung

Wieder­her­stel­lung und Rück­füh­rung in den Betrieb

  • Vorbe­rei­tung des Wieder­an­laufs

Hinweis zur Indus­trie­praxis
In indus­tri­ellen Betrieben ist der Wieder­an­lauf oft mit physi­schen Anlagen, Safety-Systemen und externen Part­nern (z. B. OEMs) verbunden. Daher ist es wichtig, sowohl tech­ni­sche Rück­si­che­rung als auch Betriebs­si­cher­heit und Produkt­schutz im Blick zu behalten.

Empfeh­lung: Inte­grieren Sie den Wieder­an­lauf in Ihre regel­mä­ßigen Krisen­übungen, idea­ler­weise abge­stimmt auf Ihre Prozesse gemäß IEC 62443, NIS2 oder ISO 27001.

Tech­ni­sche Maßnahmen Aufgabe
Betrof­fene Systeme voll­ständig berei­nigen oder neu aufsetzen
  • Keine Wieder­ver­wen­dung kompro­mit­tierter Instal­la­tionen verwenden
  • Indus­tri­elle Steue­rungen (z. B. SPS, HMIs) mit Origi­nal­kon­fi­gu­ra­tion prüfen und ggf. neu flashen
Backups nur nach Prüfung auf Inte­grität und Malware verwenden
  • Viren­prü­fung auf isolierter Umge­bung durch­führen
  • Hash­wert-Vergleich zur Sicher­stel­lung der Unver­än­dert­heit
Systeme patchen und härten
  • Alle Sicher­heits­up­dates einspielen (OS, SCADA, MES, ERP)
  • Lokale Admin­rechte, unnö­tige Dienste und offene Ports prüfen
Orga­ni­sa­to­ri­sche Maßnahmen Aufgabe
Wieder­an­lauf planen und prio­ri­sieren
  • Kriti­sche Produk­ti­ons­li­nien vor Neben­sys­temen
  • Wieder­her­stel­lungs­zeit­punkte (RTO) und ‑zustände (RPO) abstimmen
Frei­ga­be­pro­zess defi­nieren
  • Tech­ni­sche Prüfung durch IT/OT
  • Doku­men­tierte Frei­gabe durch Sicher­heits­ver­ant­wort­liche oder Krisen­stab

  • Sicherer Wieder­an­lauf und System­in­te­gra­tion

Tech­ni­sche Maßnahmen Aufgabe
Netz­werk­seg­men­tie­rung beibe­halten oder verstärken
  • OT-Systeme nur mit defi­nierten Schnitt­stellen zur IT verbinden
  • Moni­to­ring (z. B. IDS/IPS) akti­vieren
Neu inte­grierte Systeme über­wa­chen (Post-Inci­dent-Moni­to­ring)
  • 24–72 Stunden engma­schiges Moni­to­ring von Logdaten, Verhalten und Netz­werk­ver­kehr
  • Anoma­lie­er­ken­nung akti­vieren
Zugangs­daten und Benut­zer­rechte über­ar­beiten
  • Kompro­mit­tierte Konten deak­ti­vieren
  • Prinzip der geringsten Rechte umsetzen
Orga­ni­sa­to­ri­sche Maßnahmen Aufgabe
Kommu­ni­ka­tion mit Fach­ab­tei­lungen und Produk­ti­ons­ver­ant­wort­li­chen
  • Klare Infor­ma­tionen zum Start­zeit­punkt, erwar­teten Verhalten und Melde­wegen
  • Schu­lung oder Brie­fing zur Erken­nung auffäl­ligen Verhal­tens
Wieder­an­lauf doku­men­tieren
  • Welche Systeme wurden wann und wie zurück­ge­führt?
  • Welche Tests wurden durch­ge­führt? Wer hat frei­ge­geben?

  • Schutz vor erneuten Angriffen

Tech­ni­sche Maßnahmen Aufgabe
IT- und OT-Sicher­heits­maß­nahmen erwei­tern
  • MFA für Fern­zu­gänge akti­vieren
  • Appli­ca­tion White­lis­ting auf HMIs oder SCADA-Systemen
  • Netz­werk­scanner und Schwach­stel­len­scanner regel­mäßig einsetzen
Sicher­heits­über­wa­chung zentra­li­sieren (z. B. über SOC/SIEM)
  • Logs zentral sammeln und korre­lieren
  • Früh­warn­sys­teme aufbauen
Orga­ni­sa­to­ri­sche Maßnahmen Aufgabe
Lessons Learned durch­führen
  • Was hat funk­tio­niert, was nicht?
  • Betei­ligte Bereiche einbinden (IT, OT, Produk­tion, Compli­ance)
Notfall- und Wieder­an­lauf­pläne anpassen
  • Erkennt­nisse in Notfall­do­ku­men­ta­tion und SOPs inte­grieren
  • Nächste Schu­lung oder Übung planen

Digi­ta­li­sie­rung – Vernet­zung – Bildung

Nach­be­ar­bei­tung und Doku­men­ta­tion

  • Struk­tu­rierte Nach­be­rei­tung und Vorfalls­do­ku­men­ta­tion

Maßnahmen Beschrei­bung
Zentralen Vorfall­be­richt erstellen Tech­ni­scher Ablauf, betrof­fene Systeme, Angriffs­pfad, Reak­ti­ons­maß­nahmen, Wieder­her­stel­lung doku­men­tieren
Zeit­strahl des Vorfalls erstellen Beginn, Erken­nung, Eska­la­tion, Maßnahmen, Wieder­an­lauf – ideal zur Visua­li­sie­rung für Manage­ment
Beweis­si­che­rung archi­vieren Logs, Images, Memory Dumps und Kommu­ni­ka­ti­ons­pro­to­kolle sicher und nach­voll­ziehbar aufbe­wahren
Kosten und Auswir­kungen erfassen Produk­ti­ons­aus­fall, Perso­nal­auf­wand, Dienst­leister, Repu­ta­ti­ons­schäden etc. bezif­fern
Abschluss­be­richt mit Lessons Learned an Stake­holder über­geben Geschäfts­füh­rung, Daten­schutz, IT/OT-Leitung, Aufsichts­be­hörden (falls erfor­der­lich)

Praxis­bei­spiel:
Ein Ransom­ware-Angriff führte zu 3 Tagen Produk­ti­ons­aus­fall. Der Abschluss­be­richt enthält eine genaue Time­line, eine tech­ni­sche Analyse der Malware-Vertei­lung über SMB, die doku­men­tierten Wieder­an­lauf­maß­nahmen und einen Maßnah­men­plan zur Präven­tion. Kosten wurden mit 180.000 € bezif­fert, der Bericht diente auch zur Meldung an die Versi­che­rung.

  • Ursa­chen­ana­lyse (Root Cause Analysis)

Maßnahmen Methode
Tech­ni­sche Schwach­stellen ermit­teln Z. B. fehlende Netz­werk­seg­men­tie­rung, unge­patchte SCADA-Kompo­nenten, unsi­chere Remote-Zugänge
Prozes­suale Schwä­chen analy­sieren Z. B. keine struk­tu­rierte Inci­dent-Eska­la­tion, fehlende Notfall­kom­mu­ni­ka­tion, unklare Zustän­dig­keiten
„5‑Why”-Methode oder Ishi­kawa-Diagramm verwenden Um von Symptomen zu Ursa­chen vorzu­dringen
Beob­ach­tungen aus opera­tivem Umfeld einbe­ziehen Rück­mel­dung aus Produk­tion, Instand­hal­tung, IT/OT-Personal

Praxis­bei­spiel:
Ein kompro­mit­tierter Fern­war­tungs­zu­gang wurde als Einstiegs­punkt iden­ti­fi­ziert. Root Cause: kein 2‑Faktor-Login, Stan­dard­pass­wort nicht geän­dert, Zugriff nicht proto­kol­liert. Ergebnis: Einfüh­rung von MFA, zentraler Zugangs­kon­trolle und Logging für alle Fern­zu­griffe.

  • Orga­ni­sa­tion und Technik nach­haltig stärken

Bereich Maßnahme
Tech­nisch Netz­werk­seg­men­tie­rung umsetzen, IDS/IPS auf OT-Ebene einführen, regel­mä­ßiges Schwach­stel­len­scan­ning (z. B. Tenable.ot)
Orga­ni­sa­to­risch Notfall­hand­buch und Kommu­ni­ka­ti­ons­plan aktua­li­sieren, Rollen und Zustän­dig­keiten klar fest­legen
Mensch­lich Mitar­bei­ter­schu­lungen, Phis­hing-Simu­la­tionen, Aware­ness-Maßnahmen im Produk­ti­ons­um­feld (z. B. Poster, Aushänge)
Prozes­sual Inci­dent-Response-Prozesse stan­dar­di­sieren (SOPs), Melde­wege einüben, Inci­dent-Drills in OT-Umge­bungen durch­führen

  • Lessons Learned durch­führen

Maßnahmen Beispiel
Vorfall durch alle betei­ligten Rollen reflek­tieren lassen IT, OT, Produk­tion, Manage­ment, ggf. externe Partner
Was lief gut? Was hat gehakt? z. B. Kommu­ni­ka­tion, Zugriff auf Notfall­pläne, tech­ni­sche Erken­nung
Konkrete Maßnahmen prio­ri­sieren und termi­nieren Sofort­maß­nahmen vs. lang­fris­tige Anpas­sungen
Doku­men­ta­tion ins ISMS / Notfall­kon­zept zurück­spielen Lessons Learned sollen leben­dige Verbes­se­rungen erzeugen

Praxis­bei­spiel:
Nach einem Vorfall wurde die Notfall­ruf­nummer auf einem alten Intranet-Link gefunden – zu spät. Maßnahme: aktu­elle Kurz­an­lei­tung im Pausen­raum für Produk­tion, QR-Code auf Maschinen zur Meldung.

  • Empfeh­lungen zur Verste­ti­gung

Regel­mä­ßige Sicher­heits­übungen, auch in der Produk­tion (z. B. „Schein­an­griff auf HMI“)
Jähr­liche Review des Inci­dent-Response-Plans (inkl. Vorfall­sta­tistik)
Einfüh­rung eines konti­nu­ier­li­chen Verbes­se­rungs­pro­zesses (PDCA-Zyklus im ISMS)
Einbin­dung externer Experten oder Pene­tra­ti­ons­tests für realis­ti­sche Tests der Infra­struktur

Ein gut doku­men­tierter und reflek­tierter Vorfall macht die Orga­ni­sa­tion nicht nur reak­ti­ons­fä­higer, sondern stärkt auch Vertrauen bei Mitar­bei­tenden, Part­nern und Behörden – und redu­ziert nach­haltig das Risiko bei künf­tigen Angriffen.