Technik ist sowohl Teil des Problems als auch Teil der Lösung. Menschen, die IT nutzen und betreiben, und Betriebsprozesse, die für den IT/OT-Betrieb genutzt werden, sind gleichermaßen wichtig, wenn es um Sicherheit in der IT und der OT geht. Die sicherste Technik schützt nur eingeschränkt gegen Angriffe aus dem Cyber-Space, wenn sie nicht genutzt wird (Governance) oder die Nutzer sie umgehen (Compliance).

Grundlagen der IT/OT Sicherheit

Mit wenig zusätzlicher Governance läßt sich die Produktion vor WannaCry schützen

Governance muss zur Organisation und den Menschen passen wie gute Schuhe. Wenn die Schuhe zu eng oder zu weit sind, hat man nach kurzer Zeit Blasen an den Füßen und zieht sie nicht mehr an. Eine teure Fehlinvestition!

Legen Sie Wert auf wenige, schlanke, verständliche und konsistente Regeln und Betriebsprozesse. Dann ist die Wahrscheinlichkeit hoch, dass die Menschen und Organisationen die Regeln beachten und nach den Betriebsprozessen arbeiten.

Und auf sinnvolle Dokumentation. Sobald Ihr IT Regelwerk länger als eine Kurzgeschichte ist, können Sie sicher sein, dass es kaum beachtet wird.

Regel DMZ 1: Kein SMB/RDP Protokoll in der DMZ!

WannaCry nutzte für die Erstinfektion Systeme in Unternehmens-DMZ, die per SMB V1 Protokoll über TCP Port 445 für jeden im Internet erreichbar waren. Im SMB V1 und V2 Protokoll wurden in den vergangenen Jahren immer wieder Remote Code Execution Schwachstellen der WannaCry-Klasse entdeckt:  CVE-2016-3345, CVE-2011-1268, CVE-2011-1267, CVE-2011-0661, CVE-2011-0660, CVE-2010-2551, CVE-2010-0477, …

Um die Angriffsfläche (also die Summe aller Schwachstellen, die ein Angreifer nutzen kann, um das Unternehmensnetzwerk zu infiltrieren) so gering wie möglich zu halten, ist es ratsam, auf die Nutzung des SMB Protokolls für Zugriff vom Internet auf Systeme in der DMZ generell zu verzichten.

Das gilt auch für das RDP Protokoll: Die BlueKeep genannte Schwachstelle CVE-2019-0708 gehört zur WannaCry-Klasse, kann also auch zur Infiltrierung von Netzwerken genutzt werden.

Tipp! Generell sollte der Nutzen jedes zum Internet offenen Kommunikationsports (http, https, SMB, ssh, ftp, sftp, etc.) in der DMZ regelmäßig kritisch hinterfragt werden. Ziel dieser Aktivität ist, nur die für die Aufrechterhaltung der Geschäftstätigkeit tatsächlich notwendigen Ports offen zu halten, also die Angriffsfläche zu minimieren. Dazu gehört auch die Frage zur Protokollsicherheit (http vs. https).

Regel DMZ 2: Ist das SMB in der DMZ zwingend erforderlich: Mindestens SMB V2 Protokoll nutzen und die Systeme mit höchster Priorität patchen

Warum SMB V2 Protokoll?

Das SMB V2 Protokoll wurde mit Windows Vista/Windows Server 2008 im Jahr 2007, das SMB V3 Protokoll mit Windows 8/Windows Server 2012 im Jahr 2012 eingeführt. Alle von Microsoft gewarteten Betriebssysteme unterstützen das SMB V2 Protokoll. Das SMB V1 Protokoll muss nur zur Erhaltung der Kompatibilität mit den nicht mehr unterstützten Betriebssystemen Windows XP/Windows Server 2003 und Windows 2000 verwendet werden. Die Umstellung auf das SMB V2 Protokoll in der DMZ sollte also unproblematisch sein.

Die Umstellung auf SMB V3 führt zu Kommunikationsproblemen mit Windows 7/Windows Server 2008, da diese Betriebssysteme die Verschlüsselung der SMB Nutzdaten, die mit Version SMB V3 eingeführt wurde, nicht unterstützen.

Die Umstellung auf SMB V2 ist generell empfehlenswert, da die mit SMB V2 eingeführte kryptographische Signatur der Pakete Man-in-the-Middle Angriffe unmöglich macht.

B2B Kommunikation restriktiv einrichten.

