DE102016103521A1

DE102016103521A1 - Erkennung von Anomalien in industriellen Kommunikationsnetzen

Info

Publication number: DE102016103521A1
Application number: DE102016103521.1A
Authority: DE
Inventors: Robert A. Mixer; Gary Keith Law; Andrew E. Cutchin
Original assignee: Fisher Rosemount Systems Inc
Current assignee: Fisher Rosemount Systems Inc
Priority date: 2015-03-04
Filing date: 2016-02-29
Publication date: 2016-09-08
Also published as: CN105939334A; GB2537457A; GB201602098D0; CN105939334B; JP6749106B2; US20160261482A1; US10291506B2; GB202113105D0; GB2537457B; JP2016163352A

Abstract

Ein in einem Anlagenkommunikationsnetz installiertes Anomalieerkennungssystem erkennt unerwartete Änderungen oder Anomalien in den Verkehrsmustern über das Kommunikationsnetz, um infizierte oder potentiell infizierte Knoten zu erkennen. Das Anomalieerkennungssystem beinhaltet verschiedene Datensammelmodule an jedem der Knoten des Netzwerks, deren Aufgabe es ist, den Nachrichtenverkehr in den und aus dem Knoten zu sichten und Metadaten zu erzeugen, die sich auf den Nachrichtenverkehr beziehen. Die Kommunikationsmodule an den Knoten senden die Verkehrsmetadaten zu einer Anomalieanalyse-Engine, die die Metadaten mittels einer Regel-Engine verarbeitet, die die Metadaten anhand eines Satzes von Logikregeln und Verkehrsmuster-Basisliniendaten analysiert, um zu ermitteln, ob aktuelle Verkehrsmuster auf einem oder mehreren Netzwerkknoten anormal sind. Wenn ja, dann kann die Analyse-Engine eine Warnung oder Nachricht für einen Benutzer erzeugen, die den Benutzer über den potentiell infizierten Knoten informiert, kann den Knoten automatisch vom Netzwerk abtrennen oder kann eine andere Aktion durchführen, um die Auswirkungen eines infizierten Knotens zu minimieren.

Description

