Für Betreiber kritischer Infrastrukturen sind die Security-Anforderungen nicht nur durch die generell steigende Bedrohungslage höher geworden, sondern auch durch gesetzliche Anforderungen und die steigende Digitalisierung.
Aus unserer Sicht lassen sich alle Aufgaben der IT/OT-Security und Informationssicherheit in drei Bereiche zusammenfassen. Diese sind in strategische, offensive und defensive Bereiche gegliedert. Eine Zusammenarbeit dieser Bereiche ist unabdingbar, da sie voneinander abhängig sind und voneinander bzw. miteinander lernen können.
Im defensiven Bereich setzt man hierfür zum Beispiel ein Security Operations Center (SOC) ein. Es hat die Aufgabe, alle IT/OT-Systeme zu überwachen unabhängig von Hard- oder Software, und gegebenenfalls mit Unterstützung von international agierenden Partnern (z.B. AEC). Das SOC ist außerdem in enger Abstimmung mit den anderen beiden Bereichen (strategisch und offensiv).
Eine Kernfrage, die sich uns beim Aufbau des SOC gestellt hat war, wie neue Angriffsmethoden erkannt werden können und man diese testen kann. Gerade bei neuen Zero-Day Schwachstellen ist es wichtig zu überprüfen ob die eigenen Systeme verwundbar sind und das SOC eine Ausnutzung dieser erkennt.
Um diese Frage beantworten zu können, bedarf es interner White-hat Hacker, welche anhand von neuen Angriffstechniken versuchen, in Systeme einzudringen. Sie versuchen öffentlich verfügbare PoCs (Proofs of Concept) auf das Unternehmen und dessen Infrastruktur anzupassen oder eigene zu entwickeln, um Schwachstellen auszunutzen und einer Erkennung durch das SOC zu entgehen.
Durch dieses Vorgehen entsteht eine kontinuierliches Katz- und Maus-Spiel. Ein solches lässt sich auch bei Anti-Viren Programme beobachten. Erste Anti-viren Programme arbeiteten signatur-basiert. Da Angreifer jedoch diese Signaturen umgehen konnten, zum Beispiel durch den 1-Byte Change Trick wo das erste Byte von Shellcode verändert wird, mussten neue Erkennungsmethoden entwickelt werden. Erste Anti-Viren / EDR Software begann über sogenannte Syscall Hooks die Funktionsaufrufe der WinAPI zu überwachen. Da diese Hooks im User Space definiert wurden, war es Angreifern möglich diese bei Programmstart zu entfernen, zum Beispiel indem die WinAPI Module neu in den Speicher geladen werden. Da diese Methode aktuell nicht mehr ausreicht um maliziöses Verhalten zu erkennen, verwenden aktuelle EDRs eine Kombination aus unterschiedlichen Quellen (z.B. Hooks im User-land / Kernel-land, dem Microsoft Etw-Ti Provider) um Funktionsaufrufe überwachen zu können.
Ein Beispiel aus der Praxis ist die Schwachstelle Follina. Hier wurde durch das Red Team ein eigener Proof of Concept entwickelt und getestet, ob der Code auf den Clients des Unternehemens ausgeführt werden kann. Gleichzeigt hat das Red Team Feedback vom Blue-Team bekommen, ob diese Angriffe erkannt wurden. Da zu diesem Zeitpunkt weder das EDR-Tool, noch die NTA (Network Traffic Analysis), und auch nicht die E-Mail-Security Lösung den Angriff erkannt haben, hat das Red-Team gemeinsam mit dem Blue-Team Indicators of Compromise definiert und daraus eine Hunting Query erstellt. Diese wird regelmäßig ausgeführt und benachrichtigt das Blue-Team, wenn ein neuer Angriffsversuch erkannt wird. Gleichzeitig entwickelt das Blue-Team Gegenmaßnahmen um die Schwachstelle auf den eigenen Systemen zu schließen.
Durch das ständige Testen von neuen Angriffen und der Erkennung dieser kann behauptet werden, dass ein einzelnes IT/OT-Security System zur Erkennung von Angriffen bei weitem nicht ausreicht. Daraus ergibt sich eine Systemlandschaft aus verschiedenen Tools sowohl für das Red-Team als auch für das Blue-Team.
Wichtig hierbei sind nicht die Produkte im Detail sondern die Kombination und Verschneidung der Fähigkeiten dieser Produkte. Wichtig für uns war eine einheitliche Sicht auf alle Security Alerts im Unternehmen. Deswegen war unser primärer Ansatz, alle Informationen in einem Ticket-Tool zu sammeln, um diese gesammelt darstellen zu können.
Die einzelnen Security Tools bilden eine Art Puzzle für das SOC und erkennen unterschiedliche Angriffsvektoren vom OSI Schichtenmodell 2 – 7.