SOC OT Alphabet. Warum klassischer SOC das Prozessleitsystem nicht schützt

Es ist für niemanden ein Geheimnis, dass sich die Haupterfahrung und das Fachwissen im Bereich SOC in Russland (und im Prinzip weltweit) hauptsächlich auf die Fragen der Kontrolle und Sicherheit von Unternehmensnetzwerken konzentrieren. Dies geht aus Veröffentlichungen, Berichten auf Konferenzen, Runden Tischen usw. hervor. Aber wenn sich Bedrohungen entwickeln (wir werden uns nicht an die Schmerzen von Stuxnet erinnern, aber dennoch nicht an Black / Grey Energy, Industroyer und Triton vorbeikommen) und an die regulatorischen Anforderungen des Gesetzes "Über die Sicherheit kritischer Informationsinfrastrukturen der Russischen Föderation", ist die Frage der Notwendigkeit zu decken Die Aufmerksamkeit von SOC und dem Allerheiligsten aller Industrieunternehmen liegt auf den ICS-Segmenten. Wir haben uns vor ungefähr anderthalb Jahren zum ersten Mal vorsichtig mit dieser Muschel befasst ( 1 , 2). Seitdem gab es etwas mehr Erfahrung und Forschung, und wir fühlten die Stärke, einen vollständigen Zyklus von Materialien zu starten, die sich mit SOC OT-Themen befassen. Beginnen wir damit, wie sich die Technologien und Prozesse des Unternehmens-SOC, an die wir seit langem gewöhnt sind, vom industriellen SOC unterscheiden (es wird natürlich zu Personalfragen kommen). Wenn Ihnen das Thema nicht gleichgültig ist, bitte unter Katze.







Damit die Analyse inhaltlich ist, werden wir zunächst feststellen, dass wir den SOC OT mit der Struktur des Überwachungszentrums vergleichen, das in unserem Solar JSOC implementiert ist.







Unter anderem können wir diese Unterschiede im Rahmen der Aufgaben des GosSOPKA-Zentrums erörtern, das auch für Industriesegmente zuständig ist.



Details zu jeder Ebene des Modells finden Sie in früheren Artikeln zu Infrastrukturinventar , Überwachung , Threat Intelligence ( 1 , 2 ), Sicherheitskontrolle , Personal und Prozessen.... Im aktuellen Artikel konzentrieren wir uns auf den zentralen Block der Sicherheitsüberwachung (die Merkmale der Reaktions- und Untersuchungsprozesse im automatisierten Prozessleitsystem werden in weiteren Artikeln beschrieben).



Theater beginnt mit einem Kleiderbügel und SOC beginnt mit der Überwachung



Es scheint, dass im Bereich der Ereignisüberwachung, Korrelation und Ereigniserkennung alles bereits definiert und bekannt ist. Und selbst die Überbrückung des Luftspalts zur Erfassung von Sicherheitsereignissen ist ein ziemlich bewährtes Thema . Dennoch gibt es einige Nuancen, die es definitiv wert sind, beachtet zu werden.



Allgemeine SOC-Architektur... Trotz der scheinbar einfachen Lösung mit Luftspalt ist die Situation für große Bundesunternehmen mit verteilten Einrichtungen (dies gilt insbesondere für die Elektrizitätswirtschaft) ziemlich kompliziert. Die Anzahl der Objekte wird in Tausenden gemessen. Oft ist es nicht einmal möglich, einen Ereignissammlungsserver darauf zu platzieren. Jedes der Objekte ist recht kompakt, kann jedoch signifikante Informationssicherheitsereignisse erzeugen. Selbst zusätzlich zu der beschriebenen Situation wird das Problem der Kommunikationskanäle häufig überlagert, so eng, dass zumindest eine erhebliche Belastung der Übertragung von Ereignissen zum "Zentrum" den Betrieb der Hauptanwendungen zu stören beginnt.



Daher ist die korrekte Zerlegung von SIEM-Komponenten nach Standorten eine sehr ernste Frage. Wir werden seitdem in einem unserer weiteren Materialien darauf zurückkommenDie Felder dieses Tagebuchs sind zu klein, um es zu enthalten, da ein Informationsartikel zu viel sein wird.