TECHNISCHER BEREICH
Die vorliegende Anmeldung betrifft allgemein Prozess- oder Industrieanlagen-Kommunikationssysteme und spezieller die Erkennung von Eingriffen in Steuer- und Wartungskommunikationsnetze wie die, die in Prozess- und Industriesteuersystemen verwendet werden, auf der Basis der Erkennung von Nachrichtenverkehrsanomalien in den Anlagenkommunikationsnetzen.
BESCHREIBUNG DER VERWANDTEN TECHNIK
Prozess- oder Industriesteuer- und -wartungssysteme wie dezentrale oder skalierbare Prozesssteuersysteme wie die, die bei der Stromerzeugung, in Chemie-, Erdöl- oder anderen Herstellungsprozessen zum Einsatz kommen, beinhalten typischerweise einen oder mehrere Controller, die kommunikativ miteinander, mit wenigstens einer Host- oder Operator-Workstation über ein Prozesssteuernetz oder mit einem oder mehreren Feldgeräten über analoge, digitale oder kombinierte Analog/Digital-Busse gekoppelt sind. Die Feldgeräte, die beispielsweise Ventile, Ventilstellungsregler, Schalter und Sender (z.B. Temperatur-, Druck- und Strömungsratensensoren) sein können, üben in dem Prozess oder der Anlage Funktionen wie Öffnen oder Schließen von Ventilen, Ein- und Ausschalten von Geräten und Messen von Prozessparametern aus. Die Controller empfangen Signale, die von den Feldgeräten durchgeführte Prozess- oder Anlagenmessungen und/oder andere zu den Feldgeräten gehörende Informationen anzeigen, benutzen diese Informationen zum Implementieren von einer oder mehreren Steuerroutinen und erzeugen dann Steuersignale, die über die Busse oder Kommunikationskanäle des Anlagennetzes zu den Feldgeräten gesendet werden, um den Betrieb des Prozesses oder der Anlage zu steuern. Informationen von den Feldgeräten und dem Controller werden typischerweise über das Kommunikationsnetz einer oder mehreren von der Operator-Workstation abgearbeiteten Anwendungen zur Verfügung gestellt, damit ein Operator oder eine Wartungsperson eine gewünschte Funktion mit Bezug auf den Prozess oder die Anlage ausführen kann, wie zum Beispiel Sichten des aktuellen Zustands der Anlage, Modifizieren des Betriebs der Anlage, Kalibrieren von Geräten, Erkennen von fehlerhaften Geräten usw. Während des Betriebs werden die Prozesscontroller, die sich typischerweise in der Prozessanlagenumgebung befinden, gemäß einem Konfigurationsschema konfiguriert, um periodisch oder regelmäßig Signale zu empfangen, die Prozessmessungen oder Prozessvariablen, die von den Feldgeräten vorgenommen werden bzw. damit assoziiert sind, und/oder andere zu den Feldgeräten gehörende Informationen anzeigen und Controller-Anwendungen anhand dieser Informationen abarbeiten. Die Controller-Anwendungen implementieren beispielsweise unterschiedliche Steuermodule, die Prozesssteuerentscheidungen fällen, Steuersignale auf der Basis der empfangenen Informationen erzeugen und sich mit den Steuermodulen oder -blöcken in den Feldgeräten wie HART^® und FOUNDATION^® Fieldbus Feldgeräten abstimmen können. Ferner senden die Steuermodule in den Prozess-Controllern die Steuersignale über die Kommunikationsleitungen oder über andere Signalpfade zu den Feldgeräten, wiederum gemäß einem Konfigurationsschema, um dadurch den Betrieb des Prozesses zu steuern. Informationen von den Feldgeräten und den Prozess-Controllern werden auch einem oder mehreren anderen Hardware-Geräten innerhalb oder außerhalb der Anlage, wie zum Beispiel Operator-Workstations, Wartungs-Workstations, Servern, PCs, Handgeräten, Daten- oder Event-Ablaufrekordern, Berichtsgeneratoren, zentralisierten Datenbanken usw., über ein oder mehrere gesicherte Prozesssteuer- oder Wartungsnetzwerke zur Verfügung gestellt. Die über die Prozesssteuer- oder Wartungs-Kommunikationsnetzwerke übermittelten Informationen ermöglichen es einem Operator oder einer Wartungsperson, gewünschte Funktionen mit Bezug auf den Prozess durchzuführen und/oder den Betrieb der Anlage oder von Geräten in der Anlage zu sichten. Zum Beispiel erlauben es die Steuerinformationen einem Operator, Einstellungen von Prozesssteuerroutinen zu ändern, den Betrieb der Steuermodule innerhalb der Prozess-Controller oder der Smart-Feldgeräte zu modifizieren, den aktuellen Zustand des Prozesses oder den Status bestimmter Geräte innerhalb der Prozessanlage zu sichten, von Feldgeräten und Prozess-Controllern erzeugte Alarme und/oder Warnungen zu sichten, den Ablauf des Prozesses für Personalausbildungszwecke oder für ein Testen der Prozesssteuersoftware zu simulieren, Probleme oder Hardware-Ausfälle in der Prozessanlage zu diagnostizieren usw. Die Feldgeräte und Controller kommunizieren gewöhnlich mit den anderen Hardware-Geräten über eine oder mehrere gesicherte Prozesssteuer- oder Wartungs-Kommunikationsnetze, die beispielsweise als Ethernet-konfiguriertes LAN implementiert werden können. Das Prozesssteuer- oder Wartungs-Kommunikationsnetz sendet die Prozessparameter, Netzwerkinformationen und sonstigen Prozesssteuerdaten durch verschiedene Netzwerkgeräte und zu verschiedenen Einheiten in dem Prozesssteuersystem. Typische Netzwerkgeräte beinhalten Netzwerkschnittstellenkarten, Netzwerk-Switches, Router, Server, Firewalls, Controller, Operator-Workstations und Datenbanken. Die Netzwerkgeräte unterstützen typischerweise den Fluss von Daten durch das Netzwerk durch Steuern von Routing, Frame-Rate, Zeitabschaltung und anderen Netzwerkparametern davon, ändern die Prozessdaten selbst jedoch nicht. Wenn das Prozesssteuernetz an Größe und Komplexität zunimmt, dann nehmen entsprechend auch Anzahl und Typen von Netzwerkgeräten zu. Infolge des Wachstums von System und Netzwerk werden somit die Sicherheit und das Management innerhalb dieser komplexen Systeme immer schwieriger. Zu Beginn sind diese Netzwerke jedoch im Allgemeinen von anderen externen Netzen isoliert und sind durch ein oder mehrere Firewalls vor externen Attacken geschützt. Im Allgemeinen sind in einem typischen industriellen Steuersystem zum Begrenzen von Eingriffen in das Netzwerk die Workstations/Server des Anlagensteuersystems strategisch zwischen externen Anlagennetzen, die verschiedene mit der Anlage assoziierte Funktionen ausführen, und den integrierten Steuergeräten, die Steuer- und Datenerfassungsfunktionen (z.B. Controller, PLCs, RTUs) innerhalb des Steuersystems ausführen, platziert. Ein wichtiges Sicherheitsziel für die Steuerworkstations/-server besteht darin, zu verhindern, dass Malware in das Steuer- und Wartungssystem eindringt und die integrierten Geräte negativ beeinflusst, sowie zu verhindern, dass Malware die in den Anlagenprozesssteuerdatenbanken gespeicherten Konfigurations- und Historiendaten ändert. Darüber hinaus verhindern diese Workstations/Server einen unbefugten Zugriff auf das Steuersystem, um ein unbefugtes Ändern der Anlagenkonfiguration, einen unbefugten Zugriff auf Anlagendaten usw. zu verhindern. Es können zwar einige Sicherheitsmerkmale wie Firewalls, „Anti-Virus“-Software und „Whitelisting“ zum Erreichen dieser Sicherheitsziele benutzt werden, aber diese Sicherheitsmerkmale reichen typischerweise nicht aus. Zum Beispiel kann Anti-Virus-Software nicht gegen „Zero-Day“-Viren schützen und Whitelisting verhindert nur den Ablauf von unbefugten Anwendungen. Zusätzlich sind einige dieser Merkmale zu intrusiv, um in einem Prozesssteuersystem betrieblich zweckmäßig zu sein, weil diese Sicherheitsmerkmale das Potential haben, Aktivitäten von Anlagenoperators zu behindern. In einem allgemeinen Sinne wird Malware, etwa die im Zentrum einer Zero-Day-Attacke, typischerweise über eine autorisierte Kommunikationsverbindung mit einem externen Netzwerk durch den Betrieb einer Anwendung oder eines Service in das gesicherte Steuersystemnetz eingeführt, die die Berechtigung oder Autorisierung zum Zugreifen auf die Speichergeräte, Netzwerkports oder direkten Datenverbindungen innerhalb des Prozesssteuernetzwerks hat. Alternativ kann Malware auch über Personen vor Ort, die infizierte tragbare Geräte und/oder Medien an ein Steuersystemgerät anschließen, in das gesicherte Steuersystemnetz eingeführt werden. Danach kann die Malware auf andere Geräte (z.B. über Kommunikationen) übergreifen und/oder kann innerhalb eines Geräts in dem Prozesssteuernetz anhand der Sicherheitsberechtigungen der Anwendung oder Dienste, die mit der Malware infiziert werden, ausgeführt werden. Zusätzlich kann die Malware lokal fortbestehen, so dass sie nach dem Rebooten von vernetzten Geräten erneut abgearbeitet werden kann. In einigen Fällen kann die Malware die Berechtigungen eines Host, z.B. ein(e) infizierte(r) Anwendung oder Dienst, anhand der Berechtigungen des Kontos, unter dem die Anwendung oder der Dienst ausgeführt wird, ausweiten, und dabei kann die Malware Aktionen oder Operationen innerhalb des Prozesssteuergeräts oder Netzwerkgeräts durchführen, die höhere Berechtigungen erfordern und somit typischerweise für das Steuersystem noch schädlicher sind. Diese Attacken können ernsthafte und potentiell destruktive oder sogar fatale Auswirkungen innerhalb einer Prozessanlage haben, wenn diese Attacken den laufenden Betrieb des Prozesssteuersystems unterbrechen. Erheblicher Aufwand an Forschungsaktivitäten wurde in Bezug auf das Definieren und Erstellen von Hardware- und Software-Konfigurationenbetrieben, deren Aufgabe es ist, Attacken gegen Prozess- oder Industriesteuer- und -wartungsnetze zu verhüten oder zu begrenzen. Aber selbst stark geschützte Industriesteuersystem-(ICS)-Netze oder überwachende Steuer- und Datenerfassungs-(SCADA)-Netze unterliegen weiterhin Sicherheitsbedrohungen wie Fehlkonfigurationen beim Sicherheitsschutz, Benutzern mit legitimem Zugang, die mit böser Absicht agieren, und öffentlich unbekannter, aber bösartiger Software, die für externe Angreifer agiert. Darüber hinaus gibt es, wenn ein Netz einmal infiziert ist, nur begrenzte Möglicheiten, die Existenz von Viren oder Malware in einem Prozesssteuer- oder Industriesteuergerät oder in Anlagenkommunikationsknoten automatisch zu erkennen. Allgemein ausgedrückt wird, sobald ein Angreifer in einer Anlagenumgebung erfolgreich wird, im Allgemeinen nur ein Operator oder eine Wartungspersonerkennen, dass ein Anlagenkommunikationsknoten oder -gerät infiziert ist. Es ist zwar möglich, an jedem Knoten eines Kommunikationsnetzes Virenscan-Software im Hintergrund laufen zu lassen, aber diese Software nimmt viel Speicherplatz und Verarbeitungsressourcen in Anspruch, muss regelmäßig aktualisiert werden (was erhebliche Netzwerkwartungsressourcen und Zeit erfordert) und kann trotzdem keine Zero-Day-Viren erkennen. In vielen Fällen können Viren oder unautorisierte Software in einem Anlagengerät oder Netzwerkknoten eine Leistungsminderung an dem Gerät oder Netzwerk verursachen, normale Anlagenoperationen soweit unterbrechen, dass Fehler oder Alarme an diesem Knoten oder an anderen Knoten innerhalb des Netzes verursacht werden, oder andere ernsthafte und spürbare Probleme verursachen. In einigen dieser Fälle mag es für einen Operator oder sonstiges Anlagenpersonal relativ leicht sein, die Existenz eines Virus zu erkennen, aber es kann immer noch schwierig sein, die Position des Virus zu erkennen. Zudem kann der Virus oder die Attacke in vielen anderen Fällen für eine erhebliche Zeitdauer unentdeckt arbeiten, weil, wenn er/sie Netzwerkoperationen nur geringfügig beeinträchtigt, eine solche Herabsetzung oder sonstige Auswirkung auf den Anlagenbetrieb möglicherweise vernachlässigbar ist, so dass sie nur sehr schwer zu entdecken ist. Folglich können Viren in vielen Fällen eine erhebliche Zeit lang unerkannt bleiben, und während dieser Zeit können diese Viren Anlageneffizienzen reduzieren, den Diebstahl von Anlagendaten zulassen, ernsthaftere Eingriffe ermöglichen, Netzwerkgeräte für einen ernsthaften Eingriff oder Schaden anfällig machen usw.
ZUSAMMENFASSUNG
Ein Steuersystem wie ein Industrie- oder Prozessanlagensteuer- oder -wartungssystem implementiert ein System zum Erkennen von Kommunikationsnetzbedrohungen, das die Erkennung von über das Netzwerk gesendeten Anomalien von Kommunikationen benutzt, um potentiell infizierte Netzwerkknoten zu erkennen. Allgemein ausgedrückt erkennt das Anomalieerkennungssystem unerwartete Änderungen oder Anomalien in Verkehrsmustern über das Kommunikationsnetz, um infizierte oder potentiell infizierte Knoten zu erkennen. Eine solche Anomalieerkennung lässt sich zwar in standardmäßigen, offenen Kommunikationsnetzen aufgrund der sich ständig ändernden Konfiguration der Knoten auf diesen Netzen nur schwer durchführen, aber Anomalieerkennung kann in Prozessanlagen- oder Industriesteuernetzen aufgrund der relativ statischen Konfiguration der Netzwerkknoten sowie aufgrund der a priori Natur von in der Anlage oder dem Netzwerk benutzten Prozess- oder Industriesteuer- oder -wartungssystemkonfigurationen effektiver eingesetzt werden.
Das hierin beschriebene Anomalieerkennungssystem verteilt im Allgemeinen Datensammlungsverarbeitungslasten über die Netzwerkknoten eines Kommunikationssystems, um dadurch die Anomalieerkennungslasten an jedem Knoten zu reduzieren. Zudem reduziert das hierin beschriebene Anomalieerkennungssystem die Anomalieanalyselast auf der Basis der Kenntnis der Netzwerkkonfiguration und indem es Metadaten über Netzwerkverkehr über das Netzwerk zur Analyse meldet, anstatt ein separates Überwachungsnetz zu erfordern. Das hierin beschriebene Anomalieerkennungssystem reduziert auch die Falsch-positiv-Rate der Anomalieerkennungsanalyse durch Empfangen von Benachrichtigungen über und Berücksichtigen von autorisierten Netzwerkkonfigurationsänderungen oder automatisierten Umkonfigurationsaktivitäten (z.B. aufgrund von Hochverfügbarkeitsmechanismen). Darüber hinaus kann das hierin beschriebene Anomalieerkennungssystem dieselben Daten zum Durchführen von mehreren Typen von Anomalieanalyse (z.B. Sicherheit oder Wartung) nutzen und es ermöglicht die Durchführung von Hierarchieanalyse/-meldungen an jedem Netzwerkknoten in dem Industriesteuersystem durch eine beliebige Kombination von vordefinierten Regeln und maschinellem Lernen.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1 ist ein beispielhaftes Kommunikationsfließschema eines Prozesssteuernetzes mit einem darin installierten Anomalieerkennungssystem.
2 ist ein beispielhaftes Blockdiagramm eines/r Prozesses oder Industrieanlage mit mehreren miteinander verbundenen Kommunikationsnetzen, in denen ein oder mehrere Netzwerkanomalieerkennungssysteme wie das von 1 implementiert werden können.
3 ist ein beispielhaftes Schema von einem der Anlagennetze von 2 in Form eines dezentralen Prozesssteuersystems und Prozessautomatisierungsnetzes mit verschiedenen Knoten einschließlich Operator- und Wartungs-Workstations, Servern und Controller-Knoten, in denen ein Anomalieerkennungssystem von 1 potentiell infizierte oder kompromittierte Knoten erkennt.
4 zeigt ein Fließschema, das Kommunikationsfluss zwischen verschiedenen Komponenten eines hierin beschriebenen beispielhaften Anomalieerkennungssystems und daran durchgeführte Verarbeitung illustriert.
BESCHREIBUNG
Allgemein ausgedrückt implementiert ein hierin beschriebenes Netzwerksicherheitssystem Bedrohungserkennung durch Erkennen von Anomalien in Netzwerkverkehrsmustern (z.B. Verkehrs- oder Nachrichteninhalt, Häufigkeit, Zeit, Länge usw.) an Knoten oder über Knoten eines Industriesystems oder eines Prozesssteuernetzes, und arbeitet effektiv, weil die a priori Natur der Konfiguration des Industriesystems oder Prozesssteuernetzes das Vergleichen von gemessenen Verkehrsmustern mit erwarteten oder bekannten Mustern ermöglicht. Das heißt, die Konfiguration von Netzwerkkommunikationen in Prozesssteuer-, Industriesystem- oder Anlagenautomatisierungsnetzen ist vor Implementation oder Betrieb des Kommunikationsnetzes im Allgemeinen recht gut bekannt, so dass sich Netzwerkverkehrsmuster beim Gebrauch oder Betrieb dieser Netze tendenziell nicht erheblich ändern. Stattdessen neigen Netzwerkkommunikationsverkehrsmuster dazu, während des Betriebs des Kommunikationsnetzes recht statisch (in einem statistischen Sinne) zu sein, und somit können Änderungen der Netzwerkmuster, insbesondere in einem statistischen Sinne, ein Hinweis auf einen Eingriff in das Netzwerk sein, der nicht Teil der ursprünglichen oder gewünschten Konfiguration ist.
Ein typisches Problem bei Anomalieerkennungssystemen auf Netzwerkbasis ist, dass die Analyse-Engine, die die Engine ist, die Nachrichten oder Verkehr parst, um Änderungen an Netzwerkmustern zu erkennen, Zugang zu den Nachrichten haben muss, die über jeden Netzwerkknoten empfangen und gesendet werden. Diese Anforderung bedeutet, dass eine separate Analyse-Engine an jedem Netzwerkknoten ausgeführt werden muss oder dass Nachrichtenverkehr an jedem Knoten über das Netzwerk zu einer zentralisierten Anomalieerkennungs-Engine zur Analyse gesendet werden muss. Im ersten Fall ist die Analyse-Engine an jedem Knoten auf das Parsen oder Analysieren von Nachrichtenverkehr an einem einzigen Knoten begrenzt, was die Analyse-Engine weniger effektiv macht als eine, die Nachrichtenverkehr über das gesamte Netzwerk analysieren kann. Zudem kann die Analyse-Engine in diesem Fall viel Verarbeitungsleistung von einem Knoten in Anspruch nehmen, was den Knoten beim Durchführen anderer Aufgaben beschränkt oder verlangsamt. Im zweiten Fall wird das Netzwerk möglicherweise mit Verkehr überlastet, da jeder Knoten alle Nachrichten zu der zentralisierten Analyse-Engine senden muss, was erfordert, dass jede an jedem Knoten auf dem Netzwerk empfangene Nachricht redundant zu dem zentralisierten Analyse-Engine-Knoten (über den Netzwerkbus oder Kommunikationskanal) gesendet wird.
Da sämtlicher Netzwerkverkehr für die Analyse-Engine sichtbar sein muss, damit sie Anomalien effektiv erkennen kann (was ein ernsthaftes Problem in segmentierten Netzwerken ist), lässt sich die zentralisierte Sammlung nicht gut auf Hunderte von Netzwerkendpunkten skalieren. Ferner neigen Nahe-Echtzeit-Endpunkte in Prozessanlagennetzen dazu, begrenzte Rechenressourcen für Sicherheitsaufgaben zu haben, was die Fähigkeit dieser Endpunktgeräte begrenzt, leistungsstarke Verkehrsanomalieerkennungssysteme zu betreiben oder abzuarbeiten. Außerdem können Netzwerkverbindungen variierende Kapazitäts- und Leistungscharakteristiken haben, und Steuersystemkonfigurationsänderungen auf halbem Weg können eine große Zahl von Falsch-positiv-Meldungen erzeugen.
1 zeigt ein beispielhaftes Netzwerkanomalieerkennungssystem 10, das diese Probleme reduziert oder eliminiert. Allgemein ausgedrückt ist das Anomalieerkennungssystem 10 ein dezentrales System, da es Datensammelmodule beinhaltet, die auf jedem Netzwerkknoten angeordnet sind, um Informationen über Nachrichtenverkehr zu einer zentralisierteren Analyse-Engine zu senden. Während die Datensammelmodule die Aufgabe haben, Nachrichtenverkehr zu sammeln und zu analysieren, der in die Netzwerkknoten eintritt und sie verlässt, senden die Datensammelmodule nicht die Nachrichten selbst zur Analyse-Engine, sondern erzeugen stattdessen Metadaten, die diesen Nachrichtenverkehr beschreiben, und senden die Metadaten zur Analyse-Engine. Die zentralisierte Analyse-Engine empfängt die an jedem Netzwerkknoten gesammelten Verkehrsmetadaten und analysiert diese Metadaten zum Erkennen von Nachrichtenverkehrsanomalien, die einen Eingriff in das Netzwerk anzeigen können.
Spezieller, wie in 1 angedeutet, arbeitet das Anomalieerkennungssystem 10 in einem Netzwerk 20 (das ein Prozessanlagennetz, ein Prozesssteuer- und/oder -wartungsnetz, ein industrielles Steuersystemnetz, ein Automatisierungsnetz oder ein beliebiger anderer Netzwerktyp sein kann) mit verschiedenen dezentralen Netzwerkknoten 22A–22N, die über eine Kommunikationsverbindung 24 miteinander verbunden sind. Die Kommunikationsverbindung 24 kann eine verdrahtete oder drahtlose Kommunikationsverbindung (oder eine Kombination davon) sein und kann jeden beliebigen gewünschten Typ von Kommunikationsprotokoll(en) oder Protokollen zum Durchführen von Kommunikationen benutzen, die typischerweise paketgestützte Kommunikationen sind. Das Anomalieerkennungssystem 10 beinhaltet verschiedene Module oder Komponenten, die an den verschiedenen Knoten des Netzwerks 20 angeordnet sind, einschließlich Nachrichtensammelmodulen 30 und 32 und einer Anomalieanalyse-Engine 34, die in wenigstens einem Knoten angeordnet ist, wie in 1 als Knoten 22K illustriert. Wie insbesondere in 1 illustriert ist, kann jeder Netzwerkknoten 22 ein oder mehrere Nachrichtenanalyse-Sammelmodule 30 und 32 haben, einschließlich eines Eingangsnachrichten-Sammelmoduls 30 und eines darin angeordneten Ausgangsnachrichten-Sammelmoduls 32. Allgemein ausgedrückt empfangen (sichten) und analysieren die Nachrichtensammelmodule 30 und 32 an jedem Netzwerkknoten 22 jeweils jede eingehende oder abgehende Nachricht und sammeln oder erzeugen Metadaten in Bezug auf einige oder alle dieser Nachrichten. Die Metadaten können, aber ohne darauf begrenzt zu sein, einen Zeitstempel einer Nachricht, eine Nachrichtenlänge, eine Länge von einem oder mehreren Datenfeldern in der Nachricht, den Adressaten oder Absender (z.B. Sender und/oder Empfänger), Paritätsinformationen, den Nachrichtentyp (zum Beispiel das Format) usw. enthalten. Die Module 30 und 32 können natürlich auch beliebige andere Metadaten über jede Nachricht erzeugen oder sammeln, die an einem Netzwerkknoten empfangen oder von diesem gesendet wird, und die Sammelmodule 30 und 32 können die Metadaten in einem vorübergehenden oder anderen Speicher 31 am Netzwerkknoten speichern.
Die Nachrichtensammelmodule 30 und 32 eines beliebigen Netzwerkknotens 22 können periodisch, zu nicht-periodischen Zeiten oder in Echtzeit die gesammelten Metadaten für diesen Knoten über die Netzwerkverbindung 24 zu der Anomalieerkennungsanalyse-Engine 34 über ein Kommunikations-Frontend 33 des Knotens kommunizieren. Allgemein ausgedrückt beinhaltet wie in 1 illustriert die Anomalieerkennungsanalyse-Engine 34 einen Anomalieerkennungs-Controller 40, eine Expert- oder Logik-Engine 42, eine(n) Regeldatenbank oder -speicher 44, eine Nachrichtenverkehrsmuster-Speicherdatenbank 46, eine Alarm- oder Benachrichtigungs-Engine, auch Alert-Generator 48 genannt, und eine Metadatenspeichereinheit 50. Insbesondere empfängt der Erkennungs-Controller 40 die von den verschiedenen Nachrichtensammelmodulen 30 und 32 der Netzwerkknoten 22 kommenden Metadaten beispielsweise über die Netzwerkverbindung 24. Der Erkennungs-Controller 40 speichert diese Metadaten (zusammen mit einer Anzeige des Netzwerkknotens, auf den sich die Metadaten beziehen) in der Metadatenspeichereinheit 50. Es wird zwar bevorzugt, die Netzwerkverbindung 24 (z.B. den primären Netzwerkbus oder Kommunikationskanal des Netzwerks 20) zum Bewirken von Kommunikationen der gesammelten Metadaten von den Netzwerkknoten 22 zur Erkennungs-Engine 34 zu benutzen, aber die Anomalieerkennungs-Engine 34 kann auch über eine separate Kommunikationsverbindung mit den Netzwerkknoten 22 verbunden sein, die beispielsweise für Kommunikationen in Bezug auf die gesammelten Metadaten zu der Erkennungs-Engine 34 dediziert ist.
So benutzt das Anomalieerkennungssystem 10, im Gegensatz zu Systemen des Standes der Technik, die die Nachrichten selbst zu einer Analyse-Engine zur Analyse senden, die Netzwerkverbindung 24 zum Kommunizieren von Nachrichtenmetadaten von den Knoten 22 zur Erkennungs-Engine 34, anstatt der gesamten Nachrichten. Da die Metadaten typischerweise eine relativ geringe Größe im Vergleich zu den Nachrichten selbst haben, benötigt das Anomalieerkennungssystem 10 im Allgemeinen nur sehr wenig Netzwerkbandbreite oder belegt nur minimale Netzwerkverbindungsbandbreite. Folglich benötigen, da der zwischen den Knoten 22 über die Netzwerkverbindung 24 gesendete Nachrichtenverkehr wie durch die Linie 60 in 1 angedeutet Zugang zur vollen Bandbreite der Kommunikationsverbindung 24 hat, die über die Kommunikations- oder Netzwerkverbindung 24 erfolgenden Metadatenkommunikationen wie durch die Linie 62 in 1 angedeutet im Allgemeinen nur eine geringe Bandbreitenbelegung der Verbindung 24.
In jedem Fall aktiviert der Controller 40 der Erkennungs-Engine 34 die Expert- oder Logik-Engine 42 zum Analysieren der gesammelten Metadaten periodisch, kontinuierlich, zu verschiedenen vorkonfigurierten Zeiten, als Reaktion auf eine Benutzeranforderung oder einen Benutzerbefehl, als Reaktion auf ein erkanntes Ereignis usw. Bei solchen Analysezyklen kann die Logik-Engine 42 die gesammelten Metadaten von den Knoten 22 (wie im Metadaten-Speicher 50 gespeichert) durch Implementieren eines Satzes von in der Regeldatenbank 44 gespeicherten Logikregeln analysieren, um Anomalien in dem in jedem Netzwerkknoten 22 eingehenden und davon abgehenden Nachrichtenverkehr zu erkennen. Insbesondere kann die Analyse- oder Logik-Engine 42 eine oder mehrere (oder alle) in der Regeldatenbank 44 gespeicherte Logikregel(n) auf der Basis der gespeicherten Metadaten und einen oder mehrere in der Verkehrsmusterspeicherdatenbank 46 gespeicherte Verkehrsmusterparameter implementieren.
Im allgemeinen Sinne reflektieren die in der Verkehrsmusterdatenbank 46 gespeicherten Verkehrsmusterparameter das erwartete oder normale Verhalten des Nachrichtenverkehrs in die und aus den Knoten 22 des Netzwerks 20. Spezieller können die in der Verkehrsmusterdatenbank 46 gespeicherten Verkehrsmusterdaten durch Sammeln und Analysieren von Nachrichten- oder Verkehrsmetadaten von den Knoten 22 des Netzwerks 20 während einer bestimmten Zeitperiode erzeugt werden, z.B. ab dem Zeitpunkt, an dem das Netzwerk 20 betriebsbereit ist, aber unmittelbar, nachdem es eingerichtetwurde, wenn es relativ sicher ist, dass das Netzwerk nicht kompromittiert ist. Während dieser Zeit reflektieren die erzeugten oder gesammelten Metadaten den „normalen“ oder „erwarteten“ Betrieb des Netzwerks in einem statistischen Sinne. Es können verschiedene Verkehrsmusterparameter oder -statistiken von den während dieser Zeit gesammelten Nachrichtenmetadaten gesammelt oder erzeugt werden, und diese Daten können in der Verkehrsmusterdatenbank 46 als Basis- oder Referenzsatz von Daten gespeichert werden, die den erwarteten oder normalen Betrieb des Netzwerks reflektieren. Die gesammelten oder erzeugten und in der Datenbank 46 gespeicherten Verkehrsmusterparameter können beispielsweise statistische Messwerte für den Verkehr an einem beliebigen Knoten oder an beliebigen Knotengruppen in jeder Granularität beinhalten. Das heißt, die gespeicherten Verkehrsmusterparameter können beliebige statistische Messwerte für Daten (z.B. Mittel, Standardabweichung, Durchschnitt, Median usw.) anzeigen, die an einem beliebigen Typ von Daten, Zeitrahmen, Knoten oder Gruppenknoten, eingehend oder abgehend, Senden/Empfangen, Länge usw. gruppiert oder durchgeführt werden, und diese können in jeder gewünschten Hierarchie gespeichert werden, wie zum Beispiel in einer Hierarchie, die die Konfigurationshierarchie des Netzwerks reflektiert. Die Verkehrsmusterparameter können auch Bereiche oder Grenzen für beliebige Typen oder Gruppen von Kommunikationen in eine(n) oder aus einem/r Knoten oder Knotengruppe beinhalten, die, wenn sie überschritten werden, eine Anomalie- oder potentielle Anomalieerkennung reflektieren oder auslösen. Diese Bereiche oder Grenzen können absolute Grenzen, zum Beispiel in Form einer festen Zahl, oder relative Grenzen sein, auf der Basis von oder in Bezug zu anderen statistischen Messwerten, zum Beispiel das Dreifache eines Durchschnittswerts, in die erste oder zweite Standardabweichung fallend, um einen vorbestimmten Betrag über oder unter einem Median- oder Mittelwert liegend usw.
Man wird verstehen, dass die Regeln innerhalb der Regeldatenbank 44 erzeugt und benutzt werden, um die Art und Weise zu definieren, in der die aktuellen oder gesammelten Metadaten zum Erkennen von Anomalien in dem Netzwerk analysiert werden sollen. Spezieller geben die Regeln in der Regeldatenbank 44 die Art und Weise vor, in der die gesammelten Metadaten analysiert werden sollen, zum Beispiel durch Vergleichen der gesammelten Metadaten oder Statistiken über die gesammelten Metadaten mit in der Datenbank 46 gespeicherten Verkehrsmusterdaten, und/oder durch Benutzen von Verkehrsmustergrenzen oder -bereichen wie in der Verkehrsmusterdatenbank 46 gespeichert. In einem allgemeinen Sinne implementiert die Regel-Engine 42 die in der Regeldatenbank 44 gespeicherten Regeln zum Vergleichen der gesammelten Metadaten (z.B. Statistiken über die gesammelten Metadaten) mit den Verkehrsmusterparametern wie in der Verkehrsmusterdatenbank 46 als Basisliniendaten gespeichert.
Ebenso beinhaltet die Erkennungs-Engine 34, wie in 1 angedeutet, einen Alert-Generator 48, der ein oder mehrere Warnungen, Alarme oder Nachrichten auf der Basis der Ergebnisse der von der Regel- oder Logik-Engine 42 durchgeführten Analysen erzeugen kann. Die vom Alert-Generator 48 erzeugten Warnungen, Alarme oder Nachrichten können zu beliebigen gewünschten Personen wie zum Beispiel Operators, Sicherheitspersonen, IT-Personen usw. entweder über die Netzwerkverbindung 24 (wie in 1 gezeigt) oder über eine beliebige Kommunikationsverbindung gesendet werden, die für diesen Zweck bereitgestellt oder verwendet wird. Zum Beispiel können Warnungen, Alarme oder Nachrichten zur E-Mail-Adresse einer designierten Person, zu einem Operator oder zu einer Sicherheitsschnittstelle gesendet werden, die auch andere Daten über die Anlage illustriert, sie können als Telefonanruf oder als Textnachricht gesendet werden, die über private oder öffentliche Netze zu einer designierten Person oder Personengruppe gesendet wird, an einem beliebigen gewünschten Gerät wie zum Beispiel einem Mobilgerät usw. Ebenso können diese Warnungen, Alarme oder Nachrichten ausgelöste Alarme oder Benachrichtigungen auf Handgeräten wie Telefonen, Armbanduhren, tragbaren Geräten, Laptops, Tablet-Computern usw. einer beliebigen designierten Person sein, die zum Reagieren auf und Untersuchen von potentielle(n) Eingriffe(n) in das Netzwerk 20 verantwortlich ist. In einigen Fällen kann der Alarm- oder Alert-Generator 48 die Aufgabe haben, den Zugriff auf einen infizierten oder potentiell infizierten Knoten zu begrenzen, er kann einen Knoten abschalten oder kann, in sehr kritischen Situationen, das Kommunikationsnetz 20 selbst abschalten oder isolieren, um durch den Eingriff bedingte Schäden an der Anlage oder einem Subsystem in der Anlage zu begrenzen. Der Alert-Generator 48 kann natürlich auch Software oder Logik beinhalten, die mit anderen Geräten in dem Netzwerk 20 übermittelt werden kann, um solche automatischen Vorgänge zu bewirken. In einigen Fällen kann der Alert-Generator 20 nach einer Autorisierung von einem Benutzer fragen, bevor er solche automatischen Aktionen in dem Anlagennetz 20 durchführt, aber in anderen Fällen kann er die Aktionen in dem Netzwerk 20 auch vor oder gleichzeitig mit einer Benachrichtigung eines Benutzers über einen Eingriff oder potentiellen Eingriff durchführen. Ferner kann der Alert-Generator 48 beim Durchführen automatischer Aktionen mit dem infizierten oder potentiell infizierten Knoten kommunizieren, um Kommunikationen von diesem (in den und/oder aus dem) Knoten zu begrenzen, beispielsweise zum Begrenzen oder Stoppen bestimmter Typen von Nachrichten von diesem Knoten, zum Stoppen oder Begrenzen des Betriebs bestimmter Anwendungen an diesem Knoten (die möglicherweise den anormalen Nachrichtenverkehr erzeugen), zum Stoppen oder Begrenzen von Kommunikationen über bestimmte Ports eines Geräts usw. Stattdessen oder zusätzlich kann der Alert-Generator 48 mit anderen Knoten wie zum Beispiel mit mit anderen Netzen verbundenen Gateway-Knoten kommunizieren, um Nachrichten zwischen dem Netzwerk 20 und anderen Netzwerken zu begrenzen oder zu stoppen. Diese Aktion kann es zulassen, dass die kritischen Operationen (wie Steuervorgänge) auf dem Netzwerk 20 ablaufen, während das Netzwerk 20 von externen Quellen isoliert ist, um, zumindest vorübergehend, zu verhindern, dass der anormale Nachrichtenverkehr das Netzwerk 20 verlässt oder in dieses eintritt, um Datendiebstahl zu begrenzen, um zu verhindern, dass der Virus in dem Netzwerk 20 andere Netzwerke infiziert, damit weitere Eingriffe in das System 20 über den infizierten Knoten verhindert werden können usw. Zum Beispiel kann der Alert-Generator 48 sämtliche Kommunikationen zwischen externen Geschäftssystemen und dem betroffenen industriellen Steuersystemnetz abtrennen, bis das Sicherheitspersonal vor Ort die Anomalie bewerten kann. Der Alert-Generator 48 kann natürlich auch in andere Systeme wie Sicherheitssysteme eingebunden werden (kommunikativ verbunden werden mit), um diese Funktionen auszuführen.
Die Regeldatenbank 44 kann jeden gewünschten Satz von Regeln speichern, die von einer oder mehreren Sicherheitspersonen, Konfigurationspersonen, Benutzern, Operators usw. erzeugt oder generiert werden, die Analysen definieren, die an dem Nachrichtenverkehr oder an Nachrichtenmetadaten durchgeführt werden sollen, der/die von den Kommunikationsnetzknoten 22 empfangen wird/werden, um zu ermitteln, ob es eine Anomalie in dem Nachrichtenverkehr oder den Verkehrsmustern gibt, und somit, ob eine Warnung oder ein Alarm erzeugt werden soll. Die Regel-Engine 42 kann diese Regeln auch ausführen, um aktuelle Nachrichten oder Verkehrsmetadaten mit einem Satz von Standard- oder Basisliniendaten zu vergleichen, die von den Sammelmodulen 30 und 32 an den verschiedenen Knoten 22 des Netzwerks 20 während einer Zeit gesammelt werden, in der das System anfänglich eingerichtet oder konfiguriert wird, und wenn es somit bekannt oder wahrscheinlich ist, dass kein Eingriff oder Malware in dem Netzwerk 20 vorliegt. Diese gespeicherten Nachrichten oder Verkehrsmusterdaten werden hierin als Basisliniensatz von Metadaten bezeichnet, die einen „normalen“ Betrieb des Netzwerks oder der Netzwerkknoten definieren. Die von der Regel-Engine 42 angewandten Regeln können somit zum Vergleichen der von einem Knoten oder einer Knotengruppe gesammelten Metadaten mit den Standard- oder Basislinienmetadaten für den Knoten oder die Knotengruppe dienen, um zu ermitteln, ob es signifikante Unterschiede dazwischen gibt, gemäß Definition durch andere Verkehrsmusterparameter, wie Grenzen oder Differenzvariablen, die in der Verkehrsmusterdatenbank 46 gespeichert sind. Ein signifikanter oder statistisch relevanter Unterschied, ermittelt anhand der Logikregeln in der Regeldatenbank 44, kann einen Eingriff in das Netzwerk 20 oder an seinem Knoten 22 anzeigen. Wenn ein solcher Unterschied erkannt wird, dann kann der Controller 40 bewirken, dass der Alert-Generator 48 eine Warnung oder einen Alarm erzeugt. Der Typ von Warnung oder Alarm, der/die Empfänger solcher Alarme und andere Parameter der Warnung oder Alarme (z.B. Priorität usw.) können auf der Basis des Typs des erkannten Unterschieds zwischen dem aktuellen Nachrichtenverkehr und dem Basisliniennachrichtenverkehr, der Ernsthaftigkeit des Unterschieds usw. konfiguriert werden.
Man wird verstehen, dass beliebige gewünschte Typen von Metadaten für die Nachrichten oder den Verkehr an den Knoten 22 erzeugt oder erhalten werden können und dass die Regeln in der Regeldatenbank 44 zum Analysieren der Metadaten in der Analyse-Engine 34 in einer beliebigen gewünschten Weise unter Verwendung dieser Metadaten oder Statistiken über diese Metadaten erzeugt werden können. Zum Beispiel können die Metadaten allgemeine Informationen oder Statistiken enthalten über: (1) Nachrichten wie Nachrichtenzahlen und Nachrichtenzahlenstatistiken, z.B. Minima, Maxima, Durchschnitte usw.; (2) Verbindungsinformationen und -statistiken, z.B. Quellen (wie konfigurierte gegenüber unkonfigurierten Knoten, Source-Ports usw.), Adressen (wie Source- und Zieladressen und -ports), Umfang (wie Unicast, Multicast, Broadcast), Nutzlasttyp (wie TCP, UDP, andere) und Zeitangaben (wie Tageszeit, relative Zeit, Versuchsrate usw.); (3) Kommunikationsinformationen, z.B. Nachrichtenzeiten (wie Raten, Tageszeiten, Sequenzfehler usw.), Sicherheitsfehler (wie versagte Integrität, Authentifizierung oder Entschlüsselung), Nachrichteninhalt (wie Größe, Formatfehler usw.); und (4) spuriöse Informationen, z.B. Ratenbegrenzungsinfo (wie Zustand, Methode, Begrenzungsrate usw.), und Verbindungsversuche (wie: außer Sequenz, fehlgeformt, Sweeps usw.). Natürlich können auch andere Typen von Nachrichtenmetadaten zusätzlich oder stattdessen erhalten und benutzt werden, und man wird verstehen, dass die hier gegebene Liste nicht umfassend ist.
Ferner können Nachrichtenmetadaten auf der Basis von anderen Faktoren oder Parametern innerhalb des Netzwerks oder der Knoten gesammelt und gespeichert werden, wie zum Beispiel die Rollen von Sende- oder Empfangsknoten (z.B. ob diese Knoten Workstations, Server, Gateways, Controller, E/A-Server, Fernterminaleinheiten (RTUs) usw. sind). Man wird somit verstehen, dass Nachrichten- und Verkehrsmetadaten auf oder für mehrere unterschiedliche hierarchische Ebenen des Netzwerks erzeugt werden können, wie z.B. auf Geräte- oder Knotenbasis, auf Geräte- oder Knotenrollenbasis, auf Nachrichtenbasis usw., oder relativ zu einer beliebigen anderen hierarchischen Ebene des Netzwerks. Darüber hinaus können die Konfigurationsinformationen des Steuer- oder Kommunikationsnetzwerks 20 zum anfänglichen Erzeugen oder Modifizieren von Regeln zum Analysieren von Verkehrsmetadaten oder zum Organisieren der Metadatenanalyse benutzt werden. Allgemein ausgedrückt beinhalten die Konfigurationsinformationen für das Netzwerk Informationen über die Anzahl von Anwendungen, Modulen, Steuerroutinen usw. an jedem der Knoten (Geräte), sowie die Art und Weise, in der diese verschiedenen Logikelemente, Software-Elemente und Hardware-Elemente miteinander kommunizieren, einschließlich Kommunikationspaare (Sender/Empfänger-Paare), Kommunikationszeiten, Häufigkeiten, Nachrichtentypen, Steuersystemrolle oder Gerätetyp usw. Diese Konfigurationsinformationen können zum Erzeugen oder Modifizieren der Regeln benutzt werden, die zum Analysieren der Verkehrsmetadaten von beliebigen der Knoten benutzt werden. Das heißt, die Konfigurationstypen, einschließlich der Konfigurationshierarchieinformationen (z.B. welche Geräte und Module sich auf welche anderen Module und Geräte in dem Netzwerk beziehen), können zum Erzeugen, Modifizieren oder Ausfüllen von Parametern von Regeln zum Analysieren von Nachrichtenmetadaten verwendet werden. Zum Beispiel können die Konfigurationsinformationen beispielsweise zum Auswählen eines Teilsatzes (d.h. eines Profils) der generalisierten Regeln zum Analysieren von Verkehrsmetadaten benutzt werden. Die Konfigurationsinformationen können auch zum Einfügen spezifischer Werte in einen oder mehrere generalisierte Regelparameter benutzt werden (z.B. dort, wo eine Regel einen Platzhalter für <Subscribers> hat, könnten die Konfigurationsinformationen zum Ausfüllen der Adress- und Portinformationen für die in der Konfiguration aufgeführten spezifischen Teilnehmer benutzt werden). Auf diese Weise können die effektiven Logikregeln von einem größeren Satz von allgemeinen Regeln auf einen Teilsatz von spezifischen Regeln auf der Basis der Steuersystemkonfiguration eines Geräts oder Knotens maßgeschneidert werden.
Darüber hinaus beinhaltet, wie 1 illustriert, das Anomalieerkennungssystem 10 ein Netzwerkkonfigurationsänderungsmodul 70, das beispielsweise in einer Netzwerkkonfigurationsdatenbank oder einem Server-Gerät 72 gespeichert sein kann. Allgemein ausgedrückt hat das Konfigurationsänderungsmodul 70 die Aufgabe, Änderungen der Netzwerkkonfiguration für das Kommunikationsnetzwerk 20 zu erkennen, und es sendet diese Änderungen und/oder Benachrichtigungen über diese Änderungen dann beispielsweise über die Netzwerkverbindung 24 zur Erkennungs-Engine 34. Der hierin verwendete Begriff Konfigurationsänderung kann beispielsweise eine beliebige Änderung beinhalten, die am Betrieb eines Geräts oder Gerätesatzes an dem Netzwerk vorgenommen wird, einschließlich des Hinzufügens neuer Geräte, Anwendungen, Module usw.; des Herausnehmens von beliebigen Geräten, Anwendungen, Modulen usw.; und der Änderung an Geräten, Anwendungen, Modulen usw., Parametern, Einstellungen oder anderen Konfigurationen (einschließlich des Änderns von Hardware-, Software- oder Firmware-Einstellungen), einschließlich der Änderung von Kommunikations- und Prozesssteuereinstellungen wie zum Beispiel der Änderung einer Rezeptur, die beispielsweise in einem Batch-Prozess verwendet wird, usw. In diesem Fall erkennt das Netzwerkkonfigurationsänderungsmodul 70, immer wenn ein Konfigurationstechniker oder ein anderer Benutzer die Netzwerkkonfiguration ändert, zum Beispiel durch Hinzufügen neuer Anwendungen oder Module zu dem Netzwerk, Ändern der Art und Weise, in der Anwendungen oder Module in dem Netzwerk miteinander kommunizieren usw., eine solche Änderung und sendet eine Benachrichtigung zur Erkennungs-Engine 34, die den Controller 40 über die
Änderung der Netzwerkkonfiguration informiert. Das Konfigurationsmodul 70 kann sich natürlich, obwohl es als in der Konfigurationsdatenbank 72 befindlich illustriert ist, in jedem Gerät oder Computer (wie zum Beispiel einem Operator-Schnittstellengerät oder einem Server) befinden, der Zugang zu einer Konfigurationsanwendung (die die Konfiguration des Netzwerks 20 ändert oder einen Benutzer zum Ändern der Konfiguration befähigt) hat oder diese implementiert oder auf andere Weise über Konfigurationsänderungen benachrichtigt wird, und kann auf eine beliebige gewünschte Weise arbeiten, um Netzwerkkonfigurationsänderungen zu erkennen.
In jedem Fall kann das Änderungserkennungsmodul 70, wann immer eine Änderung an einer Konfiguration des Netzwerks 20 vorgenommen wird (die z.B. das Hinzufügen, Löschen oder Ändern von Kommunikationsaspekten von Software, Funktionsblöcken, Modulen usw. in beliebigen der Geräte auf dem Netzwerk 20 oder an das Netzwerk 20 gebunden bewirkt), eine Benachrichtigung zur Analyse-Engine 34 senden, um die Analyse-Engine 34 darüber zu informieren, dass Änderungen oder potentielle Änderungen an Netzwerkverkehrsmustern oder Spezifika zu erwarten sind. Diese Benachrichtigung kann die Analyse-Engine 34 befähigen, Falschmeldungen (z.B. Erkennung eines Eingriffs) zu vermeiden, wenn die Änderung der Verkehrsmuster auf Änderungen in der Netzwerkkonfiguration anstatt auf einen tatsächlichen Eingriff zurückzuführen ist.
Außerdem kann der Controller 40 nach dem Erkennen einer Netzwerkkonfigurationsänderung eine Prozedur abarbeiten oder implementieren, die Metadaten von den Netzwerkknoten 22 (nach dem Ändern der Konfiguration) sammelt und diese neu gesammelten Metadaten zum Erzeugen eines neuen Satzes von Basislinien-Metadaten oder Basislinien-Metadatenstatistiken benutzt, die in der Verkehrsmusterdatenbank 46 gespeichert werden sollen. Der neue Satz von Basislinien-Metadaten kann dann zum Erkennen zukünftiger Anomalien in den Verkehrsmustern auf der Basis des konfigurierten Zustands des Netzwerks benutzt werden. Darüber hinaus kann der Controller 40 in einigen Fällen auch, oder stattdessen, die in der Regeldatenbank 44 gespeicherten Regeln ändern und/oder kann Grenzen oder andere in der Verkehrsmusterdatenbank 46 gespeicherte Parameter auf der Basis der neuen Konfiguration des Netzwerks ändern, um das Anomalieerkennungssystem 10 zu befähigen, im Hinblick auf die neue oder geänderte Netzwerkkonfiguration besser zu arbeiten.
So kann, wie man verstehen wird, eine Änderung der Netzwerkkonfiguration die Netzwerkverkehrsmuster beispielsweise durch Erhöhen oder Verringern von Netzwerkverkehr ändern, spezifische Typen von Netzwerkkommunikationen ändern (z.B. durch Ändern der Eigenschaften oder Mengen bestimmter Typen von Kommunikationen zwischen verschiedenen Geräten auf dem Netzwerk 22 oder zwischen Anwendungen, die innerhalb der verschiedenen Geräte auf den Knoten 22 des Netzwerks 20 laufen). In jedem Fall kann eine Änderung der Netzwerkkonfiguration zur Folge haben, dass die Basislinien-Metadaten und Metadaten-Statistiken, die für die Basislinien-Netzwerkkonfiguration entwickelt und gespeichert wurden, inkorrekt sind. Unter diesen Umständen kann der Controller 40 der Erkennungs-Engine 34 damit beginnen, neue Netzwerkverkehrsmetadaten unter der neuen Konfiguration zu sammeln, statistische oder andere Daten über Netzwerkverkehr auf der Basis der Metadaten ermitteln und diese Daten in der Basisliniendatenbank 46 als neue Basislinien-Metadaten speichern. Unter einigen Umständen ist es möglicherweise wünschenswert, Regeln in der Regeldatenbank infolge der neuen Konfiguration zu ändern, hinzuzufügen oder zu löschen, um beispielsweise die Regeln auf die neue Konfiguration maßzuschneidern, zum Beispiel durch Implementieren eines Profil-Plug-ins innerhalb von einer oder mehreren Regeln der Regeldatenbank, um Parameter der neuen Konfiguration anzupassen oder zu reflektieren. Zum Beispiel können neue Kommunikationstypen durch die neue Konfiguration hinzukommen und eine Regel kann mit einem Profil-Plug-in auf der Basis der neuen Kommunikation aktualisiert werden, und diese Regel kann dann zum Analysieren der mit diesen neuen Kommunikationstypen assoziierten Metadaten auf der Basis der neuen Sender und/oder Empfänger der Kommunikationen benutzt werden.
In jedem Fall kann die Regel-Engine 42 nach dem Erzeugen eines neuen Satzes von statistischen Basislinien damit beginnen, aktiv Eingriffe auf der Basis der neuen statistischen Basisliniendaten und in der Regeldatenbank 44 gespeicherten Regeln zu erkennen. Wie man verstehen wird, kann die Verwendung des Konfigurationsänderungserkennungsmoduls 70 Falsch-positiv-Meldungen (d.h. inkorrekte Erkennungen von Eingriffen) reduzieren oder begrenzen, die durch eine Änderung der Netzwerkkonfiguration verursacht werden. Darüber hinaus kann das Konfigurationsänderungserkennungsmodul 70 auch zum Neuabstimmen der Anomalieerkennungs-Engine 10 benutzt werden, wenn das Netzwerk umkonfiguriert wird, um es dadurch zu ermöglichen, dass die Anomalieerkennungs-Engine 10 selbst nach Netzwerkkonfigurationsänderungen korrekt arbeitet.
Wie man sehen wird, verteilt das Anomalieerkennungssystem 10 von 1 die Datensammelverarbeitungslast über Netzwerkknoten 22 und braucht somit keine große Menge an Verarbeitungsleistung an den verschiedenen Knoten 22. Ferner reduziert dieses System die Netzwerkknoten- und Anomalieerkennungsanalyselast durch Kenntnis der Systemnetzwerkkonfiguration und meldet Metadaten über Netzwerkverkehr zur Analyse, anstatt separate Überwachungsnetze zu benötigen. Außerdem reduziert dieses System die Falsch-positiv-Rate der Anomalieerkennungsanalyse durch Benachrichtigungen von autorisierten Netzwerkkonfigurationsänderungen oder automatisierter Umkonfiguration (z.B. aufgrund von Hochverfügbarkeitsmechanismen) und kann dieselben Daten zum Durchführen mehrerer Anomalieanalysetypen (z.B. Sicherheit oder Wartung) benutzen. Außerdem kann dieses System die Durchführung von hierarchischer Analyse/Meldung an einem beliebigen Netzwerkknoten in einem Anlagensteuer- oder Industriesteuersystem durch eine beliebige Kombination von vordefinierten Regeln und maschinellem Lernen ermöglichen.
Zudem kann das Anomalieerkennungssystem 10 die Anlagennetzwerkkonfiguration an Netzwerkknoten zum Reduzieren der Metadatensammellast benutzen, kann die bekannte Systemnetzkonfiguration an der Analyse-Engine 34 zum Definieren des Regelsatzes und zum Seeden des Lernprozesses für die Analyse-Engine 34 benutzen und kann nur Metadaten über den von Netzwerkknoten gesehenen Netzwerkverkehr melden (anstatt volle Kopien von Netzwerk-Frames, Logs oder nur SNMP-Warnungen zu melden). Ebenso kann das Anomalieerkennungssystem 10 Systemnetzwerkkonfigurations-Änderungsbenachrichtigungen benutzen, um die Falsch-positiv-Rate der Anomalieerkennungsanalyse zu reduzieren oder die resultierende Benachrichtigung umzuklassifizieren, und kann Metadaten an Netzwerkinfrastrukturgeräten (z.B. Switches, Routern, Firewalls) anstatt an zentralisierten Servern/Geräten sammeln und/oder analysieren. Darüber hinaus kann dieses System 10 Metadaten an Endpunktgeräten (z.B. Controllern, RTUs, E/A-Servern, Workstations, Servern) anstatt an zentralisierten Servern/Geräten sammeln und/oder analysieren.
In einigen Fällen kann das Anomalieerkennungssystem 10 die Metadaten mit einer FPGA, TCP-Offload-Engine oder sonstiger programmierbarer Hardware sammeln und/oder analysieren und kann hierarchische Metadaten innerhalb eines Netzwerkknotens 22 oder über Netzwerkknoten sammeln. Ebenso kann das Anomalieerkennungssystem 10 Metadaten auf der Basis von abgehendem Verkehr sammeln und/oder an Endpunktgeräten (z.B. Controllern, RTUs, E/A-Servern, Workstations, Servern) anstatt an zentralisierten Servern/Geräten analysieren und kann Metadaten auf der Basis der Abwesenheit von Verkehr sammeln und/oder an Endpunktgeräten (z.B. Controllern, RTUs, E/A-Servern, Workstations, Servern) auf der Basis der Systemnetzwerkkonfiguration analysieren. Ferner kann das Anomalieerkennungssystem 10 in einigen Fällen bei Bedarf eingerichtet werden, um alle Netzwerk-Switches anzuzapfen, um auf sämtlichen durch die Switches gehenden Netzwerkverkehr zuzugreifen. Diese Konfiguration lässt sich jedoch nicht gut auf mehrstufige Switch-Topologien skalieren, weil diese Konfiguration die maximale Kapazität jedes Switch begrenzt und das Verlegen/Einrichten zusätzlicher Verkabelung/Netzwerke nur für den Überwachungsverkehr erfordert.
Zum Beispiel illustrieren die 2 und 3 beispielhafte Anlagennetze, in denen das Anomalieerkennungssystem 10 von 1 installiert und benutzt werden kann. Insbesondere illustriert 2 ein Anlagen- oder Industriekommunikationssystem 110 mit einer Reihe verschiedener, aber miteinander verbundener Kommunikationsnetze 112, 114, 116 und 118, die jeweils verschiedene Netzwerkknoten haben. Insbesondere kann das Kommunikationsnetzwerk 112 von 2 ein Geschäftskommunikationsnetz mit mehreren Knoten 122A–122H sein, die durch einen Kommunikationsbus 124 miteinander verbunden sind, der beispielsweise ein Ethernet-Bus oder ein beliebiger/s anderer/s verdrahteter/s oder drahtloser/s Kommunikationsbus oder Netzwerk ist. Die Knoten 122A, 122B können beispielsweise Computer, Server, Workstations usw. beinhalten, auf denen Geschäftsanwendungen oder -programme abgearbeitet werden, und der Knoten 122C kann beispielsweise eine Datenbank sein, die Geschäftsdaten, Industrieanlagenkonfigurationsdaten oder beliebige andere gewünschte Daten über die Anlage 110 speichert. Ebenso können die Knoten 122D, 122E und 122F Gateway-Knoten sein, die das Netzwerk 112 jeweils mit den anderen Kommunikationsnetzen 114, 116, 118 verbinden und Inter-Netzwerk-Kommunikationen zulassen. Ebenso kann ein Knoten 122G ein Gateway-Knoten sein, der das Netzwerk 112 mit dem Internet, dem Cloud oder einem anderen Weitbereichsnetz verbindet, um das Netzwerk 112 zu befähigen, mit fernen Servern, Anlagen oder anderen Computern zu kommunizieren.
In diesem Beispiel sind die Netzwerke 114, 116 und 118 Anlagen-(wie eine Prozessanlage oder Industrieanlage)-Steuernetze, die verschiedene Knoten beinhalten, die durch eine(n) verdrahtete(n) oder drahtlose(n) Kommunikationsbus oder Netzwerkverbindung miteinander verbunden sind. Jedes der Anlagensteuernetze 114, 116, 118 kann beliebige von verschiedenen Typen von Geräten an den Knoten davon beinhalten. Zum Beispiel sind die Anlagensteuernetze 114 und 116 verdrahtete Kommunikationsnetze, die jeweils ein oder mehrere Benutzeroberflächengeräte 130 beinhalten, eine Datenbank oder ein Eventablaufrekorder 132, die/der Anlagensteuernetzwerk-Konfigurationsdaten für die Netzwerke 114 und/oder 116 speichern kann, ein oder mehrere Prozess-Controller-Knoten 134, die über einen Kommunikationsbus 136 miteinander verbunden sind, in diesem Fall in Form eines Ethernet-Kommunikationsbusses, und ein oder mehrere Server- oder Prozessorknoten 138. Die Prozesssteuerknoten 134 können einen oder mehrere Prozess-Controller beinhalten, die kommunikativ mit anderen Geräten wie E/A- und Feldgeräten (z.B. Sensoren, Ventilen, gesteuerten Geräten usw.) über ein oder mehrere verdrahtete oder drahtlose Subnetze 140 gekoppelt sind. Die Feldgeräte in den Subnetzen 140 können beispielsweise die Form von Ventilen, Sensoren, Sendern oder anderen Mess- oder Steuergeräten haben, die einen Parameter oder eine Prozessvariable in der Anlage messen oder die eine physische Steueraktion in Bezug auf einen Materialvorgang oder einen Materialfluss in der Anlage durchführen. Die Feldgeräte-Subnetze 140 können beispielsweise ein beliebiges gewünschtes Prozesssteuerkommunikationsprotokoll oder Paradigma wie das Highway Addressable Remote Transmitter (HART^®) Protokoll, das FOUNDATION^® Fieldbus Protokoll, das Profibus-Protokoll, das CAN-Protokoll usw. benutzen. Ferner können die Feldgeräte-Subnetze 140 als verdrahtete oder drahtlose Netzwerke wie das WirelessHART^® Netzwerk implementiert werden. Die Netzwerke 114 und 116 können auch Gateway-Geräte an den Knoten 122D, 122F aufweisen, die die Netzwerke 114 und 116 mit dem Netzwerk 112, dem Internet oder anderen WANs usw. verbinden. Diese Gateway-Geräte können natürlich eine Firewall und andere Sicherheitsmerkmale oder -anwendungen bereitstellen.
Ebenso ist das Kommunikationsnetz 118 als drahtloses Kommunikationsnetz illustriert, das ein drahtloses Kommunikationsprotokoll wie zum Beispiel ein drahtloses Ethernet-Protokoll, das WirelessHART^®-Protokoll, das drahtlose ISA100-Protokoll usw. benutzen kann. Das Kommunikationsnetz 118 ist als verschiedene Geräte, wie Benutzeroberflächengeräte oder Workstations 130, Datenbanken 132, Prozess-Controller 134, Server 136, Feldgeräte-Subnetze 140, Gateway-Geräte 139 usw. beinhaltend illustriert. Es kann sich natürlich jede beliebige Anzahl von diesen und anderen Gerätetypen an den verschiedenen Knoten der Kommunikationsnetze 114, 116 und 118 befinden. Man wird verstehen, dass beliebige oder alle Netzwerkgeräte in den Netzwerken 112, 114, 116, 118 einen oder mehrere computerlesbare Speicher und Prozessoren beinhalten können, auf denen verschiedene Software-Module, einschließlich der mit dem hierin beschriebenen Anomalieerkennungssystem 10 assoziierten Module, gespeichert und abgearbeitet werden können.
Bedeutsamerweise kann ein mit Bezug auf 1 beschriebenes Anomalieerkennungssystem 10 in beliebigen und allen der Netzwerke 112, 114, 116 und 118 von 2 zum Erkennen von Eingriffen in diese Netzwerke beispielsweise in Form von Malware oder anderen in diesen Netzwerken laufenden unbefugten Anwendungen implementiert werden. Allgemein ausgedrückt kann es ein separates Anomalieerkennungssystem für jedes der Netzwerke 112, 114, 116 und 118 geben, aber in einigen Fällen kann ein einziges Anomalieerkennungssystem zum Abdecken von mehreren der Netzwerke 112–118 benutzt werden, wie zum Beispiel der Netzwerke 114 und 116 oder der Netzwerke 112 und 114 usw. Ebenso können Komponenten für das Anomalieerkennungssystem von einem Netzwerk, wie dem Netzwerk 118, in Geräten in einem anderen der Netze wie z.B. im Netzwerk 112 gespeichert werden.
Wie zum Beispiel allgemein in den Netzwerken 114, 116 und 118 von 2 illustriert, kann ein Anomalieerkennungssystem für jeden dieser Knoten eine Sammelanwendung 150 beinhalten (die die Nachrichtensammelblöcke 30 und 32 von 1 beinhalten kann), die sich an jedem der Netzwerkknoten (oder wenigstens an einigen der Netzwerkknoten) der Kommunikationsnetze 114, 116, 118 befindet, und kann eine Analyse-Engine 154 aufweisen (die die Erkennungs-Engine 34 von 1 sein kann), die sich an einem der Knoten der Netzwerke 114, 116 und 118 befindet, die zu schützen das Anomalieerkennungssystem konfiguriert ist. Im Falle des Netzwerks 118 ist die Analyse-Engine 154 als in einem Knoten des Netzwerks 112 befindlich illustriert, z.B. an der Workstation 122A, um zu illustrieren, dass sich Komponenten eines Anomalieerkennungssystems für ein bestimmtes Netzwerk in einem Gerät außerhalb dieses Netzwerks befinden können.
Allgemein ausgedrückt überwacht oder analysiert jede(s) der Sammelanwendungen oder -module 150 Netzwerknachrichtenverkehr, der auf der Netzwerkverbindung an einem Knoten erzeugt und über diese gesendet wird, und/oder Nachrichtenverkehr, der an dem Netzwerkknoten empfangen (und zu diesem gesendet) wird, und diese Sammelanwendungen oder -module 150 erzeugen Metadaten über diesen Nachrichtenverkehr. Die Sammelanwendungen 150 arbeiten im Allgemeinen unabhängig auf jedem Knoten eines Netzwerks, um Netzwerkverkehrsmetadaten auf jedem Knoten zu sammeln und die Metadaten dann zur Analyse-Engine 154 für dieses Netzwerk zu senden, wobei die Analyse-Engine 154 diese Metadaten zum Ermitteln von Anomalien in Netzwerkverkehrsmustern analysiert. Diese erkannten Anomalien können dann benutzt werden zum Erkennen von potentiellen oder tatsächlichen Eingriffen in das Netzwerk, einschließlich Malware, Spähprogramme usw. Falls gewünscht, können die Sammelanwendungen 150 die Metadaten über den Nachrichtenverkehr auf einem (in einen und aus einem) Netzwerkknoten über das Netzwerk selbst senden, oder mit einem alleinstehenden, separaten oder parallelen Kommunikationsnetz, wenn dies gewünscht wird. Da jedoch im Allgemeinen nur die Metadaten in Bezug auf Nachrichtenverkehr zu der Analyse-Engine 154 gesendet zu werden brauchen und nicht die Nachrichten selbst, tragen die Kommunikationen zwischen den Datensammelanwendungen 150 und der jeweiligen Analyse-Engine 154 nicht wesentlich zur Verkehrslast der Netzwerkverbindung bei. Zusätzlich können sie vorzugsweise, während die Datensammelanwendungen 150 Metadaten in Echtzeit senden können, diese Metadaten speichern und Schübe von Metadaten periodisch zu der jeweiligen Analyse-Engine 154 senden, wann immer eine bestimmte Menge Metadaten für einen Knoten gesammelt wurde, zu vorgegebenen Zeiten, als Reaktion auf vorgegebene Ereignisse usw., um dadurch durch Kommunikationen zwischen den Datensammelanwendungen 150 und den Analyse-Engines 154 verursachten Netzwerkverkehr zu reduzieren. Für Illustrationszwecke wird auch ein Satz von Konfigurationsänderungserkennungsmodulen 170 in den verschiedenen Netzwerken 112, 114, 116, 118 illustriert, und diese Module arbeiten in der oben beschriebenen Weise, um eine jeweilige Analyse-Engine 154 über eine Konfigurationsänderung in einem jeweiligen Netzwerk in Kenntnis zu setzen.
Ebenso illustriert, wieder für Illustrationszwecke, 2 ein Anomalieerkennungssystem für das Netzwerk 114, das vollständig innerhalb des Netzwerks 114 (d.h. innerhalb von Geräten, die direkt mit der Netzwerkverbindung des Netzwerks 114 verbunden sind) angeordnet ist, während das Anomalieerkennungssystem für das Netzwerk 118 Elemente (z.B. die Sammelmodule 150) beinhaltet, die in Geräten in dem Netzwerk 118 angeordnet sind, während die Analyse-Engine 154 (im Knoten 122A) und das Konfigurationsänderungserkennungsmodul 170 (im Knoten 122C) für dieses Netzwerk angeordnet und in Geräten in einem anderen Netzwerk (dem Netzwerk 112), mit dem das Netzwerk 118 kommunikativ gekoppelt ist, ausgeführt werden. Auf diese Weise senden die Nachrichtensammelmodule 150 Metadaten für das Netzwerk 118 zu einer Analyseanwendung 154 für das Netzwerk 118, die tatsächlich in einem Gerät außerhalb des Netzwerks 118 (z.B. in dem Gerät am Knoten 122A des Netzwerks 112) implementiert wird. Ferner kann, obwohl dies nicht eigens dargestellt ist, eine einzige Analyse-Engine 154 zum Erkennen von Verkehrsanomalien in mehreren Netzwerken oder über mehrere Netzwerke benutzt werden. Zum Beispiel kann die Analyse-Engine 154 in dem Gerät am Knoten 122A des Netzwerks 112 zum Empfangen von Metadaten von Geräten in den Netzwerken 112 und 116, in den Netzwerken 118 und 116 oder in den Netzwerken 112, 116 und 118 arbeiten. In diesem Fall würde dieselbe Analyse-Engine 154 Änderungsbenachrichtigungen von einem oder mehreren Konfigurationsänderungserkennungsmodulen 170 empfangen, die sich in Geräten in einem der Netzwerke 112, 116 oder 118 oder sogar in anderen Netzwerken befinden können, je nachdem, wo sich zum Beispiel die Konfigurationsdatenbanken für diese Netzwerke befinden. So kann ein einziges Anomalieerkennungssystem zum Erkennen von Nachrichten- und Verkehrsanomalien in einem einzigen Netzwerk oder über mehrere Netzwerke benutzt werden. Außerdem könnte, obwohl das Anomalieerkennungssystem mit einer einzigen Anomalieerkennungs-Engine 154 für jedes Netzwerk beschrieben wurde, dasselbe Anomalieerkennungssystem mehrere Erkennungs-Engines 154 beispielsweise in unterschiedlichen Geräten eines Netzwerks haben. Eine solche Konfiguration könnte den Verarbeitungsleistungsbedarf einer bestimmten Engine 154 reduzieren, dezentrale Verarbeitung ermöglichen usw.
Als ein weiteres Beispiel illustriert 3 das Kommunikationsnetz 114 von 2 ausführlicher. In diesem Beispiel beinhaltet das Kommunikationsnetz 114 einen verdrahteten Ethernet-Bus 200, der einen oder mehrere Switches 202 beinhalten kann, die verschiedene Geräte miteinander verbinden, wie zum Beispiel ein Gateway mit anderen Netzwerken 226, ein Gateway mit externen Systemen 228 wie dem Internet, ein oder mehrere Benutzeroberflächengeräte oder Workstations 230, eine Konfigurationsdatenbank 232, einen Server 23 und zwei Prozesssteuerknoten 234A und 234B. Hier beinhaltet der erste Prozesssteuerknoten 234A einen oder mehrere redundante Prozess-Controller 260, der/die über Ein-/Ausgangs-(E/A)-Karten 226 und 228 mit verdrahteten Feldgeräten 215–222 kommunikativ verbunden ist/sind und über ein drahtloses Gateway 234 und das Netzwerk-Backbone 200 mit drahtlosen Feldgeräten 240–258 kommunikativ verbunden ist/sind. In diesem Fall ist das drahtlose Gateway 235 der zweite Steuerknoten 234B des Netzwerks 114. In einer anderen Ausgestaltung kann der Controller 260 am Knoten 234A jedoch kommunikativ mit dem drahtlosen Gateway 235 über ein anderes Kommunikationsnetz als das Backbone 200 verbunden sein, wie zum Beispiel über ein(e) andere(s) verdrahtete(s) oder drahtlose(s) Kommunikationsverbindung oder E/A-Modul.
Der Controller 260, der beispielsweise ein DeltaV^TM Controller sein kann, der von Emerson Process Management veräußert wird, kann zum Implementieren von einem oder mehreren Batch-Prozessen oder kontinuierlichen Prozessen, Wartungsanwendungen, Sicherheitssystemanwendungen usw. mit wenigstens einigen der Feldgeräte 215–222 und 240–258 arbeiten. Der Controller 260 kann mit den Feldgeräten 215–222 und 240–258 mit beliebiger gewünschter Hardware und Software kommunikativ verbunden werden, die beispielsweise mit standardmäßigen 4–20 ma Geräten, Ein-/Ausgangs-(E/A)-Karten 236, 238 assoziiert sind, und/oder einem beliebigen Smart-Kommunikationsprotokoll wie dem FOUNDATION^® Fieldbus Protokoll, dem HART^® Protokoll, dem WirelessHART^® Protokoll usw. Der Controller 260 kann zusätzlich oder alternativ mit wenigstens einigen der Feldgeräte 215–222 und 240–258 über andere Verbindungen verbunden sein. In dem in 3 illustrierten Netzwerk 114 sind der Controller 260, die Feldgeräte 215–222 und die E/A-Karten 236, 238 verdrahtete Geräte, und die Feldgeräte 240–258 sind drahtlose Feldgeräte. Die verdrahteten Feldgeräte 215–222 und die drahtlosen Feldgeräte 240–258 könnten jedoch auch beliebigen anderen gewünschten Normen oder Protokollen entsprechen, wie beispielsweise beliebigen verdrahteten oder drahtlosen Protokollen, einschließlich in der Zukunft entwickelten beliebigen Normen oder Protokollen.
Der Controller 260 von 3 beinhaltet einen Prozessor 270, der eine oder mehrere Prozesssteuerroutinen (in einem Speicher 272 gespeichert) implementiert oder überwacht, die Regelkreise beinhalten können. Der Prozessor 270 kann mit den Feldgeräten 215–222 und 240–258 und mit anderen Knoten kommunizieren, die kommunikativ mit dem Backbone 200 verbunden sind, um Steueraktivitäten oder andere Aktivitäten wie Wartungs-, Überwachungs- und Sicherheitssystemaktivitäten durchzuführen. Es ist zu bemerken, dass Teile von beliebigen der hierin beschriebenen Steuerroutinen oder -module von anderen Controllern oder anderen Geräten implementiert oder ausgeführt werden können, wenn dies gewünscht wird. Ebenso können die hierin beschriebenen Steuerroutinen oder -module, die in dem Prozesssteuersystem implementiert werden sollen, jede Form inkl. Software, Firmware, Hardware usw. haben. Steuerroutinen können in jedem gewünschten Software-Format implementiert werden, wie zum Beispiel unter Verwendung von objektorientierter Programmierung, Leiterlogik, sequentiellen Funktionsplänen, Funktionsblockdiagrammen, oder unter Verwendung einer/s beliebigen anderen Software-Programmiersprache oder Design-Paradigmas. Die Steuerroutinen können in jedem gewünschten Speichertyp gespeichert werden, wie zum Beispiel Direktzugriffsspeicher (RAM) oder Festwertspeicher (ROM). Ebenso können die Steuerroutinen beispielsweise in ein oder mehrere EPROMs, EEPROMs, anwendungsspezifische integrierte Schaltungen (ASICs) oder beliebige andere Hardware- oder Firmware-Elemente hart-codiert werden. So kann der Controller 260 zum Implementieren einer Steuerstrategie oder Steuerroutine auf eine beliebige gewünschte Weise konfiguriert werden.
In einigen Ausgestaltungen implementiert der Controller 260 eine Steuerstrategie unter Verwendung dessen, was gewöhnlich als Funktionsblöcke bezeichnet wird, wobei jeder Funktionsblock ein Objekt oder ein anderer Teil (z.B. eine Subroutine) einer Gesamtsteuerroutine ist und in Zusammenhang mit anderen Funktionsblöcken (über Links genannte Kommunikationen) arbeitet, um Prozessregelkreise innerhalb des Prozesssteuersystems zu implementieren. Steuerungsbasierte Funktionsblöcke führen typischerweise eine einer Eingangsfunktion aus, wie zum Beispiel die, die mit einem Sender, einem Sensor oder einem anderen Prozessparametermessgerät assoziiert ist, eine Steuerfunktion wie zum Beispiel die, die mit einer Steuerroutine assoziiert ist, die PID-, Fuzzy-Logic- usw. -Steuerung durchführt, oder eine Ausgangsfunktion, die den Betrieb eines Geräts wie zum Beispiel ein Ventil steuert, um eine physische Funktion innerhalb des Prozesssteuersystems auszuführen. Es existieren natürlich auch Hybrid- und andere Funktionsblocktypen. Funktionsblöcke können im Controller 260 gespeichert sein und von diesem ausgeführt werden, was typischerweise dann der Fall ist, wenn diese Funktionsblöcke mit standardmäßigen 4–20 ma Geräten und einigen Typen von Smart-Feldgeräten wie HART-Geräten benutzt werden oder damit assoziiert sind, oder sie können in den Feldgeräten selbst gespeichert sein und von diesen implementiert werden, was mit Fieldbus-Geräten der Fall sein kann. Der Controller 260 kann eine oder mehrere Steuerroutinen 280 beinhalten, die eine oder mehrere Regelkreise implementieren können. Jeder Regelkreis wird typischerweise als Steuermodul bezeichnet und kann durch Abarbeiten von einem oder mehreren der Funktionsblöcke ausgeführt werden.
Die verdrahteten Feldgeräte 215–222 können beliebige Gerätetypen wie Sensoren, Ventile, Sender, Stellglieder usw. sein, während die E/A-Karten 236 und 238 beliebige Typen von E/A-Geräten entsprechend einem gewünschten Kommunikations- oder Controller-Protokoll sein können. In der in 3 illustrierten Ausgestaltung sind die Feldgeräte 215–218 standardmäßige 4–20 ma Geräte oder HART-Geräte, die über Analogleitungen oder kombinierte Analog- und Digitalleitungen mit der E/A-Karte 236 kommunizieren, während die Feldgeräte 219–222 Smart-Geräte wie FOUNDATION^® Fieldbus-Feldgeräte sind, die über einen digitalen Bus mit der E/A-Karte 238 über ein Fieldbus-Kommunikationsprotokoll kommunizieren. In einigen Ausgestaltungen können jedoch wenigstens einige der verdrahteten Feldgeräte 215–222 und/oder wenigstens einige der E/A-Karten 236, 238 mit dem Controller 260 über ein großes Datennetz kommunizieren. In einigen Ausgestaltungen können wenigstens einige der verdrahteten Feldgeräte 215–222 und/oder wenigstens einige der E/A-Karten 236, 238 Knoten des Prozesssteuersystemnetzes 114 sein.
In der in 3 illustrierten Ausgestaltung kommunizieren die drahtlosen Feldgeräte 240–258 in einem drahtlosen Netzwerk 290 über ein drahtloses Protokoll wie dem WirelessHART^® Protokoll. Solche drahtlosen Feldgeräte 240–258 können direkt mit einem oder mehreren anderen Knoten des Netzes 114 kommunizieren, die auch zum drahtlosen Kommunizieren konfiguriert sind (zum Beispiel über das Drahtlosprotokoll). Zum Kommunizieren mit einem oder mehreren anderen Knoten, die nicht zum drahtlosen Kommunizieren konfiguriert sind, können die drahtlosen Feldgeräte 140–158 das drahtlose Gateway 235 benutzen, das mit dem Kommunikations-Backbone 200 oder einem anderen Prozesssteuerkommunikationsnetz verbunden ist. In einigen Ausgestaltungen können wenigstens einige der drahtlosen Feldgeräte 240–258 Knoten des Prozesssteuersystemnetzes 114 sein.
Das drahtlose Gateway 235 bietet kommunikative Kopplung zwischen den drahtlosen Geräten 240–258, den verdrahteten Geräten 215–222 und/oder anderen Knoten des Prozesssteuernetzes 114. Das drahtlose Gateway 235 bietet kommunikative Kopplung in einigen Fällen über Routing-, Puffer- und Timing-Dienste in unteren Schichten der verdrahteten und drahtlosen Protokollstapel (z.B. Adressumwandlung, Routing, Paketsegmentierung, Priorisierung usw.), während eine oder mehrere gemeinsam genutzte Schichten der verdrahteten und drahtlosen Protokollstapel getunnelt werden. In anderen Fällen kann das drahtlose Gateway 235 Befehle zwischen verdrahteten und drahtlosen Protokollen umsetzen, die keine Protokollschichten gemeinsam nutzen. Zusätzlich zur Protokoll- und Befehlsumwandlung kann das drahtlose Gateway 235 synchronisierte Taktgabe bereitstellen, die von Zeitschlitzen und Superframes (Sätzen von zeitlich gleich beabstandeten Kommunikationszeitschlitzen) eines Scheduling-Schemas benutzt werden, das mit dem in dem drahtlosen Netzwerk 290 implementierten drahtlosen Protokoll assoziiert ist. Ferner kann das drahtlose Gateway 235 Netzwerkmanagement- und Administrationsfunktionen für das drahtlose Netzwerk 290 bereitstellen, wie zum Beispiel Ressourcenmanagement, Leistungseinstellungen, Netzstörungsabhilfe, Verkehrsüberwachung, Sicherheit und dergleichen.
Ähnlich wie die verdrahteten Feldgeräte 215–222 können die drahtlosen Feldgeräte 240–258 des drahtlosen Netzwerks 290 physische Steuerfunktionen innerhalb der Prozessanlage durchführen, z.B. Öffnen oder Schließen von Ventilen oder Durchführen von Messungen von Prozessparametern, oder sie können andere Funktionen ausführen. Die drahtlosen Feldgeräte 240–258 sind jedoch zum Kommunizieren unter Verwendung des drahtlosen Protokolls des Netzwerks 290 konfiguriert. Somit sind die drahtlosen Feldgeräte 240–258, das drahtlose Gateway 235 und andere drahtlose Knoten des drahtlosen Netzes 290 typischerweise Produzenten und Verbraucher von drahtlosen Kommunikationspaketen.
In einigen Szenarien kann das drahtlose Netzwerk 290 nicht-drahtlose Geräte beinhalten. Zum Beispiel kann ein Feldgerät 248 von 3 ein 4–20 ma Legacy-Gerät sein und ein Feldgerät 250 kann ein traditionelles verdrahtetes HART-Gerät sein. Zum Kommunizieren im Netzwerk 290 können die Feldgeräte 248 und 250 mit dem drahtlosen Kommunikationsnetz 290 über einen Drahtlosadapter (WA) 252a oder 252b verbunden werden. Zusätzlich können die Drahtlosadapter 252a, 252b andere Kommunikationsprotokolle wie FOUNDATION^® Fieldbus, PROFIBUS, DeviceNet usw. unterstützen. Ferner kann das drahtlose Netzwerk 290 einen oder mehrere Netzwerkzugangspunkte 255a, 255b beinhalten, die separate physische Geräte in drahtgebundener Kommunikation mit dem drahtlosen Gateway 235 sein können oder die in dem drahtlosen Gateway 235 als integriertes Gerät bereitgestellt werden können. Das drahtlose Netzwerk 290 kann auch einen oder mehrere Router 258 zum Weiterleiten von Paketen von einem drahtlosen Gerät zu einem anderen drahtlosen Gerät innerhalb des drahtlosen Kommunikationsnetzes 290 beinhalten. Die drahtlosen Geräte 240–258 können, wie in 3 durch punktierte Linien illustriert, miteinander und mit dem drahtlosen Gateway 235 über drahtlose Links des drahtlosen Kommunikationsnetzes 290 kommunizieren.
Das Netzwerk 114 von 3 illustriert zwar nur einen einzigen Controller 260 mit einer finiten Anzahl von Feldgeräten 215–222 und 240–258, aber dies ist nur eine illustrative und nicht begrenzende Ausgestaltung. Es kann jede beliebige Zahl von Controllern auf dem Netzwerk 114 vorhanden sein und der Controller 260 kann mit einer beliebigen Zahl von verdrahteten oder drahtlosen Feldgeräten 215–222, 240–258 kommunizieren, um beispielsweise einen Prozess in der Anlage zu steuern. Ferner kann die Prozessanlage auch eine beliebige Anzahl von drahtlosen Gateways 235, Routern 258, Zugangspunkten 255 und drahtlosen Prozesssteuerkommunikationsnetzen 290 beinhalten.
Allgemein ausgedrückt kann ein Bedrohungserkennungssystem in dem Netzwerk 114 auf eine beliebige gewünschte Weise gemäß der Offenbarung von 1 installiert oder implementiert werden. Insbesondere beinhaltet, wie in 3 illustriert, das Anomalieerkennungssystem 10 Kommunikationsmodule 330 (die die Kommunikationsmodule 30 und 32 von 1 sein können), die in jedem der Netzwerkknoten 226, 228, 230, 232, 233, 234A, 234B und 235 und in beliebigen der Switches 202 oder anderen Endpunktgeräten des Netzwerks 114 angeordnet sein können. Obwohl dies in 3 nicht ausführlich dargestellt ist, können die Kommunikationsmodule 330 in beliebigen der Subknotengeräte installiert sein, wie zum Beispiel in den E/A-Geräten 236 und 238 oder in beliebigen oder allen der verdrahteten Feldgeräte 215–222 oder in beliebigen oder allen der drahtlosen Geräte 240–258. In 3 ist jedes der Kommunikationsmodule 330 in einem Subknotengerät mit der Bezugszahl 330a bezeichnet, um zu zeigen, dass es sich in einem Teilknoten eines größeren Knotens des Netzwerks 114 befindet. Wie mit Bezug auf 1 angedeutet, analysieren die Kommunikationsmodule 330 und 330a Verkehr in und aus jeden/m der Knoten und kompilieren Metadaten über den Verkehr.
In diesem beispielhaften System kommunizieren die Kommunikationsmodule 230 und 230a über die Netzwerkverbindung 200 mit einer Anomalieerkennungs-Engine 334, die als in einem der Benutzeroberflächengeräte 230 installiert illustriert ist. Die Anomalieerkennungs-Engine 334 kann jedoch in beliebigen der anderen Computergeräte auf dem Netzwerk 114 installiert werden, wie zum Beispiel in der Konfigurationsdatenbank 232, den Gateway-Geräten 226, 228, den Switches 202 usw. auf dem Netzwerk. Darüber hinaus kann die Anomalieerkennungs-Engine 334 in einem Computergerät außerhalb des Netzwerks 114 angeordnet sein, wie zum Beispiel in einem der Netzwerke 112, 116, 118 von 2. In diesem Fall können die auf den verschiedenen Knoten oder Teilknoten des Netzwerks 114 gesammelten Metadaten über die Netzwerkverbindung 200 und eines der Gateway-Geräte 226, 228 (das eine Firewall beinhalten kann oder auch nicht) zu einem anderen Netzwerk übermittelt werden. Zusätzlich können Kommunikationen von den Subnetzgeräten, wie zum Beispiel den Feldgeräten 215–222, E/A-Geräten 236, 238 und drahtlosen Feldgeräten 240–258, zu einem primären Netzknotengerät wie zum Beispiel dem Controller 260 oder dem Gateway-Gerät 235 gesendet werden, und diese Geräte können dann diese Kommunikationen zur Erkennungs-Engine 334 weiterleiten. Darüber hinaus beinhaltet, wie in 3 illustriert, die Konfigurationsdatenbank 232 ein Konfigurationsänderungsmodul 370, das Konfigurationsänderungen an der Erkennungs-Engine 234 auf eine beliebige gewünschte Weise erkennt und kommuniziert. Wie wenigstens in einigen der Knoten von 3 illustriert, beinhaltet jedes der Knotengeräte einen Prozessor 309, der ein Mikroprozessor, eine ASIC oder ein anderer Prozessor sein kann, der die verschiedenen Anomalieerkennungssystemmodule 330, 334 und 370 implementiert und ausführt und beinhaltet einen computerlesbaren Speicher 311, der diese Module zur Ausführung auf dem Prozessor 309 speichert.
4 zeigt ein beispielhaftes Fließschema, das den Kommunikationsfluss zwischen und die Verarbeitung an verschiedenen Knoten eines Kommunikationsnetzes illustriert, das ein beispielhaftes Anomalieerkennungssystem wie hierin beschrieben implementiert. Insbesondere beinhaltet eine Routine 400 mehrere unterschiedliche Komponenten, die in unterschiedlichen Geräten von oder auf einem Netzwerk implementiert werden können, einschließlich einer Komponente 402, die in jedem der Geräte oder Netzwerkknoten implementiert werden kann, in denen Nachrichtenverkehrsmetadaten erzeugt und gesammelt werden; einer Komponente 404, die zusammen mit einem Konfigurationsmodul, einer Konfigurationsdatenbank oder einer anderen Konfigurationsroutine gespeichert und in dieser oder als Teil dieser implementiert werden kann, um Konfigurationsänderungen an der Konfiguration eines Knotens zu erkennen; und einer Komponente 406, die in der Expert- oder Anomalieerkennungs-Engine benutzt werden kann, um Anomalien in dem analysierten Netzwerk zu erkennen.
Die Komponente oder Routine 402 beinhaltet einen ersten Block 410, der eingehende Nachrichten und abgehende Nachrichten an einem Knoten sammelt und sichtet und sich in der Kommunikationsschicht des Netzwerks befinden oder in Verbindung damit arbeiten kann, so dass er Zugang zu allen Nachrichten hat, die in den Knoten eingehen und davon abgehen. Der Block 410, der die Blöcke 30 und 31 von 1 implementieren kann, um die Nachrichten zu sichten und die Nachrichten vorübergehend zu speichern. Nach dem Sammeln einer Nachricht erzeugt und speichert ein Block 412 Metadaten über die Nachricht, einschließlich beliebiger der hierin beschriebenen Metadaten oder beliebiger anderer Metadaten, die von der Analyse-Engine angefordert oder benötigt werden. Natürlich kann die spezifische Natur der gesammelten und erzeugten Metadaten von Zeit zu Zeit auf der Basis der Konfiguration der in der Regel-Engine gespeicherten Regeln geändert werden. Als Nächstes ermittelt ein Block 414, ob es Zeit ist, die Metadaten zur Analyse-Engine zu senden, was periodisch erfolgen kann, als Reaktion auf eine Benutzeranforderung, wenn eine bestimmte Menge an Metadaten erzeugt oder gespeichert ist, wenn eine bestimmte Menge an Nachrichten analysiert wurde, usw. Wenn die Metadaten nicht gesendet zu werden brauchen, dann überträgt der Block 414 die Steuerung zu Block 410. Wenn die Metadaten jedoch gesendet werden müssen, dann sendet ein Block 416 die gespeicherten Metadaten zur Analyse-Engine oder zur Anomalieerkennungs-Engine, je nachdem, in welchem Knoten sich die Engine befindet. Der Block 416 sendet möglicherweise auch Spezifika über den Knoten, der die Metadaten erzeugt hat, oder andere Kontextinformationen, die von der Analyse-Engine benutzt werden können. Während der Block 416 diese Metadaten über die Kommunikationsverbindung oder den Bus des Netzes oder über ein separates externes Kommunikationsnetz senden kann, können die Kommunikationen in den Fällen, in denen sich die Routine 402 auf demselben Gerät befindet wie die Analyse-Engine, über Inter-Geräte-Kommunikationen stattfinden. Die Metadaten sind in 4 durch eine punktierte Linie so dargestellt, dass sie vom Block 416 zur Netzanalyseroutine 406 in der Anomalieerkennungs-Engine gesendet werden.
Die Routine 402 setzt den Betrieb an jedem Knoten des Netzwerks natürlich kontinuierlich während des Betriebs des Netzwerks fort, um alle eingehenden und abgehenden Nachrichten zu analysieren und um Metadaten zu erzeugen und zu speichern und diese Metadaten bei Bedarf zu der Anomalieerkennungs-Engine zu senden.
Eine Routine 404, die in einer Konfigurationsdatenbank oder einer Konfigurationsroutine arbeiten kann, die Konfigurationsänderungen an der Netzwerkkonfiguration vornimmt, beinhaltet einen Block 420, der erkennt, ob es eine Konfigurationsänderung gibt, und, wenn nicht, auf sich selbst zurückgeht und die Analyse daraufhin fortsetzt, wann eine Konfigurationsänderung vorgenommen wird. Wenn eine Konfigurationsänderung vorgenommen wird, beispielsweise dann, wenn eine in der Konfigurationsdatenbank gespeichert wird, wenn eine von einer Konfigurationsroutine erzeugt und auf das Netzwerk heruntergeladen wird, wenn eine neue Konfiguration oder eine Konfigurationsänderung auf eine Konfigurationsdatenbank heruntergeladen wird usw., dann sendet ein Block 422 die Notiz über eine Konfigurationsänderung und/oder sendet neue Konfigurationsdetails oder sogar die gesamte neue Konfiguration zur Erkennungs-Engine, wie durch die punktierte Linie von Block 422 angedeutet wird. Diese Kommunikation kann bei Bedarf über die Netzwerkverbindung erfolgen. Die Routine 404 setzt natürlich den Betrieb zum Erkennen von Konfigurationsänderungen und bei Bedarf zum Senden von Benachrichtigungen über diese Änderungen sowie von Konfigurationsänderungsdetails zur Anomalieerkennungs-Engine fort, die die Routine 406 implementiert.
Wie in 4 illustriert, beinhaltet die Routine 406 einen Block 430, der Metadaten von den verschiedenen Knoten empfängt und speichert und die Metadaten im Speicher wie zum Beispiel dem Metadaten-Speicher 50 von 1 zur späteren Analyse speichert. Die Metadaten können auf jede beliebige gewünschte Weise unter Verwendung jeder Art von gewünschten Kommunikationen empfangen und gespeichert werden und können zusätzlich mit einer/m beliebigen gewünschten Datenbankspeicherroutine und/oder System gespeichert werden. Die Metadaten können auf der Basis des Knotens gespeichert werden, von dem sie kommen, sowie auf eine Art und Weise, die auf die jeweiligen Typen, Quellen usw. der Metadaten verweist. Diese Metadaten können beispielsweise in einer relationalen Datenbank, auf die auf viele verschiedene Weisen zugegriffen werden kann, auf der Basis des Typs der gespeicherten Metadaten, der Parameter der Metadaten, der Quelle der Metadaten, der Zeit usw., gespeichert werden.
In jedem Fall ermittelt ein Block 432 während der Ausführung, ob es neue Regeln (einschließlich geänderter Regeln) gibt, die für die Verwendung durch die Anomalieerkennungs-Engine erzeugt wurden. Solche neuen Regeln können beispielsweise von einem Benutzer kommen, der möglicherweise Regeln in der Anomalieerkennungs-Engine ändert, oder vom Sicherheitspersonal, das neue Regeln herunterladen, Regeln ändern oder von den aktuellen Regeln benutzte Parameter oder Grenzen umkonfigurieren kann. Wenn neue oder geänderte Regeln oder Grenzdaten erhalten wurden, dann übergibt der Block 432 die Steuerung an den Block 450, der die neuen Regeln dann in der Regeldatenbank der Anomalieerkennungs-Engine speichert, wie zum Beispiel der Regeldatenbank 44 von 1, und/oder neue Grenz- oder Parameterdaten in der Verkehrsmusterdatenbank 46 von 1 speichert. Zusätzlich revidiert ein Block 452 die effektiven Regeln in der Regeldatenbank auf der Basis von Regeländerungen oder implementiert diese. In jedem Fall ermittelt ein Block 434, wenn keine neuen Regeln oder Regeländerungen erkannt werden oder nach dem Speichern der neuen Regeln oder Daten, ob eine neue Konfiguration im Netzwerk gespeichert und/oder gesichert wurde, wie durch die Konfigurationsänderungsroutine 404 angedeutet. Wenn keine neue Konfiguration oder Konfigurationsänderung erkannt wurde, dann kann das Anomalieerkennungssystem gemäß dem aktuellen Regelsatz und dem aktuellen Satz von Verkehrsparameterdaten arbeiten und die Steuerung geht auf einen Block 436 über. Der Block 436 ermittelt, ob es Zeit ist, die derzeit in der Metadatendatenbank gespeicherten Metadaten zu verarbeiten. Zum Beispiel kann der Block 436 ermitteln, ob Metadaten periodisch verarbeitet werden müssen, wie zum Beispiel einmal die Sekunde, einmal die Minute, einmal die Stunde usw., oder in irgendeinem anderen Zeitrahmen, oder kann dies als Reaktion auf eine Benutzeranforderung oder als Reaktion auf das Auftreten eines vorbestimmten Ereignisses wie zum Beispiel einer Alarmerzeugung tun. In jedem Fall gibt der Block 436, wenn es nicht Zeit ist, die Metadaten zu verarbeiten, die Steuerung an den Block 430 zur nächsten Wiederholung der Anomalieerkennungsroutine 406 zurück.
Wenn jedoch der Block 436 feststellt, dass es Zeit ist, die Metadaten zu verarbeiten, dann analysiert ein Block 438 die Metadaten anhand von einer oder mehreren der in der Regeldatenbank 44 von 1 gespeicherten Regeln und der in der Verkehrsparameterdatenbank 46 von 1 gespeicherten Basislinienmetadaten und Verkehrsparameter. Der Block 438, der von der Regel-Engine 42 von 1 implementiert werden kann, kann die Logikregeln in jeder gewünschten Weise analysieren oder verarbeiten. Nach dem Analysieren aller Metadaten oder eines Teils der Metadaten in einer oder mehreren der Regeln oder allen Regeln ermittelt der Block 44 dann, ob es nötig ist, eine Warnung zu erzeugen, wenn beispielsweise eine potentielle Anomalie auf der Basis des Betriebs der Regeln in der Regeldatenbank erkannt wurde. Wenn ja, dann sendet ein Block 442 tatsächlich eine Warnung auf der Basis des erkannten Anomalietyps oder von anderen Informationen zu einem Benutzer, der auf irgendeine Weise auf der Basis des erkannten Anomalietyps oder auf der Basis der Spezifika der Regeln, die auf der Basis der Anomalieerkennungsanalyse verletzt wurden,, designiert sein kann. Der Block 442 kann eine Warnung zu einem oder mehreren Benutzern auf der Basis ihrer Identität oder auf der Basis einer vorkonfigurierten Liste dessen senden, welcher Benutzer welche Anomalieerkennungstypen erhalten soll. Zusätzlich kann der Block 442 automatische Aktionen induzieren oder einleiten, wie zum Beispiel das Netz abschalten, eine Nachricht zu dem Knoten senden, in dem eine Anomalie erkannt wurde, damit er sich vom Netzwerk abtrennt, bestimmte Anwendungen im Knoten abschalten usw. Dann kehrt die Steuerung zum Block 430 für einen neuen Zyklus oder eine neue Wiederholung der Routine 406 zurück.
Wenn der Block 434 feststellt, dass eine neue Konfigurationsänderung vorgenommen wurde, dann ermittelt ein Block 460, ob er einen Satz von Regeln auf der Basis der Konfigurationsänderung ändern muss. Wenn ja, dann ändert ein Block 452 die effektiven Regeln wie in der Regeldatenbank gespeichert entweder automatisch oder als Reaktion auf eine Benutzerangabe, und speichert die neuen oder geänderten Regeln in der Regeldatenbank (z.B. der Datenbank 44 von 1). In jedem Fall ermittelt ein Block 462, ob es nötig ist, auf der Basis der Konfigurationsänderung die Basislinien-Verkehrsdatenparameter zu ändern, weil beispielsweise die Konfiguration den erwarteten Betrieb des Netzwerks im Hinblick auf Verkehrsfluss in einen oder aus einem bestimmten Knoten oder dem Netzwerk insgesamt verändern kann. Wenn ja, dann sammelt ein Block 464 Metadaten von einem oder mehreren Knoten für eine vorbestimmte Zeitperiode, und ein Block 466 ermittelt, ob genügend Metadaten über diese Zeitperiode gesammelt wurden. Wenn nicht, dann kehrt die Steuerung zu Block 464 zurück, der weiter Metadaten von den Knoten unter der neuen Konfiguration sammelt. Wenn der Block 466 erkennt, dass genügend Metadaten gesammelt wurden, dann erzeugt ein Block 468 neue Basislinien-Verkehrsdatenparameter von den gesammelten Metadaten beispielsweise durch Kompilieren neuer Statistiken über die Metadaten oder Verarbeiten der Metadaten auf irgendeine andere gewünschte Weise. Am Ende des Prozesses geht die Steuerung zurück zu Block 430, um Anomalieerkennung anhand der Regeln und der neuen Verkehrsdatenparameter gemäß Ermittlung vom Betrieb des Netzwerks unter der neuen Konfiguration zu betreiben.
Wie man verstehen wird, benutzt das hierin beschriebene Anomalieerkennungssystem die Systemnetzwerkkonfiguration an Netzwerkknoten, um die Metadatensammellast zu reduzieren, benutzt die bekannte Systemnetzkonfiguration an der Analyse-Engine zum Definieren des Regelsatzes und zum Seeden des Lernprozesses für die Analyse-Engine, bei der es sich auch um eine Lern-Engine handeln kann. Falls die Analyse-Engine eine Lern-Engine ist, kann die Regel-Engine der Analyse-Engine Feedback beispielsweise von einem Benutzer erhalten, um zu ermitteln, ob eine Anomalie erkannt werden soll oder ob eine erkannte Anomalie keinen Eingriff in das Netzwerk anzeigte, und kann die Regeln entsprechend ändern, so dass sie dieses Feedback integrieren oder reflektieren. Die Anomalieerkennungs-Engine meldet auch Metadaten über den vom Netzwerkknoten gesehenen Netzwerkverkehr (anstatt voller Kopien von Netzwerk-Frames, Logs oder nur SNMP-Warnungen) und benutzt eine Systemnetzwerkkonfigurations-Änderungsbenachrichtigung zum Reduzieren der Falsch-positiv-Rate der Anomalieerkennungsanalyse oder zum Umklassifizieren der resultierenden Benachrichtigung. Zudem kann dieses System Metadaten an Netzwerkinfrastrukturgeräten (z.B. Switches, Routers, Firewalls) anstatt an zentralisierten Servern/Geräten sammeln und/oder analysieren, kann Metadaten an Endpunktgeräten (z.B. Controllern, RTUs, E/A-Servern, Workstations, Servern) anstatt an zentralisierten Servern/Geräten sammeln und/oder analysieren und kann die Metadaten mit einer FPGA, TCP-Offload-Engine oder sonstiger programmierbarer Hardware sammeln und/oder analysieren. Ferner kann das System hierarchische Metadaten innerhalb eines Netzwerkknotens oder über Netzwerkknoten sammeln und kann Metadaten auf der Basis der Abwesenheit von Verkehr sammeln und/oder an Endpunktgeräten (z.B. Controllern, RTUs, E/A-Servern, Workstations, Servern) auf der Basis der Systemnetzwerkkonfiguration analysieren.
Die hierin beschriebenen Sicherheitstechniken wurden zwar so beschrieben, dass sie in Verbindung mit vernetzten Prozesssteuergeräten und Systemen mittels Ethernet und verschiedenen bekannten Prozesssteuerprotokollen wie Fieldbus, HART und standardmäßigen 4–20 ma Protokollen benutzt werden, aber die hierin beschriebenen Sicherheitstechniken können natürlich auch in jedem Steuergerätetyp unter Verwendung eines/r beliebigen anderen Prozesssteuerkommunikationsprotokolls oder Programmierumgebung implementiert werden und können mit beliebigen anderen Typen von Geräten, Funktionsblöcken oder Controllern verwendet werden. Die hierin beschriebenen Sicherheitsmerkmale werden zwar vorzugsweise in Software implementiert, aber sie können auch in Hardware, Firmware usw. implementiert werden und können von jedem anderen mit einem Computergerät assoziierten Prozessor ausgeführt werden. So können die hierin beschriebenen Verfahren und Routinen und Systeme in einer standardmäßigen Universal-CPU oder auf speziell entwickelter Hardware oder Firmware wie beispielsweise ASICs implementiert werden, wenn dies gewünscht wird. Wenn sie in Software implementiert werden, dann kann die Software in einem beliebigen computerlesbaren Speicher wie einer Magnetplatte, einer Laserplatte, einer Bildplatte oder einem anderen Speichermedium, in einem RAM oder ROM eines Computers oder Prozessors usw. gespeichert werden. Ebenso kann diese Software einem Benutzer oder einem Prozesssteuersystem mit einem beliebigen bekannten oder gewünschten Lieferverfahren geliefert werden, zum Beispiel einschließlich einer computerlesbaren Platte oder einem anderen transportierbaren Computer-Speichermechanismus, oder kann über einen Kommunikationskanal wie eine Telefonleitung, das Internet usw. moduliert werden.
Außerdem wurde die vorliegende Erfindung zwar mit Bezug auf spezifische Beispiele beschrieben, die lediglich illustrativ sein und die Erfindung nicht begrenzen sollen, aber die durchschnittliche Fachperson wird erkennen, dass Änderungen, Zusätze oder Löschungen an den offenbarten Ausgestaltungen vorgenommen werden können, ohne von Wesen und Umfang der Erfindung abzuweichen.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

