Proof of Concept für industrielle IT-Security-Lösungen

Es gibt viele gute Gründe für einen Proof of Concept (PoC), bevor man neue Technologien einsetzt. Angefangen damit, das Projektrisiko zu reduzieren und intern Gewissheit zu erlangen, dass die gewählte Lösung zum konkreten Anwendungsfall passt. Diese 5 Aspekte sind bei einem Proof of Concept für ICS-Sicherheit zu bedenken.

Um die richtige Cybersicherheitslösung zu finden, konzentriert sich ein PoC jedoch auf das Projektmanagement (auch als Scoping bezeichnet, die eigentliche Planung und wie man dabei alle Aspekte unter einen Hut zu bringt). Eine nicht zu unterschätzende Rolle spielen Softskills wie der Beziehungsaufbau, die eigentlichen Verhandlungen und nicht zuletzt Geduld. Und es schadet ganz und gar nicht, sich an Best-Practices der Branche zu orientieren.

Ich persönlich war an mehreren PoCs im Umfeld kritischer Infrastrukturen beteiligt – von der Implementierung von Firewalls bis hin zu komplexen Systemen zur Netzwerküberwachung. Im Zuge dessen wurde ich mehrfach danach gefragt, welches die wichtigsten Überlegungen bei der Planung eines erfolgreichen Proof of Concept sind. 

Warum einen Proof of Concept für Industrial Control Systems (ICS)-Sicherheit?

Ein PoC verbessert in aller Regel die Erfolgswahrscheinlichkeit eines Technologieprojektes. Das liegt zum einen daran, dass man ein tieferes Verständnis für das eigene Anforderungsprofil entwickelt. Ist die Transparenz des ICS-Netzwerks wichtiger oder will man zuallererst wissen, wo genau die Schwachstellen liegen? Oder geht es darum die betriebliche Infrastruktur gegen Cyberbedrohungen widerstandsfähiger zu machen? Ein PoC zwingt Sie dazu, die Anforderungen möglichst genau zu definieren und auf dieser Basis eine

Value Proposition für das Projekt zu erstellen. Die wiederum wird an die Führungsebene kommuniziert und im Idealfall genehmigt. IT und OT sollten sich im Rahmen des PoC auf ein gemeinsames Ziel hin ausrichten. Darüber hinaus beweist ein PoC (oder auch nicht), dass die vorgeschlagene Lösung Ihren Anforderungen entspricht und Sie darauf vertrauen können, dass die ausgewählte Technologie die richtige für das betreffende Unternehmen ist.

5 Aspekte, die Sie bei Ihrem Proof of Concept für ICS-Sicherheit bedenken sollten

• Problemstellung und Anwendungsfälle von Grund auf kennen – Zu den typischen PoC-Ergebnissen gehört es eine Problemstellung zu entwickeln, Anwendungsfälle zu identifizieren, den Projektumfang zu definieren und einen Projektplan zu erstellen, Erfolgskriterien und ein Bewertungsmodell (Scoring-Modell) auszuwählen und einen Zeitplan für das Projekt zu entwerfen. Anwendungsfälle und eine präzise ausgearbeitete Problemstellung tragen dazu bei, dass Projekt und PoC auf Kurs bleiben. Problemstellungen definieren den Bedarf aus der Adlerperspektive. Anwendungsfälle beziehen sich demgegenüber auf spezifische Aspekte des Problems und zeigen mögliche Lösungen für die Bedarfe auf. Ohne die Problemstellung formuliert zu haben und mindestens einen im Vorfeld identifizierten Anwendungsfall müssen die Erfolgskriterien ad hoc definiert werden. Das erhöht leider die Wahrscheinlichkeit, dass der PoC scheitert.
   