Wird das System in der DMZ zum Austausch von Daten mit anderen Unternehmen (B2B) genutzt, so sind Punkt-zu-Punkt Verbindungen in der Firewall zu konfigurieren. Dadurch ist gewährleistet, dass nur die Partnerunternehmen die Verbindungen nutzen können.

Warum Patchen mit höchster Priorität?

Remote Code Execution Schwachstellen ohne Benutzerinteraktion (UI:N) in der DMZ müssen umgehend gepatcht werden, da Programme zur Ausnutzung von neu veröffentlichten Schwachstellen, die sogenannten Exploits, immer schneller, zum Teil in Auftragsarbeit, entwickelt und verbreitet werden.  Das gilt nicht nur für Windows und Linux. Es gilt insbesondere für alle Komponenten im Application Stack, etwa Apache, PHP, Java etc.

Wichtig! Umgehend bedeutet nicht innerhalb des normalen Windows Patch-Zyklus von 4 Wochen und länger.

Empfehlung: 2 Tage nach Veröffentlichung des Patches ist das Patch installiert und aktiviert.

Regel DMZ 3: Datenaustausch zwischen DMZ und Office-Netz: Die Kommunikation wird aus dem Office-Netz initiiert

Durch die Initiierung der Kommunikation aus dem Office Netz, etwa von System (4) zu System (2) in der unteren Abbildung, findet WannaCry auf System (2) keinen offenen SMB Port, kann sich also nicht ohne Zusatzaufwand fortpflanzen. Richten Sie auf dem Sicherheitsgateway zwischen Office Netz und Produktion eine ausgehende Regel (von System 4, Protokoll TCP, Port 445, nach System 2) ein.

WannaCry’s Weg in die Produktion.

Tipp! Regel DMZ 3 sollte im Produktionsnetz generell Anwendung finden, soweit technisch möglich. Das heißt: Die Systeme in der Produktions-DMZ sollten die Verbindung zu Systemen ins Office-Netz, die Systeme in Partition 1 die Verbindung zu Systemen in die Produktions-DMZ, etc., initiieren. Dies gilt insbesondere für die Systeme in der SIS-Zone in Partition 2, sofern für diese eine Anbindung ans Produktionsnetzwerk erforderlich ist. Für Details siehe die Empfehlung zur Betriebssicherheit EmpfBS 1115 Kapitel 4.2.

Regel PROD 1: Ausnahmen von der Nachbarschaftsregel minimieren

Für jede Ausnahme muss eine Risikobetrachtung erfolgen. Bei Ausnahmen muss immer geprüft werden, ob mit Regel DMZ 3 das Risiko reduziert werden kann.

Regel PROD 2: Bei Ausnahmen von der Nachbarschaftsregel ist das SMB/RDP verboten

Sofern ein Nutzer im Office-Netzwerk für seine Aufgaben Zugriff auf Systeme in Partition 1 oder Partition 2 benötigt, so sollte das entweder über eine sichere Fernwartungslösung oder mittels eines Jump-Servers in der Produktions-DMZ erfolgen. Wird für den Zugriff auf den Jump-Server das RDP Protokoll genutzt, so sollte das Verbinden von Laufwerken per RDP Protokoll deaktiviert werden.

Regel PROD 3: Bei Ausnahmen dürfen nur Punkt-zu-Punkt Verbindungen implementiert werden

P2P Verbindungen bieten hier den Vorteil, dass potenzielle Angreifer keine Möglichkeit haben, nach weiteren angreifbaren System zu suchen und diese als Operationsbasis zu infiltrieren.

Regel PROD 4: Mindestens alle Systeme an den Endpunkten von erforderlichen Verbindungen und Ausnahmen sind mit hoher Priorität zu patchen

Das gilt für alle Systeme an der Grenze zwischen Office-Netz und Produktions-DMZ und zwischen Produktions-DMZ und Partition 1. An der Grenze zwischen Partition 1 und Partition 2 sollten mindestens die Systeme in Partition 1 mit hoher Priorität gepatcht werden. Dies sind in der Regel keine Echtzeitsysteme, daher sollten sie auch außerhalb der geplanten Wartung zum Aktivieren der Patches neugestartet werden können.

Empfehlung: Spätestens 5 Tage nach Veröffentlichung der Patches sind diese installiert und aktiviert.

Regel PROD 5: Zugriff auf Email und Internet sind im Produktionsnetzwerk verboten

