Als Teamlead Service unterstützt du Rhebo-Kunden täglich bei der OT-Sicherheit. Was sind die größten Herausforderungen für Unternehmen, wenn sie OT-Sicherheit bei sich umsetzen?

René Krause

Teamlead Service

Anne Grätz

Teamlead Inside Sales

Du hast als Teamlead Inside Sales oftmals den ersten Kontakt mit potenziellen Kunden. Wie ist mittlerweile das Verständnis für OT-Sicherheit bei Unternehmen? Welche Bedenken hörst du am häufigsten?

Das Verständnis hat sich in den letzten Jahren insbesondere in Unternehmen, die zu den kritischen Infrastrukturen gehören, deutlich gewandelt. Die Unternehmen, mit denen ich in Kontakt bin, nehmen das Thema "OT-Sicherheit" ernst und bauen intern entsprechende Strukturen auf. Für sie ist das Thema vorrangig aufgrund der Compliance-Frage wichtig.

Bei Unternehmen, die nicht unter die gesetzlichen Schwellenwerte fallen, sieht das aber anders aus. Dort herrscht noch immer häufig die Ansicht vor, dass eine Firewall ausreicht. Das liegt zum einen daran, dass sie bisher mit den Firewalls ganz gut fahren, weil es wenige, zumindest sichtbare Angriffe gibt. Zum anderen fehlt noch immer eine klare gesetzliche Definition für ein System zur Angriffserkennung. Die Orientierungshilfe des BSI gibt zwar einige Hinweise, ist aber noch sehr erklärungsbedürftig und unklar, wie so ein System zur Angriffserkennung konkret aussieht oder was das nun ist. Es liegt damit an uns, diese Definition und Erklärungen zu liefern.

Ich schätze, dass sich das Bewusstsein für OT-Sicherheit und die Notwendigkeit eines Systems zur Angriffserkennung in den zwei nächsten Jahren gerade auch mit NIS2 noch einmal wandeln wird.

Eine Frage an:

Martin Menschner

Als Pioniere der OT-Sicherheit begann die Geschichte von Rhebo zu einer Zeit, in der dieses Thema noch kaum jemandem bekannt war. Wir haben Martin Menschner, einen der Gründer des Unternehmens, dazu befragt:

„Du hast bereits 2013 mit der Entwicklung des Prototyps von Rhebo Industrial Protector begonnen, als OT-Sicherheit noch völlig unbekannt war. Wie bist du an die Entwicklung herangegangen, was waren deine Prämissen?“

Auf diese Frage antwortet Martin: Wir wollten die Produktvision unbedingt mit unseren Kunden zusammen entwickeln, um ihre Anforderungen und Bedürfnisse direkt zu berücksichtigen und die Umsetzung schnell testen zu können. Aus diesem Grund folgten wir dem Ansatz der agilen Softwareentwicklung.

Aufgrund meiner Erfahrungen in den Bereichen IT-Sicherheit und Netzwerkanalyse habe ich im ersten Schritt eine schlanke Deep-Packet-Inspection-Plattform implementiert, die erst einmal grundsätzlich in der Lage war, Datenpakete aufzuzeichnen und die Header der einzelnen Protokolle zu analysieren. Die dadurch erhobenen Metadaten wurden statistisch ausgewertet und im zeitlichen Verlauf dargestellt. Auf Basis dieser Daten sollten sinnvolle Alarme generiert werden. Glücklicherweise hatten wir Zugang zu mehreren potentiellen Kunden aus verschiedenen Bereichen, sowohl in der produzierenden Industrie als auch der Kritischen Infrastruktur.

Im Laufe mehrerer Demos und Teststellungen waren wir dank des sehr umfangreichen Kundenfeedbacks in der Lage, die Produktvision immer weiter zu schärfen. Ein wesentlicher Punkt dabei war der Zugang zu echten Netzwerkdaten aus Produktivnetzen. OT-Protokolle sind jeweils sehr spezifisch für ihr jeweiliges Umfeld und selbst im Laboraufbau zeigen sie oft ein anderes Verhalten als in einer realen Umgebung. Die meisten dieser Teststellungen des Rhebo Industrial Protector gingen aufgrund der kontinuierlichen Weiterentwicklung der Software quasi schleichend in den Produktivbetrieb über.

Dabei wurde nicht nur berücksichtigt, welche Arten von Statistiken und Alarmen den Kunden den meisten Nutzen brachte, sondern auch, wie diese Daten am besten dargestellt werden können. So war es zum Beispiel nötig, häufig auftretende Warnungen zusammenzufassen. Ein weiterer wichtiger Schritt war die Einbindung in die vorhandene Infrastruktur der Kunden. Anfangs lief Rhebo Industrial Protector zumeist noch vollkommen isoliert, so dass Alarme ohne Weiteres ignoriert werden konnten. Später jedoch war durch die Weiterleitung der Alarme in die Leitstellen der Kunden eine 24/7-Überwachung möglich. So formte sich die Software, einem agilen Entwicklungsmodell folgend und stets dem Feedback aus der Kundenrealität angepasst, mehr und mehr zu einem ausgereiften Produkt.