ISA100-Protokoll [0034]

Claims

Anomalieerkennungssystem zur Verwendung in einem Kommunikationsnetz mit mehreren Netzwerkknoten, die kommunikativ durch eine Kommunikationsverbindung gekoppelt sind, das Folgendes umfasst: mehrere Nachrichtenmodule, wobei jedes der mehreren Nachrichtenmodule auf einem Prozessor auf einem der Netzwerkknoten läuft, um Nachrichtenverkehr auf dem Netzwerkknoten zu erkennen und um Metadaten über den Nachrichtenverkehr auf dem Netzwerkknoten zu erzeugen; eine Analyse-Engine, die in einem mit dem Kommunikationsnetz gekoppelten Verarbeitungsgerät gespeichert ist und darauf abgearbeitet wird, die Folgendes umfasst: einen Metadatenspeicher, einen Controller, der auf einem Prozessor des Verarbeitungsgeräts läuft, um die Metadaten über jeden der Netzwerkknoten von den mehreren Nachrichtenmodulen zu empfangen, und der die empfangenen Metadaten in dem Metadatenspeicher speichert, eine Regeldatenbank, die einen Satz von Logikregeln speichert, eine Regel-Engine, die auf einem Prozessor des Verarbeitungsgeräts läuft, um die in dem Metadatenspeicher gespeicherten Metadaten anhand der in der Regeldatenbank gespeicherten Logikregeln zu verarbeiten, um eine Verkehrsmusteranomalie in dem Kommunikationsnetz zu erkennen, und ein Benachrichtigungsmodul, das auf einem Prozessor des Verarbeitungsgeräts läuft, um eine Benachrichtigung einer erkannten Anomalie zu einem Benutzer zu senden.
Anomalieerkennungssystem nach Anspruch 1, wobei die Analyse-Engine ferner eine Metadaten-Basisliniendatenbank beinhaltet, die Basislinieninformationen über Metadaten speichert, die für das Kommunikationsnetz während des Betriebs des Kommunikationsnetzes während einer Basislinienzeitperiode gesammelt wurden, und wobei die Regel-Engine auf einem Prozessor des Verarbeitungsgeräts läuft, um die in dem Metadatenspeicher gespeicherten Metadaten anhand der in der Regeldatenbank gespeicherten Logikregeln und der in der Metadaten-Basisliniendatenbank gespeicherten Basislinien-Informationen zu verarbeiten, um eine Verkehrsmusteranomalie in dem Kommunikationsnetz zu erkennen, wobei insbesondere die Metadaten-Basisliniendatenbank einen oder mehrere Metadatenparameter speichert, die eine Grenze oder einen Bereich reflektieren, der von einer oder mehreren der Logikregeln zum Erkennen einer Anomalie anhand der in dem Metadatenspeicher gespeicherten Metadaten zu benutzen ist.
Anomalieerkennungssystem nach Anspruch 2, das ferner ein Konfigurationsänderungserkennungsmodul beinhaltet, das in einem weiteren mit dem Kommunikationsnetz gekoppelten Verarbeitungsgerät gespeichert ist, das auf einem Prozessor des weiteren Verarbeitungsgeräts läuft, um eine Konfigurationsänderung an der Konfiguration des Kommunikationsnetzes zu erkennen, und das eine Notiz über eine erkannte Konfigurationsänderung zu der Analyse-Engine sendet, wobei insbesondere das Konfigurationsänderungserkennungsmodul in einer Konfigurationsdatenbank gespeichert ist.
Anomalieerkennungssystem nach Anspruch 3, wobei der Controller der Analyse-Engine eine Logikregel in der Regeldatenbank auf der Basis der erkannten Konfigurationsänderung ändert; wobei insbesondere der Controller vor dem Ändern einer Logikregel in der Logikdatenbank eine neue Logikregel von einem Benutzer empfängt und/oder wobei der Controller eine Logikregel auf der Basis eines Konfigurationsänderungstyps ändert und/oder wobei das Konfigurationsänderungserkennungsmodul einen Typ einer Konfigurationsänderung an die Analyse-Engine kommuniziert und/oder wobei der Controller der Analyse-Engine einen neuen Satz von Basislinienmetadaten für das Kommunikationsnetz in der Metadatendatenbank als Reaktion auf die erkannte Konfigurationsänderung sammelt und einen neuen Satz von Basislinieninformationen von dem neuen Satz von Basislinienmetadaten für das mit der neuen Konfiguration laufende Kommunikationsnetz erzeugt.
Anomalieerkennungssystem nach einem der Ansprüche 1 bis 4, wobei die Regel-Engine eine Lern-Engine ist und/oder wobei das Benachrichtigungsmodul die Benachrichtigung über die Kommunikationsverbindung des Kommunikationsnetzes sendet.
Anomalieerkennungssystem nach einem der Ansprüche 1 bis 5, wobei das Benachrichtigungsmodul auf einem Prozessor läuft, um einen Kommunikationsparameter in einem oder mehreren Netzwerkknoten des Kommunikationsnetzes einzustellen; wobei insbesondere das Benachrichtigungsmodul läuft, um einen Kommunikationsparameter einzustellen, der verhindert, dass einer der ein oder mehreren Netzwerkknoten des Kommunikationsnetzes auf dem Kommunikationsnetz kommuniziert und/oder wobei das Benachrichtigungsmodul läuft, um einen Kommunikationsparameter einzustellen, der verhindert, dass ein oder mehrere Netzwerknoten des Kommunikationsnetzes mit einem anderen Netzwerk kommunizieren und/oder wobei das Benachrichtigungsmodul läuft, um einen Kommunikationsparameter einzustellen, der verhindert, dass einer der ein oder mehreren Netzwerkknoten des Kommunikationsnetzes es zulässt, dass eine bestimmte Anwendung auf der Kommunikationsverbindung kommuniziert und/oder wobei das Benachrichtigungsmodul läuft, um einen Kommunikationsparameter einzustellen, der verhindert, dass einer der ein oder mehreren Netzwerknoten des Kommunikationsnetzes bestimmte Nachrichtentypen auf der Kommunikationsverbindung kommuniziert.
Anomalieerkennungssystem nach einem der Ansprüche 1 bis 6, wobei die Analyse-Engine sich in einem Verarbeitungsgerät auf einem der Netzwerkknoten befindet, der direkt mit der Kommunikationsverbindung des Kommunikationsnetzes verbunden ist und/oder, wobei die Analyse-Engine sich in einem Verarbeitungsgerät befindet, das nicht direkt mit der Kommunikationsverbindung des Kommunikationsnetzes verbunden ist.
Anomalieerkennungssystem nach einem der Ansprüche 1 bis 7, wobei wenigstens eines der mehreren Nachrichtenmodule sich in einem Verarbeitungsgerät in einem Subnetz des Kommunikationsnetzes und/oder wobei eines der Nachrichtenmodule in einem Prozess-Controller-Gerät angeordnet ist, das mit einem oder mehreren Feldgeräten zum Steuern eines Prozesses oder einer Industrieanlage gekoppelt ist und/oder wobei jedes der Nachrichtenmodule ein eingehendes Nachrichtenmodul beinhaltet, das an einem Netzwerkknoten über die Kommunikationsverbindung empfangene Nachrichten analysiert und/oder wobei jedes der Nachrichtenmodule ein abgehendes Nachrichtenmodul beinhaltet, das auf der Kommunikationsverbindung von einem Netzwerkknoten gesendete Nachrichten analysiert.
Anomalieerkennungssystem zur Verwendung in einer Anlagenumgebung, das Folgendes umfasst: ein Kommunikationsnetz mit einer Vielzahl von Netzwerkknoten, die jeweils einen Prozessor und einen computerlesbaren Speicher aufweisen, wobei die Vielzahl von Netzwerkknoten durch eine Kommunikationsverbindung miteinander verbunden sind; mehrere Nachrichtenmodule, wobei jedes der Nachrichtenmodule auf dem Prozessor auf einem anderen der Netzwerkknoten läuft, um Nachrichtenverkehr am Netzwerkknoten zu erkennen und um Metadaten über den Nachrichtenverkehr am Netzwerkknoten zu erzeugen; eine Analyse-Engine, die kommunikativ mit jedem der mehreren Nachrichtenmodule gekoppelt ist, wobei die Analyse-Engine auf einem mit dem Kommunikationsnetz gekoppelten Verarbeitungsgerät läuft, das Folgendes beinhaltet: einen Metadatenspeicher, einen Controller, der auf einem Prozessor des Verarbeitungsgeräts läuft, um die Metadaten über jeden der Netzwerkknoten von den mehreren Nachrichtenmodulen zu empfangen, und der die empfangenen Metadaten im Metadatenspeicher speichert, eine Regeldatenbank, die einen Satz von Logikregeln speichert, eine Regel-Engine, die auf einem Prozessor des Verarbeitungsgeräts läuft, um die im Metadatenspeicher gespeicherten Metadaten anhand der in der Regeldatenbank gespeicherten Logikregeln zu verarbeiten, um eine Verkehrsmusteranomalie in dem Kommunikationsnetz zu erkennen, und ein Benachrichtigungsmodul, das auf einem Prozessor des Verarbeitungsgeräts läuft, um eine Benachrichtigung über eine erkannte Anomalie zu senden.
Anomalieerkennungssystem nach Anspruch 9, das ferner ein Konfigurationsänderungserkennungsmodul beinhaltet, das in einem weiteren mit dem Kommunikationsnetz gekoppelten Verarbeitungsgerät gespeichert ist, das auf einem Prozessor des weiteren Verarbeitungsgeräts läuft, um eine Konfigurationsänderung an der Konfiguration des Kommunikationsnetzes zu erkennen, und eine Notiz über eine erkannte Konfigurationsänderung zu der Analyse-Engine sendet; wobei insbesondere das Konfigurationsänderungserkennungsmodul einen Typ einer Konfigurationsänderung zu der Analyse-Engine kommuniziert und/oder wobei der Controller der Analyse-Engine einen Satz von Basislinienmetadaten für das Kommunikationsnetz in der Metadatendatenbank als Reaktion auf die erkannte Konfigurationsänderung sammelt und einen Satz von Basislinieninformationen aus dem Satz von Basislinienmetadaten für das Kommunikationsnetz mit der neuen Konfiguration erzeugt, und wobei die Regel-Engine den Satz von Basislinieninformationen beim Implementieren der Logikregeln zum Erkennen einer Anomalie benutzt und/oder wobei das Konfigurationsänderungserkennungsmodul in einer mit der Kommunikationsverbindung verbundenen Konfigurationsdatenbank gespeichert ist und/oder wobei das Konfigurationsänderungserkennungsmodul in einem Verarbeitungsgerät gespeichert ist, das nicht direkt mit der Kommunikationsverbindung verbunden ist.
Anomalieerkennungssystem nach Anspruch 9 oder 10, wobei die Analyse-Engine ferner eine Metadaten-Basisliniendatenbank beinhaltet, die Basislinieninformationen über Metadaten speichert, die für das Kommunikationsnetz während des Betriebs des Kommunikationsnetzes während einer Basislinien-Zeitperiode gesammelt wurden, und wobei die Regel-Engine auf einem Prozessor des Verarbeitungsgeräts läuft, um die in dem Metadatenspeicher gespeicherten Metadaten anhand der in der Regeldatenbank gespeicherten Logikregeln und der in der Metadaten-Basisliniendatenbank gespeicherten Basislinieninformationen zu verarbeiten, um eine Verkehrsmusteranomalie im Kommunikationsnetz zu erkennen; wobei insbesondere die Metadaten-Basisliniendatenbank einen oder mehrere Metadatenparameter speichert, die eine Grenze oder einen Bereich reflektieren, die/der von einer oder mehreren der Logikregeln benutzt werden soll, um eine Anomalie anhand der im Metadatenspeicher gespeicherten Metadaten zu erkennen.
Anomalieerkennungssystem nach einem der Ansprüche 9 bis 11, wobei sich die Analyse-Engine in einem Verarbeitungsgerät auf einem der Netzwerkknoten befindet, der direkt mit der Kommunikationsverbindung des Kommunikationsnetzes verbunden ist und/oder wobei wenigstens eines der mehreren Nachrichtenmodule sich in einem Verarbeitungsgerät in einem Subnetz des Kommunikationsnetzes befindet und/oder, wobei das Benachrichtigungsmodul auf einem Prozessor des Verarbeitungsgeräts läuft, um einen Kommunikationsparameter in einem oder mehreren Netzwerkknoten des Kommunikationsnetzes einzustellen, wobei insbesondere das Benachrichtigungsmodul einen Satz von Kommunikationsparametern einstellt, der verhindert, dass einer der ein oder mehreren Netzwerkknoten des Kommunikationsnetzes auf der Kommunikationsverbindung kommuniziert.
Verfahren zum Ausführen einer Anomalieerkennung in einem Anlagenkommunikationsnetz mit mehreren Netzwerkknoten, die durch eine Kommunikationsverbindung miteinander verbunden sind, das Folgendes beinhaltet: Analysieren von Nachrichtenverkehr auf zwei oder mehr der mehreren Netzwerkknoten mittels eines Prozessors auf jedem der zwei oder mehr der mehreren Netzwerkknoten, um Metadaten über den Nachrichtenverkehr auf jedem der zwei oder mehr der mehreren Netzwerkknoten zu erzeugen; elektronisches Senden der erzeugten Metadaten von jedem der zwei oder mehr der mehreren Netzwerkknoten zu einer Analyse-Engine, die sich in einem mit dem Kommunikationsnetz gekoppelten Computer-Verarbeitungsgerät befindet; Speichern der Metadaten von jedem der zwei oder mehr der mehreren Netzwerkknoten auf einem computerlesbaren Speicher auf dem Computer-Verarbeitungsgerät; Speichern eines Satzes von Basislinien-Metadatenparametern in einem computerlesbaren Speicher auf dem Computer-Verarbeitungsgerät; Analysieren der gespeicherten Metadaten auf der Analyse-Engine mittels eines Prozessors auf dem Computer-Verarbeitungsgerät unter Verwendung eines Satzes von Logikregeln und der gespeicherten Basislinien-Metadatenparameter, um zu ermitteln, ob es eine Anomalie im Verkehrsmuster auf einem oder mehreren der Netzwerkknoten des Kommunikationsnetzes gibt; und Durchführen einer Aktion zum Korrigieren der Anomalie im Verkehrsmuster, wenn eine Anomalie in dem Verkehrsmuster auf einem oder mehreren der Netzwerkknoten des Kommunikationsnetzes erkannt wird.
Verfahren nach Anspruch 13, wobei das Senden der erzeugten Metadaten das Senden der erzeugten Metadaten von den zwei oder mehr der mehreren Netzwerkknoten zur Analyse-Engine über die Kommunikationsverbindung beinhaltet.
Verfahren nach Anspruch 13 oder 14, das ferner das Erkennen einer Konfigurationsänderung an der Konfiguration des Kommunikationsnetzes und das Senden einer Notiz über eine erkannte Konfigurationsänderung zur Analyse-Engine beinhaltet; insbesondere das ferner das Ändern von einer der Logikregeln beinhaltet, die zum Analysieren der gespeicherten Metadaten auf der Basis der erkannten Konfigurationsänderung verwendet werden und/oder das ferner das Kommunizieren eines Typs der erkannten Konfigurationsänderung zu der Analyse-Engine und das Ändern von einer der Logikregeln beinhaltet, die zum Analysieren der gespeicherten Metadaten auf der Basis des Konfigurationsänderungstyps benutzt werden und/oder das ferner, als Reaktion auf die Erkennung einer Konfigurationsänderung, das Sammeln eines neuen Satzes von Metadaten auf der Basis des Betriebs des Kommunikationsnetzes nach der Konfigurationsänderung und das Erzeugen eines neuen Satzes von Basislinien-Metadatenparametern von dem neuen Satz von Metadaten zur Verwendung durch die Analyse-Engine beim Analysieren von Metadaten von einem oder mehreren der Netzwerkknoten des Kommunikationsnetzes beinhaltet.
Verfahren nach einem der Ansprüche 13 bis 15, das ferner das Ausführen des Analyseschritts auf einem Prozessor eines Computergeräts beinhaltet, das direkt mit der Kommunikationsverbindung des Kommunikationsnetzes verbunden ist und/oder wobei das Durchführen einer Aktion zum Korrigieren der erkannten Anomalie das Senden einer Notiz zu einem Benutzer der erkannten Anomalie beinhaltet und/oder wobei das Durchführen einer Aktion zum Korrigieren der erkannten Anomalie das Verhindern beinhaltet, dass einer der Netzwerkknoten des Kommunikationsnetzes auf der Kommunikationsverbindung kommuniziert und/oder dass einer der Netzwerkknoten des Kommunikationsnetzes es zulässt, dass eine bestimmte Anwendung auf der Kommunikationsverbindung kommuniziert und/oder dass einer der Netzwerkknoten des Kommunikationsnetzes bestimmte Nachrichtentypen auf der Kommunikationsverbindung kommuniziert und/oder wobei das Analysieren von Nachrichtenverkehr auf einem der zwei oder mehr der Netzwerkknoten das Analysieren von Nachrichtenverkehr auf jedem aus einer Vielzahl von Subknoten des einen der zwei oder mehr der mehreren Netzwerkknoten und das Erzeugen von Metadaten für den Nachrichtenverkehr auf jedem der Vielzahl von Subknoten beinhaltet.