Dadurch wird das Risiko eines Cyber-Angriffs über Remote Code Execution Schwachstellen mit User Interaction None deutlich verringert.

Etwas Compliance ist notwendig, damit die wenigen Regeln eingehalten werden.

Führen Sie regelmäßig Erweiterte Assessments der Firewall- bzw. Kommunikationsregeln für alle Sicherheitsgateways durch:

  • Jede Firewall Regel muss im Hinblick auf die Regeln DMZ 1 – 2 und PROD 1 -4 hinterfragt werden.
  • Jede Ausnahme der Nachbarschaftsregel muss hinterfragt werden. Die Risikobetrachtung für die Ausnahmen muss regelmäßig aktualisiert werden.
  • Für jede Ausnahme und Firewall Regel ist zu hinterfragen, ob sie noch notwendig ist.
    Wichtig! Die beste Firewall Regel ist diejenige, die nicht vorhanden ist.
  • Der Patchzustand aller Systeme an den Endpunkten der Kommunikationsregeln muss untersucht werden. Mindestens alle Remote Code Execution Schwachstellen mit UI:N im Betriebssystem und im Application Stack müssen gepatcht sein. Abweichungen sind umgehend zu beheben.

Welche Maßnahme kann man zur Erhöhung der Widerstandfähigkeit gegen Remote Code Execution (RCE) Schwachstellen mit User Interaction Required, UI:R, ergreifen?

Nicht alle Bedrohungen kommen jedoch ohne Interaktion der Benutzer aus. Diese sollten jedoch trotzdem nicht außer Acht gelassen werden. Aus diesem Grund folgenden hier nochmal drei Regel für Schwachstellen die eine Beihilfe der Nutzer benötigen.

Maßnahme USER 1: Think before you Klick!

Der Angreifer ist auf die Mitarbeit des Opfers angewiesen – wenn sich das Opfer verweigert, ist die Ausnutzung der Schwachstelle nicht möglich! Der Benutzer ist die wichtigste Komponente in der Prävention von Cyber-Angriffen, die sogenannte First Line of Defense. Regelmäßig das Thema Cyber-Sicherheit, insbesondere Phishing-Techniken, auf die Tagesordnung von Betriebsbesprechungen bringen hilft dem Anwender neue Phishing-Methoden zu erkennen und zu ignorieren.

Maßnahme USER 2: Nie mit permanenten administrativen Berechtigungen arbeiten.

Aufgrund der großen Zahl von RCE Schwachstellen mit User Interaction sollten Anwender nie mit permanenten administrativen Berechtigungen arbeiten. Die Benutzerkontensteuerung bietet eine elegante Möglichkeit, bei Bedarf einzelne Prozesse mit höheren Berechtigungen auszuführen. Die Einrichtung dauert nur wenige Minuten.

Generell sollte die Benutzerkontensteuerung auf „Immer Benachrichtigen“ eingestellt werden. Dadurch wird verhindert, dass sich ein Angreifer, der sich per RCE Schwachstelle im Sicherheitskontext des Anwenders auf einem System festgesetzt hat, einfach mit Windows Bordmitteln erhöhte Berechtigungen (Auto-Elevation) beschaffen kann. Zudem werden einige Funktionen in Systemen, die für Cyber-Angriffe genutzt werden, blockiert. Auf Anwender ohne Privilegien auf einem Computer hat dies keine Auswirkungen, Administratoren müssen häufiger ein Passwort eingeben.

Immer Benachrichtigen!

Maßnahme USER 3: RCE Schwachstellen mit User Interaction mit Priorität patchen

Auch wenn die Auswirkungen von RCE Schwachstellen mit User Interaction in der Regel weniger gravierend sind dürfen sie unter keinen Umständen ignoriert werden. RCE Schwachstellen in Programmen, mit denen Anwender mit Diensten im Internet agieren (Browser wie Internet Explorer, Edge, Firefox, Chrome, Office Programme, Acrobat Reader, Flashplayer, etc.), sollten nach Veröffentlichung der Schwachstellen mit hoher Priorität gepatcht werden.

Empfehlung: 2 – 5 Tage nach Veröffentlichung der Patches sind diese installiert und aktiviert.

Jetzt sind Sie an der Reihe! Nutzen Sie die Auflistung für Ihre Compliance- und Governance- Richtlinien, um die Widerstandsfähigkeit Ihres Anlagennetzes gegen WannaCry-artige Bedrohungen zu erhöhen.