OT-Sicherheit: Wie die Angreifersicht beim Schutz des Unternehmens hilft

Nutzt Ihr Unternehmen Automatisierungstechnik? Sie sind Teil von Industrie 4.0 oder wollen es werden? Predictive Maintenance oder Remote Access gehören zu Ihrem Tagesgeschäft? Dann haben Sie hoffentlich nicht nur von Operational-Technology-(OT)-Security gehört, sondern sind bereits aktiv an der Analyse und Umsetzung von Maßnahmen beteiligt. Dafür gibt es eine Vielzahl von Frameworks und Best Practices, die Firmen bei der Auswahl von Maßnahmen helfen.

Darüber hinaus macht es jedoch zusätzlich Sinn, sich das eigene Unternehmen aus der Sicht eines Angreifers anzusehen.

Um dieses Vorgehen zu verdeutlichen, stellen wir einige Beispiele aus der Praxis vor:

Beispiel 1: „Wir haben Policies, Procedures und diverse Guidelines im Unternehmen, wir sind sicher!“

Zuerst einmal ist dies ein guter Schritt in die richtige Richtung, denn diese Dokumentation hilft am Ende bei einem strukturierten und effizienten Vorgehen. Wichtig ist aber zu wissen, dass die Dokumente selbst einen Angreifer nicht abwehren. Nur weil man auf mehreren hundert Seiten beschreibt, wie der Soll-Zustand aussehen müsste, ist man noch kein bisschen sicherer geworden. Entscheidend ist hier, dass Policies, Procedures und Guidelines nicht nur erstellt, sondern auch im Unternehmen kommuniziert, implementiert und gegebenenfalls trainiert werden.

Beispiel 2: „Tool xyz sieht super aus und wird dafür sorgen, dass wir sicher sind!“

Das ist leider ein Klassiker, dem man immer wieder über den Weg läuft. Seien es vollmundige Werbeprospekte voller Buzzwords bestenfalls noch in Kombination mit KI oder die Versprechungen, dass man unbedingt ein Tool benötigt, um automatisiert compliant und sicher zu werden. Klingt erstmal verlockend, aber ist wirklich klar, welche Herausforderung das Tool lösen soll oder müssen die passenden Herausforderungen für das Tool erst noch entdeckt werden?

Beispielsweise macht es wenig Sinn, aufwendig Network-Intrusion-Detection-Systeme auszurollen, wenn die Schalt- und Serverräume sowie die zugehörigen Gebäude nicht grundlegend abgeschlossen/abgesichert sind und auch die Racks selbst keine Schließung aufweisen, da hier leicht eine physische Manipulation vorgenommen werden kann, die ein solches System dann nicht erkennt.

Es ist wichtig, nicht direkt mit der Auswahl von Tools zu beginnen, sondern sich zunächst Gedanken über die zu lösenden Herausforderungen zu machen. Darauf aufbauend können kompakte Anforderungen an eine Lösung erarbeitet werden und erst dann sollte damit begonnen werden, mögliche Tools neutral gegen diese Anforderungen zu evaluieren. Klassisches Requirements Engineering also. Andernfalls läuft man Gefahr, eine Lösung für ein nicht vorhandenes/nicht relevantes Problem zu beschaffen oder nur einen Teil der eigentlichen Herausforderungen abzudecken.

Beispiel 3: „Wir haben eine highend technische Absicherung, wir sind sicher!“

Das ist schon einmal sehr gut! Wichtig ist hierbei, nicht zu vergessen, dass Sicherheit drei Dimensionen hat: Menschen, Prozesse und Technologie. Diese müssen nicht alle auf dem gleichen Niveau sein, aber es sollte zumindest
sichergestellt sein, dass keine der Dimensionen übersehen wird. Sonst kann es passieren, dass beispielsweise ein Mitarbeiter im Rahmen von Social Engineering Informationen verrät, die zur Kompromittierung von Systemen führen.

Beispiel 4: „Wir haben unser aktuelles Security-Programm abgeschlossen, wir sind jetzt sicher!“

Zumindest zum Zeitpunkt des Abschlusses ist man sicher, aber sobald Unternehmen meinen, man könne sich nun entspannt zurücklehnen, ist der sichere Zustand sehr schnell wieder dahin, da unter anderem Schwachstellen regelmäßig bearbeitet werden müssen. Treffend ist hier auch die Aussage von Bruce Schneier: „Security is a process, not a product“.

Beispiel 5: „Wir brauchen kein führendes Tool, unser System/Netz ist so einfach, das Tool bauen wir uns selbst und dann sind wir sicher!“