• Konzentrieren Sie sich auf objektive Kennzahlen und setzen Sie subjektive Metriken sinnvoll ein – Die wichtigsten objektiven Kennzahlen für eine spezifische Betriebsumgebung funktionieren in der Regel nach dem Muster schwarz oder weiß. Die Lösung kann in eine SIEM-Lösung von FireEye integriert werden oder nicht. Sie bietet passive und aktive Netzwerküberwachung oder nicht. Sie unterstützt das Siemens S7-ICS-Protokoll oder nicht.

  Aber bei rund fünfzehn Prozent der üblichen Bewertungsmodelle für einen PoC handelt es sich um subjektive Kennzahlen. Bei der Durchführung eines PoC gemeinsam mit Lösungsanbietern zur Netzwerküberwachung haben wir beispielsweise ein Erfolgskriterium ausgewählt, das auf der Unternehmenskultur des Partners basiert. Natürlich muss der betreffende Anbieter die technischen Anforderungen erfüllen. Aber wir wollten auch sicherstellen, dass das ausgewählte Unternehmen mit uns so gut wie möglich zusammenarbeiten würde. Das ist vor allem dann entscheidend, wenn man mit unerwarteten Herausforderungen konfrontiert wird.

  Aber auch, wenn man über den Tellerrand hinaus denken muss, um durch innovative Lösungen wettbewerbsfähig zu bleiben. Gibt es eine objektive Metrik, mit der man die Kultur eines Unternehmens bestimmen kann? Eher nicht. Beziehungen entwickeln sich im Laufe der Zeit und über vielfältige Interaktionen zwischen den Mitarbeitern beider Unternehmen. Trotzdem ist dieses Konzept zu einem stark gewichteten Kriterium in unserem Auswahlprozess geworden. Der Markt für kontinuierliche Überwachung von betrieblicher OT und kritischen Infrastrukturen ist noch relativ jung. Es ist also noch mit einigen Veränderungen, wenn nicht Verwerfungen zu rechnen. Umso wichtiger ist es dann mit einem Unternehmen zusammenzuarbeiten, das ähnliche Werte hat und ernsthaft an einer Zusammenarbeit über Jahre des Wachstums und Wandels interessiert ist.
   

• Scope Creep oder wie Projekte sich schleichend ausweiten – Egal wie sehr man versucht, diese Entwicklung in Grenzen zu halten, der Umfang eines Projekts hat die Tendenz sich schleichend auszuweiten. Entweder kommt man dieser Tendenz zuvor oder man bereitet sich so vor, dass man schon frühzeitig entscheidet, wie man damit umgehen will. Den Umfang auszuweiten muss nicht zwingend schlecht sein. Wenn Sie mit anderen Anbietern zusammenarbeiten tauchen vielleicht neue Ideen auf, die gut fürs Projekt sind. Und die helfen, die tatsächlich beste Lösung zu finden. Es gibt natürlich auch den umgekehrten Fall, bei dem Ideen eher vom Kern der Problemstellung ablenken und so das Projekt in eine unerwünschte Richtung ausweiten. Man benötigt innerhalb des

  PoC-Frameworks einen Mechanismus, um zu bewerten, ob es sich um eine erwünschte oder unerwünschte Ausweitung des Projektumfangs handelt. Nach diesem Kriterium entscheidet man bei jedem Fall, ob er ein- oder ausgeschlossen werden soll.
   

• Testumgebung – Bei Betreibern von kritischen Infrastrukturen wie in den Branchen Öl & Gas oder Energie- und Wasserversorgung wird ein PoC selten in der Produktions-umgebung durchgeführt. Der Erfolg des Projekts hängt davon ab, wie genau die Produktionsumgebung in der Laborsituation simuliert werden kann. Stellen Sie sicher, dass das Testlabor dieselbe Infrastruktur mit derselben Konfiguration und Firmware wie in der betreffenden Produktionsumgebung verwendet.
   
• Executive Buy-in – Die Planung eines PoC beginnt damit, dass man einen „Champion“ identifiziert. Damit ist unabhängig von der Bezeichnung jemand gemeint, der ein tiefes Verständnis für die Problematik sowie für die gesamte Umgebung und die Bedingungen mitbringt, unter denen Sie operieren. Diese Person spielt eine entscheidende Rolle. Sie sorgt dafür, dass das Projekt vorankommt, indem sie die richtigen Stakeholder/ Sponsoren und Teammitglieder an Bord holt.

  Will man Hindernisse beseitigen und Fristen einhalten ist zudem eine gewisse Schnelligkeit gefragt. Unabhängig davon, ob das Projekt vom Management (Top-Down) oder von Mitarbeitern an der Basis (Bottom-Up) gesteuert wird, der Executive Buy-in ist ein entscheidender Schritt in diesem Prozess. Eine Person aus dem Führungsteam muss bestimmt werden und sich uneingeschränkt dafür einsetzen, eine Lösung für die Problemstellung zu finden. Und sie muss bereit und in der Lage sein die notwendigen Finanzmittel zuzuweisen oder zu budgetieren. Wenn es sich um ein Bottom-Up-Projekt handelt, muss man zusätzliche Arbeit leisten. Um ein Buy-In für das Projekt, die definierte Problemstellung und die vorgeschlagene Lösung zu bekommen, braucht man meistens Geduld. Fehlt allerdings die Zustimmung der Führungskräfte ist ein PoC zum Scheitern verurteilt.