Spezialisierung und Profilerstellung für Anwendungsfälle . Auch ohne das Thema vollständig spezialisierter Szenarien anzusprechen, die nur für das ICS-Segment relevant sind, ist anzumerken, dass selbst Standardvorfälle im ICS eine völlig andere Bedeutung und Kritikalität haben. Wir alle sind es gewohnt, Remote Admin Tools lange Zeit in einem Unternehmensnetzwerk zu verwenden. Es ist jedoch offensichtlich, dass die Kritikalität eines solchen Vorfalls sowie im Prinzip einer erfolgreichen Kommunikation mit dem Internet in einem geschlossenen technologischen Netzwerk enorm ist. Gleiches gilt für die Installation eines neuen Systemdienstes auf einer technologischen Workstation, die Erkennung von Malware, die einer obligatorischen Untersuchung bedarf, usw.



Wesentliche Einschränkungen bei der Verwendung von Use-Case werden durch Einschränkungen bei der Implementierung von Informationssicherheitssystemen (normalerweise sind technologische Segmente nicht sehr reich an diesen) und die Verwendung veralteter, älterer Versionen von Betriebssystemen eingeführt (und Technologen betrachten die Installation von Sysmon mit Misstrauen).



Trotzdem kann eine sehr große Anzahl von Anwendungsfällen des Unternehmensumfelds erfolgreich auf das ICS-Segment angewendet werden und ein ausreichend hohes Maß an Gesamtinfrastrukturkontrolle bieten.



Nun, es ist schwer, am Allerheiligsten - den SCADA-Systemen - vorbeizukommen... Wenn auf der Ebene des Informationssicherheitssystems, der Betriebssysteme und der Netzwerkflüsse alle Segmente zumindest geringfügig gleich sind, ergeben sich wesentliche Unterschiede, wenn Sie tiefer gehen. In Bezug auf Unternehmensnetzwerke und -segmente träumt jeder von Geschäftsüberwachung und Konnektivität von Geschäftsanwendungen. Und dieser Prozess ist zwar komplex (die Protokolle mutieren und möchten nicht vorgeben, CEF zu sein, normale Informationen können jedoch nur aus der Datenbank abgerufen werden, aber Administratoren schwören und beschweren sich über die Verlangsamung), aber im Allgemeinen implementiert. Im technologischen Segment werden diese Probleme beim Verbinden von Systemen der oberen und mittleren Ebene im Zusammenhang mit der Raumkritikalität technologischer Ausfallzeiten auf ein absolutes Niveau angehoben. Um die ersten Schritte zum Anschließen der Quelle auszuführen, benötigen Sie:



  1. Stellen Sie den Stand zusammen und überprüfen Sie den Erfolg des Empfangs von Veranstaltungen
  2. Zeichnen Sie eine allgemeine architektonische Lösung mit allen technischen Details
  3. Vereinbaren Sie dies in wenigen Monaten mit dem Anbieter
  4. Überprüfen Sie erneut am Stand des Kunden mit Emulation der Kampflast
  5. Sehr sorgfältig (wie im Witz über Igel), um die Lösung in die Produktion umzusetzen


Traurigkeit, Sehnsucht, Geschäftsprozesse. Und dies trotz der Tatsache, dass die Ausrüstung des APCS in der Regel durch eine ausreichend umfangreiche, vollständige, verständliche und qualitativ hochwertige Protokollierung gekennzeichnet ist.



Glücklicherweise (oder zufällig) kann in den ICS-Segmenten normalerweise ein anderer Ansatz implementiert werden. Die meisten Protokolle in ihnen implizieren keine Verschlüsselung oder Maskierung der übertragenen Informationen. Daher ist einer der häufigsten Ansätze zum Überwachen und Analysieren von Steuerbefehlen die Implementierung von industriellen Intrusion Detection-Systemen oder industriellen Firewalls, mit denen Sie mit einer Kopie oder dem tatsächlichen Netzwerkverkehr arbeiten und Protokolle und Steuerbefehle mit anschließender Protokollierung analysieren können. Einige von ihnen verfügen unter anderem über eine integrierte grundlegende Korrelations-Engine (die uns vor dem Schrecken der Normalisierung, Kategorisierung und Profilerstellung von Ereignissen bewahrt), sind aber gleichzeitig kein vollständiger Ersatz für das SIEM-System.



, ,