Es mag verlockend klingen, wenn ein findiger Mitarbeiter auf die Idee kommt, dass man eine Log-Analyse mit Python auch selbst entwickeln kann und sich in diesem Fall die Ressourcen für eine Security-Information-and-Event-Management-(SIEM)-Software sparen kann. Letztendlich steckt der Teufel aber wieder im Detail und nicht umsonst beschäftigen Unternehmen wie SPLUNK ein entsprechend großes Entwicklerteam.

Aus Angreifersicht hat die eigenentwickelte Lösung jedenfalls einen Vorteil: Sie durchläuft vermutlich keine entsprechend strengen Tests wie kommerzielle Software und kann daher eventuell sogar als Ausgangspunkt für den einen oder anderen Angriff nützlich sein.

Beispiel 6: „Unsere Systeme sind komplett isoliert! Wir können nicht angegriffen werden und sind sicher!“

Kann man ein System vollständig isolieren, um Sicherheit zu gewährleisten? In der Theorie mag das möglich sein, wenn man die Kabelverbindungen anschließend einbetoniert und jegliche Ports des Systems mit Heißkleber unbrauchbar macht und noch dazu sicherstellt, dass Peripheriegeräte nicht gewechselt werden können. Ansonsten ist das System zwar in einem isolierten Netzwerk, aber es gibt diverse Schnittstellen, über die sich ein Angreifer Zugriff verschaffen könnte. Sei es über einen infizierten USB-Datenträger oder auch über das Erstellen eines zusätzlichen Ports auf einem Netzwerkkabel.

Sobald ein unbefugter Zugriff auf das System oder Teile des Systems nicht ausgeschlossen werden kann oder sobald ein Datentransfer mit externen Systemen erfolgt, kann man nicht mehr von einer Sicherheit durch Isolation ausgehen.

Darüber hinaus gibt es noch verschiedene Untersuchungen zu Side-Channel-Attacks, die nach einer initialen Kompromittierung des Systems auch zur Kommunikation mit Systemen außerhalb des isolierten Netzes genutzt
werden können.

Offensive Security zur Verbesserung der Absicherung?

Typischerweise verfügen Unternehmen über Teams, die auf der Basis von Frameworks die Absicherung des Betriebs vornehmen. Durch die reine Fokussierung auf den defensiven Aspekt kann jedoch schnell eine Lücke zur Realität entstehen, da man die „dunkle“ Seite nicht kennt beziehungsweise individuelle Schwachstellen übersieht. Einige Beispiele wurden bereits vorgestellt.

Um das zu verbessern, bietet es sich an, mindestens einen Experten für Offensive Security / Red Teaming im Sicherheitsteam zu haben. Speziell im OT-Umfeld kann es zusätzlich hilfreich sein, wenn diese Person einen Hang zum Thema physische Sicherheit hat. Alternativ kann man auch unterstützend einen Experten aus dem Bereich Objektschutz hinzuziehen. So kann das Team bestehend aus offensiven und defensiven Experten das Unternehmen oder einzelne Standorte mit dem Blick eines Angreifers betrachten. Die Offensivexperten entwerfen Pläne, wie man die existierenden Maßnahmen überwinden kann, auf deren Grundlage können anschließend die Schutzmaßnahmen optimiert werden.

In der praktischen Umsetzung empfiehlt es sich, die Standorte regelmäßigen Bewertungen durch das (erweiterte) Sicherheitsteam zu unterziehen, um zu analysieren, wie gut die definierten Maßnahmen umgesetzt werden und welche Schwachstellen gegebenenfalls vorhanden sind und behoben werden müssen. Auch können durch die regelmäßigen Prüfungen etwaige Fehlkonfigurationen, die bei Wartungen oder Umbauten auftreten, erkannt und anschließend behoben werden.

Erste Hilfe

Der Aufbau eines entsprechenden (erweiterten) Sicherheitsteams ist sicherlich nicht von heute auf morgen möglich. Im Rahmen von Audits zeigen sich jedoch immer wieder Punkte, die in vielen Betrieben vernachlässigt werden. Diese gilt es zu schließen:

