Aspekte der OT-Security, Teil 4
Ein SOC für IT und OT
Umgebungen, in denen IT-Komponenten steuernd in die "wirkliche Welt" eingreifen, lassen sich mit Standardrezepten der Security nicht immer wirksam und zugleich ohne Nebenwirkungen schützen. Produktionsanlagen, Kliniken und IoT-Konstrukte verlangen nach neuen Ansätzen für die Sicherheit. Ein Security Operations Center für OT (Operational Technology) gehört zu diesen Konzepten. Es einzurichten ist kein Hexenwerk - verlangt aber nach einer klug optimierten Architektur.
Die Digitalisierung von Produktionsanlagen bedeutet grundsätzlich auch deren immer intensivere Vernetzung mit Büro-LANs, Intranets, Cloud-Diensten und dem Internet. Das macht die Systeme verletzlich für Manipulationen - und genau dies weckt starke Interessen aus dem Dark Web. Dabei schlägt zu Buche, dass sich mit Eingriffen in Herstellungsprozesse relativ leicht besonders große Effekte erzielen lassen. So könnte man beispielswei-se Produktionsausfälle und Qualitätsschwankungen bei Produkten inszenieren, die ganze Ketten von Just-in-Time-Prozessen aus dem Lot bringen und damit sofort auch Partner und Kunden der Betroffenen erreichen. Aus diesem Grund sind Angriffe auf OT-Umgebungen auch schwer aus den Medien herauszuhalten. Hinzu kommt das Risiko, dass außer Kontrolle geratene - oder besser: unter fremder Kontrolle stehende - Maschinen direkt die an ihnen tätigen Menschen gefährden können. So haben Angreifer zum Beispiel die Malware Triton gezielt dazu entwickelt, in Produktionsumgebungen Mechanismen für den Schutz von Menschenleben in Produktionshallen abzuschalten [1]. Manipulierte Produkte wiederum werden womöglich den Endkunden zum Verhängnis.
Angst vor folgenreicher Sabotage
Aus all diesen Konstellationen lassen sich Bedrohungs- und speziell Erpressungsszenarien ablesen, über die sich die Unternehmen zunehmend Sorgen machen - und sei es nur deshalb, weil sich Kunden immer häufiger per Audit bestätigen lassen wollen, dass ein bestimmter für sie wichtiger Produktionsschritt hinreichend gegen Sabotage geschützt ist. Die richtige Schlussfolgerung aus dieser Misere lautet: Ein vorzeigbares Bedrohungs-Management muss her, das die Risiken verringert. Man wünscht sich dann fast immer ein Security Operations Center (SOC), dessen Team in der Produktion ganz ähnlich wie in der klassischen Business-IT nach Anomalien und bekannten "Kill Chains" Ausschau hält - also nach andernorts bereits aufgefallenen Angriffsschritten, die als Teile ausgefeilter Attacken fungieren. In der IT würde man entsprechende Einsatzzentren dazu mit SIEM-Systemen (Security-Information- und Event-Management) ausstatten oder sich spezieller Tools bedienen, die im Netzwerk-Traffic nach Auffälligkeiten fahnden.
Produktionsanlagen allerdings sind intern und häufig auch nach außen auf eine spezifische Weise vernetzt, mit der die üblichen IT-Security-Produkte nicht unmittelbar etwas anfangen können. Sie stellen - sofern sie überhaupt Log-Daten-sammeln - keine Standard-Log-Quellen für ein SIEM zur Verfügung, und die Pakete ihres Netzwerk-Traffics mit seinen spezifischen Protokollen sagen einem IP-Analysewerkzeug aus der IT zunächst nur wenig. Hinzu kommt, dass die Systeme - zuweilen individuelle Eigenentwicklungen des jeweils internen Maschinenbaus - mitsamt ihren Steuerungsrechnern oft 40 Jahre oder noch länger laufen, bevor das Unternehmen sie ersetzt, und dass sie in vielen Fällen nicht mit neuer Software ausgestattet werden können oder dürfen. Wollte man eines der bekannten Standard-SIEM-Produkte - ArcSight, IBM QRadar, LogRhythm etc. - ohne grundlegende Modifikation auf diese Welt ansetzen, wäre zunächst eine aufwändige Neuentwicklung von Schnittstellen, Konnektoren und Parsern fällig, und zwar meist gefolgt von einem nicht minder zeit- und ressourcenintensiven Training der Anomalie-Erkennungsmechanismen.
Dennoch ist die Grundidee, Daten aus den Produktionsnetzen auch den IT-Monitoring-Tools zur Verfügung zu stellen, durchaus richtig. Würde man die Erkennung möglicher Angriffsvorgänge nur einerseits auf die IT und andererseits aufs OT-Umfeld richten, also mit zwei SOCs oder zumindest zwei getrennten Überwachungskonsolen arbeiten, hätte man ein Problem: Dann würden Aktivitäten, die sich über beide Bereiche erstrecken, der jeweiligen Korrelationslogik samt angeflanschter oder integrierter künstlicher Intelligenz und den überwachenden Spezialisten an den Bildschirmen leicht entgehen.
Business-IT und OT erfassen
Genau auf diese Weise allerdings werden geschickte Angreifer vorgehen: Sie würden die Schnittstellen zwischen beiden Bereichen erkunden und sich dann mal hier, mal dort Schritt für Schritt vorantasten, ohne dabei aufzufallen. Vor diesem Hintergrund fördert ein gemeinsames OT/IT-SOC sogar die Kooperation zwischen den getrennten OT- und IT-Security-Teams, weil es die gemeinsame Abwehr von Angreifern in den Mittelpunkt rückt [2].
Manches Unternehmen aus den einschlägigen Herstellungsbranchen bemerkt interessanterweise erst neuerdings, dass die Digitalisierung dabei nicht nur die Produktionssysteme aus Richtung der nun angeschlossenen Business-IT gefährdet, sondern dass sich für Hacker auch die Chance eröffnet, aus einer mangelhaft geschützten OT-Sphäre auf einem neuen Weg in die IT-Umgebung vorzudringen.
Eine weitere Erkenntnis ist, dass sich ein Angriff auf die Produktion möglicherweise nicht nur an typischen Security-Informationen wie Virenbefall und missglückten Anmeldeversuchen an einem Leitstand erkennen lässt, der einer Maschine direkt zugeordnet ist. Ungewöhnlich stark ausgeprägte Temperaturschwankungen und daraus resultierender hoher Materialausschuss eines Brennofens können ein Warnsignal sein, wenn zugleich eine an sich ebenfalls harmlose Anomalie an genau demjenigen Büro-PC auftritt, der als einziger eine direkte Datenverbindung zur Steuerungslogik des fraglichen Ofens aufweist.
Die gute Nachricht ist, dass Abhilfe bereits existiert. Hersteller wie Nozomi und CyberX haben mit Know-how aus der Welt der Industriekontrollsysteme (Industrial Control Systems, ICS) und der dort verwendeten Protokolle Überwachungslösungen entwickelt, die mit den Besonderheiten der Industrievernetzung zurechtkommen. Eine nachweislich gute Verwurzelung eines Anbieters und seiner Mitarbeiter in der Produktionswelt ist dabei ein "weicher" Faktor, der harte Vorteile bietet. Denn typische IT-ler und deren Lösungsansätze haben bei den Maschinenbauern und Wartungsteams der Unternehmen aus guten Gründen nicht immer einen guten Ruf. Dessen Ursachen hat ein früherer Beitrag dieser Serie bereits ausführlich diskutiert - im Kern spielt unter anderem die Tatsache eine Rolle, dass die OT-Welt aufgrund ihrer Fixierung auf das Sicherheitsziel "Verfügbarkeit" keine Security-Techniken akzeptiert, die das Echtzeitverhalten der Systeme beeinflussen oder die beim direkten Eingreifen der Praktiker auf die Anlagen in der Produktionshalle hinderlich sind.
OT-spezifische Erkennungslogik
Der "Trick", der die beschriebenen Probleme wirksam aushebelt, ist der Einsatz einer OT-spezifischen Erkennungslogik und OT-spezifischer Sensorik für die Produktionsumgebungen zusammen mit der flexiblen Weiterleitung der erkannten Details an klassische SIEM-Lösungen oder äquivalente Produkte. Dabei gehen die OT-Monitoring-Werkzeuge in einigen Fällen als stark integrierte "Plug-ins" oder "Apps" komplett in der Konsole des Master-Systems auf. Diese Architektur erlaubt die oben geforderte Korrelation von Anomalien und Alarmen aus beiden Systemen, ohne dass man in das IT-Monitoring-Tool selbst eingreifen muss.
Als Beispiel soll hier CyberX dienen. Das als Appliance oder virtuelle Maschine gelieferte Produkt schließt man über einen Span-Port oder einen Netzwerk-TAP an. Es sammelt und scannt ICS-Traffic passiv und ohne Einsatz von Agenten, aktive Scans von OT-Geräten finden nicht statt. Die meisten der in der OT-Welt gefürchteten "Nebenwirkungen" von Sicherheitsmaßnahmen auf die Produktionsanlagen sind somit von vornherein ausgeschlossen. Primär arbeitet das System mit Deep Packet Inspection, allerdings für Industrieprotokolle seriell wie auch mit Geräten, die per Ethernet vernetzt sind. Da den Entwicklungsteams OT-Spezialisten angehören, kann ein spezialisiertes Unternehmen wie CyberX auch proprietäre oder sogar eigenentwickelte Protokolle analysieren und nach verhältnismäßig geringer Entwicklungszeit unterstützen.
2. Assessment-Praxis: Assessments für die OT/IIoT-Sicherheit (siehe LANline 9/2018, S.36ff.)
3. Zutritts- und Zugriffs-Management (siehe LANline 10/2018, S.36ff.)
4. Ein SOC für IT und OT
OT-spezifische Erkennungsalgorithmen und Funktionen automatischen Lernens erlauben zum Beispiel die Erkennung unerlaubter Fernzugriffe auf der Basis OT-spezifischer Verbindungstechnik. Sie decken außerdem auf, wenn die Kommunikation zwischen Geräten vom Protokoll oder vom Kontext her außergewöhnliche Parameter transportiert oder einschlägige Protokollstandards verletzt werden. Auch unerklärlichen Konfigurationsversuche an kritischen Systemen lassen das System ansprechen. Auf der Basis einer Analyse real existierender OT-Netzwerke können Fachleute eine große Zahl typischer Protokolle aus der ICS- und Scada-Welt sofort beobachten. Außerdem macht diese Grundlage eine weitgehend automatische Discovery möglich, also das Auffinden und Kartografieren von Steuerungssystemen bekannter Maschinenbauer im Netz. Die protokollgestützte Technik reduziert den gefürchteten Zeitaufwand für ein Vorgehen, bei dem man Schnittstellen zu entsprechenden Informationsquellen individuell entwickeln muss.
Für OT-typische Angriffe leisten sich Anbieter wie CyberX spezifische Threat-Intelligence-Teams, die beispielsweise auf ICS-Systeme zugeschnittene Malware und Angriffstaktiken sowie Verwundbarkeiten (Vulnerabilities) ausfindig machen, analysieren und wie bei IBM QRadar, LogRhythm und Vectra in der IT den eigenen Appliances als Erkennungsmuster zuspielen. Das System kann Alarm schlagen, wenn es Hinweise auf Angriffsschritte findet, die einem bereits andernorts festgestellten kriminellen Vorgehen entsprechen, wenn zugleich der Kontext beim Kunden zum Kontext des Angriffsmusters passt. Die Malware-Erkennung erfolgt verhaltensbasiert, ist also nicht allein signaturabhängig. Ebenfalls aufmerksam machen wird das System auf Funktionsanomalien wie eine plötzlich immer wieder und immer häufiger abbrechende und neu anlaufende Produktionsnetz-Kommunikation. Entsprechendes Verhalten könnte unabhängig von der Ursache ein Hinweis auf einen sich anbahnenden Ausfall sein. Auch eine Aufbereitung von Daten für forensische Zwecke ist vorgesehen. CyberX geht hier besonders weit, weil der Hersteller dafür eine eigens entwickelte OT-Sandbox integriert.
OT-Netze sind vorhersagbarer
Im Grunde lässt sich ein solches System als Variante bekannter NBA-Werkzeuge (Network Behavior Analysis) verstehen, wie sie für die IT-Welt existieren. Dort werden sie zuweilen als Alternative zu SIEM-Systemen gehandelt, kommen in der Praxis aber häufig ganz ähnlich wie im oben beschriebenen Szenario als "Zulieferer" und Sensorikerweiterung für SIEM-Tools zum Einsatz. Diese steuern ihrerseits die von diversen Security-Normen streng geforderte Log-Aufbewahrung und -Analyse bei. Tandems aus NBA und SIEM sind also eine erprobte Best Practice. Im OT-Integrationsfall darf man sie wegen ihrer nebenwirkungsarmen Funktionsweise in der OT-Sphäre sogar als Mittel der Wahl bezeichnen.
Welches Werkzeug ein Anwender auswählt, sollte er primär anhand einer vorgeschalteten Bedrohungsanalyse (siehe zweiter Beitrag dieser Serie) und auf der Basis der Liste jener Protokolle bestimmen, die er in seinen Produktionsnetzen findet. Hilfreich kann überdies eine Testinstallation sein, bei der das jeweilige Tool demonstriert, wie viele der vorhandenen Elemente der Infrastruktur es tatsächlich erkennt. Dies nämlich entscheidet darüber, wie schnell und mit wie vielen oder besser mit wie geringen Ressourcen der Status der produktiven Aktivschaltung zu erreichen ist. Generell gilt, dass die verwendete passive NBA-Technik schon recht kurze Zeit nach der ersten Aktivierung Resultate - erkannte Anomalien - liefern kann, wenn sie die meisten der zu beobachtenden Protokolle schon "out of the box" kennt.
Dem Einsatz von Anomalie-Erkennungsmechanismen und künstlicher Intelligenz (KI) im OT-Umfeld kommt es generell entgegen, dass in typischen Produktionsnetzen die Kommunikation weit vorhersagbarer abläuft als in IT-Netzen. Während die Büro-IT die Definition eines "Normalverhaltens" durch immer neue Applikationen, Geräte und Geschäftsprozesse erheblich erschwert, kommen entsprechende Umbrüche bei den lang laufenden Anlagen in den Produktionshallen nur selten vor. Dies verkürzt die Lernphasen für die automatische Bedrohungserkennung erheblich.
Ein Fall für Arbeitsteilung
Die Arbeit mit einem vorgeschalteten OT-spezifischen NBA-Tool und einem nachgeschalteten, übergeordneten SIEM-Werkzeug kommt einer Besonderheit zugute, die mit der "Response" in produzierenden Unternehmen zu tun hat, also mit der Gegenwehr gegen bereits angelaufene Angriffe. Reine IT-Organisationen, die mit stark standardisierten Geschäftsanwendungen und Büro-PCs arbeiten, können die Überwachung ihrer Infrastruktur und die Einleitung von Gegenmaßnahmen in hohem Maße outsourcen, da die Reaktionen verbreiteter Softwareprodukte auf Eingriffe von außen - etwa Abschaltungen - weitgehend bekannt und vorhersagbar sind. Bei Produktionsmaschinen, die eine vorgegebene Rolle in zeitkritischen Abläufen spielen, ist dies anders. Man muss hier das Team an den Bändern, Robotern oder Fertigungsstraßen hinzuziehen, wenn aus Security-Gründen etwa die Lahmlegung eines speziellen Leitstands oder Steuerungsrechners angeraten erscheint. Drückt das Security-Team eine derartige Maßnahme unsensibel und ohne Kontaktaufnahme mit den Mitarbeitern am Band durch, kann das gravierende und sogar schlimmere Folgen haben als der Angriff selbst. Die Fragen an den Leitstand vor Ort lauten:
- Ist vielleicht ein kontrollierter Übergang auf manuelle Steuerung besser als eine Ad-hoc-Abschaltung?
- Soll man das Risiko eingehen, ein paar Minuten zu warten?
- Muss sich jemand erst einmal in Sicherheit bringen?
Dies wohl wissend, neigen produzierende Unternehmen bei der SOC-Einführung häufig dazu, zwar das Rund-um-die-Uhr-Monitoring an einen Managed-Service-Provider zu vergeben, die Response im OT-Sektor aber in den eigenen Händen zu behalten - selbst wenn Anbieter wie CyberX diese Response inzwischen auch als Managed Service anbieten. Die in diesem Beitrag favorisierte Architektur unterstützt die Kommunikationsprozesse, die mit dem Hybrid- oder Arbeitsteilungskonzept einhergehen: Das OT-NBA-Tool liefert seine Erkenntnisse an das globale SIEM, zugleich aber auf einen Bildschirm im Produktionsleitstand. Schlägt dann das SOC Alarm, ob nun mit oder ohne Unterstützung externer OT-Security-Spezialisten, hat der OT-Verantwortliche vor Ort die aus einem Bereich stammenden kritischen Daten bereits vor Augen. Dadurch kann die Absprache über das bestmögliche Abwehrverhalten schneller gelingen als ohne diesen Aufbau.
Lesen Sie mehr zum Thema