Weitermachen. Es scheint, dass die Inventarprobleme im ICS-Netzwerk am wenigsten schmerzhaft sein sollten. Das Netzwerk ist ziemlich statisch, die Ausrüstung ist von gemeinsamen Segmenten isoliert, und Änderungen an der Architektur erfordern ein ganzes Arbeitsprojekt. Ein Märchen über Unternehmensnetzwerke - "Korrigieren Sie einfach das Modell und geben Sie es in die CMDB ein." Wie üblich gibt es jedoch eine Nuance: Für das ICS-Segment ist das Auftreten neuer Geräte eines der äußerst wichtigen Anzeichen für einen Vorfall oder Angriff und muss unbedingt identifiziert werden. Und bei alledem verursachen die klassischen Inventarmethoden (sparsame Betriebsarten von Schwachstellenscannern) die schwerwiegendsten Allergien bei Technologen und sogar beim Sicherheitspersonal des automatisierten Prozessleitsystems. In einem Unternehmensnetzwerk ist es nicht ungewöhnlich, dass selbst eine Bestandsaufnahme in einem erfolglosen Modus zu einem erfolglosen Zeitpunkt eine bestimmte Anwendung „platzieren“ kann.Natürlich ist niemand bereit, solche Risiken im automatisierten Prozessleitsystem einzugehen.



Daher sind die zuvor erwähnten Netzwerkverkehrsanalysesysteme und industriellen Intrusion Detection-Systeme das Hauptinventar-Tool im automatisierten Prozesssteuerungssystem (zusätzlich zur manuellen Steuerung). Jeder neue Knoten, der im Netzwerk angezeigt wird, beginnt mit seinen Nachbarn zu kommunizieren. Sowohl die Kommunikationsmethoden als auch die Kommunikationsprotokolle, die Spezifität von Paketen und Servicefeldern ermöglichen es, den neuen „Nachbarn“ nicht nur schnell zu erkennen, sondern ihn auch eindeutig zu identifizieren.



Im Gegensatz dazu ist der Prozess der Identifizierung und Verwaltung von Schwachstellen konservativer. In der Regel wird die Infrastruktur selten und auf sehr kontrollierte Weise aktualisiert und gepatcht, die Liste der Anwendungssoftware und der technologischen Ausrüstung ist festgelegt. Um die Liste und den Status der aktuellen Schwachstellen im ICS-Segment zu ermitteln, reicht es normalerweise aus, die Versionierung der Schlüsselsoftware zu ermitteln und die Bulletins der Hersteller zu überprüfen. Infolgedessen wechseln wir vom aggressiven Scan- und Softwareüberprüfungsmodus zu den Methoden der technischen und manuellen Versionsprüfung und -analyse eines Experten aus der Branche.



Der Prozess der Analyse oder Identifizierung von Bedrohungen ist auf ähnliche Weise aufgebaut. In der Regel wird ein einmaliges festes Modell entweder aufgrund eines kritischen Umbaus der Infrastruktur (Hinzufügen neuer Knoten, Aktualisieren der Firmware-Version kritischer Geräte usw.) oder aufgrund einer neuen für die Infrastruktur relevanten Sicherheitsanfälligkeit und / oder eines neuen Angriffsvektors modernisiert. Aber auch bei ihnen ist nicht alles so einfach.



OT Threat Intelligence oder träumen isolierte Netzwerke von Kompromissindikatoren



Könnten Informationen über neue Bedrohungen und Angriffsmethoden nutzlos sein? Ich möchte sofort mit „Nein“ antworten, aber versuchen wir gemeinsam, die Anwendbarkeit klassischer TI-Daten im ausgereiften OT-Segment zu verstehen.



TIs sind normalerweise Feeds (Datenströme) oder IoCs (Indikatoren für Kompromisse bei der Identifizierung bestimmter Malware- oder Hacking-Tools). Sie enthalten folgende Eigenschaften:



  • (IP-, URL, ), upload «» , . , , . , , «» .
  • (MD5- , , / ..), / / . , . , , , , whitelisting, , . – «» . TI .


Infolgedessen gewinnen bei Angriffen auf IKS Informationen über TTP, Taktiken und Ansätze von Angreifern zu einem Angriff, der auf dem TI-Markt äußerst selten ist, viel mehr an Gewicht, wodurch Verteidigungsmechanismen und Ansätze zur Überwachung und Identifizierung von Bedrohungen im Segment angemessen angepasst werden können.



Diese und viele andere Nuancen zwingen uns, den Prozess des Aufbaus eines solchen SOC oder die Wahl eines Auftragnehmers sehr ernst und nachdenklich anzugehen und ernsthaft über die Strategie zur Bildung eines OT-SOC nachzudenken. Sollte es sich mit der SOC-IT überschneiden oder getrennt davon funktionieren, kann eine Art gegenseitige Bereicherung und Synergie in Prozessen, Teams und Aufgaben gelöst werden. In unserem nächsten Artikel werden wir versuchen, die unterschiedlichen Ansätze internationaler Teams zu diesem Thema herauszustellen. Seien Sie in allen Aspekten Ihrer Infrastruktur und Ihres Lebens sicher.



All Articles