1. Serverracks/Schaltschränke sind nicht verschlossen beziehungsweise haben kein Schloss. Sofern der zugehörige Raum entsprechend gesichert ist und sich nicht unterschiedliche Gewerke (z. B. IT, Leittechnik, TK) im gleichen Raum befinden und von verschiedenen Firmen betreut werden, kann dies akzeptabel sein. Ansonsten empfiehlt es sich, eine Schließung pro Gewerk einzuführen, um „unabsichtliche“ Änderungen weitgehend auszuschließen.
2. Schaltschränke verwenden die Hersteller-Standardschließung mit Vierkant-Schlüssel oder ähnlichem. Siehe Punkt 1. Anderenfalls sollte über eine Nachrüstung/Umrüstung nachgedacht werden. Die gängigen Schrankhersteller (unter anderem Rittal) haben mittlerweile selbst für ältere Modelle Umrüstkits im Angebot, die sogar den Einbau von elektronischen Schließsystem unterstützen.
3. Schlüssel stecken in den Schlössern der Schränke beziehungsweise hängen frei zugänglich im Schaltraum. Hier kann ein einfacher Schlüsselkasten Abhilfe schaffen – am besten in Kombination mit dem gleichen Schließsystem, das auch für die Türen im Gebäude verwendet wird. So ist die Usability gewährleistet. Ansonsten ist natürlich die Sensibilisierung der Mitarbeiterinnen und Mitarbeiter entscheidend, damit sie verstehen, wie wichtig sie für die Cybersicherheit des Unternehmens sind.
4. Passwörter stehen auf Zetteln/Post-its am Gerät (immer noch). Auch hier kann die Nutzung einer abschließbaren Box mit Passwörtern helfen. Am besten ist es natürlich, überhaupt keine schriftlichen Passwortlisten zu haben. Ansonsten kann auch hier eine Sensibilisierung der Mitarbeitenden hilfreich sein.
5. USB-Lizenz Dongles hängen außen am Gerät. Um den Verlust oder Diebstahl oder auch die anderweitige Nutzung des Ports zu verhindern, sollten interne USB-Ports genutzt werden und die äußeren Ports durch Port-Blocker verschlossen werden.
6.  Netzwerkports in Lagerhallen werden nicht genutzt, sind aber aktiv geschaltet. Die Ports sollten regelmäßig überprüft und bei Nichtbenutzung deaktiviert werden. Dies kann zum Beispiel in Zusammenarbeit mit dem Netzwerkteam geschehen, das regelmäßig überprüft, welche Ports ungenutzt sind und diese dann am Switch deaktiviert. Alternativ hilft auch hier die Sensibilisierung, damit die Beschäftigten verdächtige Aktivitäten in der Lagerhalle melden und nicht ignorieren.
7. Nach Umbaumaßnahmen (z. B. Verlegung eines Control Rooms) sind die alten Netzwerkports noch immer auf das Anlagennetz geschaltet. Man sollte sich nicht darauf verlassen, dass dies bereits „jemand“ getan hat. Stattdessen sollten die Änderungen nach den entsprechenden Änderungen verifiziert und validiert werden. Abhängig von der Kritikalität des Systems sollte diese Überprüfung durch einen unabhängigen Dritten erfolgen.
8. IT-Geräte werden beim Betreten des Geländes erfasst, aber beim Verlassen wird nicht kontrolliert, ob man die gleichen oder nur diese Geräte mitführt. Auf diese Weise können Geräte/Daten beliebig extrahiert werden, daher sollte das betroffene Personal sensibilisiert werden, die Geräte detailliert zu erfassen, die Seriennummer zu dokumentieren und gegebenenfalls auch Ports an den Geräten für die Nutzung zu sperren.
9. Fehlende Sicherheitspatches (das kann selbst bei neuen Anlagen vorkommen, sofern kein Passus in den Vertrag aufgenommen wurde). Hier bietet es sich an, ein kurzes Dokument mit ergänzenden Vertragsbedingungen zu
   erstellen, das die wichtigsten Punkte zur IT-/OT-Sicherheit zusammenfasst. Dieses Dokument wird mit dem Einkauf abgestimmt und dann anschließend bei jeder Beschaffung in die Vertragsdokumente ergänzt.
10. Geringe Security Awareness des Personals – Je nach Sensibilisierung des Personals kann es vorkommen, dass „falsche“ Techniker in Gebäude gelassen werden oder dass es niemanden interessiert, wenn Unbekannte in Lagerhallen herumlaufen und Laptops an Geräte anschließen. Hier sollte man auf eine möglichst permanente Sensibilisierung der Mitarbeitenden achten.

Fazit

Unternehmen sollten neben technischen und prozessualen Maßnahmen auch die Perspektive eines Angreifers einnehmen, um ihre OT-Sicherheit zu verbessern. Denn die Angreifersicht ist ein wertvolles Werkzeug, um Schwachstellen zu identifizieren und durch geeignete Schritte zu schließen. Darüber hinaus sind es aber auch oft die einfachen Dinge, die die Sicherheit bereits erheblich verbessern können.

Weitere Artikel zum Thema: 

Mit proaktiver Abwehr in die Offensive gehen

Die digitale Achillesferse: Moderne Endpoint Security im Kampf gegen Cyberangriffe

Absicherung von Logins: Schluss mit dem Passwort-Humbug und hin zur Problemlösung!