07.05.2014

Wagnis oder Pflicht?

Industrial Hacking

Was sind die größten Security-Risiken und -Schwachstellen meines Industriesystems? Kann ein Hacker kritische Automatisierungsprozesse beeinflussen oder sogar stören? Bin ich compliant zu industriellen Security-Regulatorien und technischen Security-Anforderungen aus aktuellen Industriestandards? Thomas Brand-stetter, Geschäftsführer der Limes Security GmbH, beschreibt, wie Anlagenbetreiber Antworten bekommen: Jeder Betreiber eines Automatisierungssystems, der ein ernstzunehmendes Interesse an der Wahrung eines sicher geführten Betriebsprozesses hat, sollte sich diese Fragen regelmäßig stellen.

Autor: Dipl.-Ing. (FH) Thomas Brandstetter, Limes Security GmbH.


Bild 1: Darstellung der bei Hacking Tests simulierten typischen Angreiferprofile inkl. zugehöriger Angriffskomplexität und Testabdeckung
Bild: Limes Security GmbH

Durch zunehmende Vernetzung der Automatisierungsanlagen und die Verwendung gängiger Softwaretechnologien sind Industrieanlagen mitunter stärker exponiert als je zuvor. Doch wie kommt man zu verlässlichen Aussagen über den Zustand der Security in den eigenen Anlagen? Welche Security-Risiken für eine bestimmte Anlage relevant sind, kann nicht pauschal beantwortet werden. Es existieren zwar eine Reihe von Standard-Bedrohungen wie bspw. infizierte Servicenotebooks oder verseuchte USB-Datenträger, ob diese jedoch für ein bestimmtes System überhaupt relevant sind und was der anzunehmende Schadensfall wäre, das muss in einer individuellen Risikoanalyse erhoben werden. Die Security-Risiken einer Industrieanlage können so individuell und unterschiedlich sein, wie die Anwendungsbereiche der Industrieanlagen selbst. Sind diese erhoben, können im Anschluss spezifische Maßnahmen definiert werden. Neben den Risiken, die am besten in Form von Interviews und Workshops bei der Risiko-Analyse erhoben werden, besteht möglicherweise auch noch die Frage nach der Compliance zu aktuellen Industriestandards. Wird eine Security-Analyse angestoßen, so ist es im Sinne der Effizienz sinnvoll, Security-Requirements aus relevanten Industriestandards gleich mit zu berücksichtigen und deren Umsetzungsstand zu erheben, um mögliche Standard-Compliance-Lücken entdecken und schließen zu können. Die spannendste Security-Frage bleibt jedoch: Kann ein Hacker kritische Automatisierungsprozesse beeinflussen und somit Ausfälle oder Schäden führen? Diese Frage kann in einem Scada Hacking-Projekt beantwortet werden, bei dem ein Angriff simuliert wird. Die dabei angewendeten Methoden als auch Werkzeuge orientieren sich dabei am aktuellen Stand der Hacking-Techniken. Besonders wichtig ist auch zu überlegen, welches Angreiferprofil simuliert werden soll: Je nach Bedrohungspotenzial und gewünschter Angriffsintensität werden vom unbedarften Script Kiddy hin bis zum professionellen Hacker einfache bis komplexe Angriffe durchgeführt. Die Angriffsintensität ist mit dem Bild eines Eisbergs gut vergleichbar: Während man durch einen kurzen Check bereits die oberflächlichen Probleme entdecken kann, muss man für einen aussagekräftigen Penetration Test, der auch die nicht offensichtlichen Probleme zeigt, mit mehr Aufwand und technischer Expertise ans Werk gehen. Das Ergebnis ist ein Überblick über die dringlichsten technischen Schwachstellen, die den Betrieb gefährden. Ein Scada-Hacking-Projekt sollte ausschließlich durch qualifizierte Spezialisten bzw. Dienstleister durchgeführt werden. Diese müssen nachweislich sowohl Wissen über Security-Testing an sich als auch explizit Know-how über Security-Prüfungen im industriellen Umfeld mitbringen. Die sehr effiziente Hau-drauf-Methode von Office-IT-Testern kann in den oft sensiblen Industrieanalagen nicht angewendet werden. Dies ist wichtig, um die Stabilität einer Industrieanlage durch Security-Tests nicht zu gefährden. Wird der Hacking-Test in einer Scada-Umgebung nicht auf Testanlagen oder während eines Wartungszeitraumes, sondern im laufenden Betrieb durchgeführt, erfordert dies besondere Sorgfalt und Vorbereitungen. Die Anforderungen an den ausführenden Dienstleister sind nochmals höher in puncto Erfahrung: Bestimmte Tests müssen vom Dienstleister ausgeschlossen bzw. anders durchgeführt werden, um die Verfügbarkeit der Anlage zur Laufzeit definitiv nicht zu beeinträchtigen. Ziel der Prüfung (Bild 2) ist sowohl Security-Risiken, Anforderungen aus Standards als auch gefährliche Security-Schwachstellen zu erfassen und im Sinne eines echten Risikomanagements ordentlich zu bewerten und schließlich zu reduzieren. Das Ergebnis für den Kunden ist die Sicherheit, dass technische Schwachstellen geschlossen werden, bevor sie zum echten Problem werden und schlimmstenfalls einen Prozessausfall verursachen. In der nächsten Ausgabe berichten wir über das zunehmend wichtigere Thema des richtigen Umgangs mit Software-Schwachstellen sowie Patch-Management.

Anzeige