DE102019210229A1

DE102019210229A1 - Verfahren und Vorrichtung zur Analyse dienste-orientierter Kommunikation

Info

Publication number: DE102019210229A1
Application number: DE102019210229.8A
Authority: DE
Inventors: Jens Gramm; Andreas Weber; Janin Wolfinger; Michael Herrmann
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2019-07-10
Filing date: 2019-07-10
Publication date: 2021-01-14
Also published as: US20210014340A1; CN112217781A; US11533388B2

Abstract

Vorrichtung und Verfahren zur Analyse dienste-orientierter Kommunikation in einem Kommunikationsnetz, wobei ein Datenpaket einen ersten Header einer Anwendungsschicht (216) für dienste-orientierter Kommunikation umfasst, und das einen zweiten Header einer von der Anwendungsschicht verschiedenen Protokollschicht (218) für Kommunikation im Kommunikationsnetz insbesondere einen zweiten Header einer Darstellungsschicht (204), einer Sitzungsschicht (206), einer Transportschicht (208), einer Vermittlungsschicht (210), einer Sicherungsschicht (212) oder einer Bitübertragungsschicht (214) umfasst, wobei für das Datenpaket abhängig von Information über einen Sender und/oder Empfänger des Datenpakets aus dem ersten Header und abhängig von Information über einen Sender und/oder Empfänger aus dem zweiten Header analysiert wird, ob das Datenpaket ein Kriterium erfüllt oder nicht, wobei das Kriterium einen Sollwert für den Sender und/oder Empfänger im ersten Header abhängig vom Inhalt des zweiten Headers definiert, und/oder wobei das Kriterium einen Sollwert für den Sender und/oder Empfänger im zweiten Header abhängig vom Inhalt des ersten Headers definiert.

Description

Stand der Technik
Die Erfindung geht aus von einem Verfahren und einer Vorrichtung zur Analyse dienste-orientierter Kommunikation insbesondere in einem Kommunikationsnetz eines Fahrzeugs, beispielsweise eines Automotive-Ethernet-Netzwerks.
Dienste-orientierte Kommunikation verwendet dienste-orientierte Kommunikationsprotokolle und eine dienste-orientierte Netzwerkarchitektur, die mit einer dienste-orientierten Middleware realisiert wird.
Eine effektive Analyse der dienste-orientierten Kommunikation ist insbesondere für eine Erkennung von Angriffen auf das Kommunikationsnetz wünschenswert.
Offenbarung der Erfindung
Dies wird durch den Gegenstand der unabhängigen Ansprüche erreicht.
Ein Verfahren zur Analyse dienste-orientierter Kommunikation in einem Kommunikationsnetz sieht vor, dass ein Datenpaket einen ersten Header einer Anwendungsschicht für dienste-orientierte Kommunikation umfasst, und das einen zweiten Header einer von der Anwendungsschicht verschiedenen Protokollschicht für Kommunikation im Kommunikationsnetz, insbesondere einen zweiten Header einer Darstellungsschicht, einer Sitzungsschicht, einer Transportschicht, einer Vermittlungsschicht, einer Sicherungsschicht oder einer Bitübertragungsschicht, umfasst, wobei für das Datenpaket abhängig von Information über einen Sender und/oder Empfänger des Datenpakets aus dem ersten Header und abhängig von Information über einen Sender und/oder Empfänger aus dem zweiten Header analysiert wird, ob das Datenpaket ein Kriterium erfüllt oder nicht, wobei das Kriterium einen Sollwert für den Sender und/oder Empfänger im ersten Header abhängig vom Inhalt des zweiten Headers definiert, und/oder wobei das Kriterium einen Sollwert für den Sender und/oder Empfänger im zweiten Header abhängig vom Inhalt des ersten Headers definiert. Diese Analyse ermöglicht es, ein besonders effektives NIDPS für ein Automotive-Netzwerk bereitzustellen. Diese Analyse der dienste-orientieren Kommunikation erfolgt insbesondere für eine Angriffserkennung im Kommunikationsnetz. Die Angriffserkennung erfolgt beispielsweise durch ein „Network Intrusion Detection and Prevention System“ (NIDPS). Das NIDPS ermöglicht das Identifizieren von und das Reagieren auf Anomalien im Netzwerkverkehr eines verteilten Computersystems, das über das Kommunikationsnetz kommuniziert. Unter NIDPS sind Systeme zu verstehen, die typischerweise eingesetzt werden, um Angriffe auf Unternehmensnetzwerke, sogenannte Enterprise-Netzwerke, zu detektieren und zu verhindern. NIDPS können auch in Automotive-Netzwerken eingesetzt werden. Automotive-Netzwerke sind interne Netzwerke von Fahrzeugen mit „Electronic Control Units“ (ECUs) als Netzwerkknoten.
Vorzugsweise definiert der Sollwert wenigstens einen registrierten Endpunkt, wobei abhängig vom Inhalt der Header geprüft wird, ob das Datenpaket von einem registrierten Endpunkt versendet wird und/oder ob das Datenpaket an einen registrierten Endpunkt versendet wird. Dies ermöglicht es, Datenpakete als auffällige Datenpakete zu erkennen, wenn entweder der Sender oder der Empfänger nicht registrierte Endpunkte sind. Der andere Endpunkt der Kommunikation muss nicht registriert sein. Dies ermöglicht registrierten Endpunkten eine Kommunikation mit einem zuvor nicht registrierten Endpunkt.
Vorzugsweise definiert der Sollwert registrierte Endpunkte, wobei abhängig vom Inhalt der Header geprüft wird, ob das Datenpaket zwischen für die dienste-orientierte Kommunikation registrierten Endpunkten ausgetauscht wird. Dies ermöglicht es, Datenpakete als auffällige Datenpakete zu erkennen, wenn dies nicht zwischen registrierten Endpunkten versendet werden.
Vorzugsweise definiert der Sollwert wenigstens einen registrierten Endpunkt, wobei das Datenpaket eine Identifikation eines Service umfasst, wobei für einen Sender-Endpunkt des Datenpakets geprüft wird, ob dieser dem im Datenpaket ausgewiesenen Dienstanbieter, ausgewiesen durch seine Identifikation des Service, entspricht, und für einen Empfänger-Endpunkt des Datenpakets geprüft wird, ob dieser dem im Datenpaket ausgewiesenen Dienstnehmer, ausgewiesen durch seine Identifikation des Client, entspricht. Diese Information stellt eine weitere besonders gute Information für die Erkennung auffälliger Datenpakete dar.
Vorzugsweise definiert der Sollwert wenigstens einen registrierten Endpunkt (102, 104) definiert, wobei das Datenpaket eine Identifikation eines Client umfasst, wobei für einen Sender-Endpunkt (102, 104) des Datenpakets geprüft wird (606), ob dieser dem im Datenpaket ausgewiesenen Dienstnehmer, ausgewiesen durch seine Identifikation des Client, entspricht, und für einen Empfänger-Endpunkt (102, 104) des Datenpakets geprüft wird (606), ob dieser dem im Datenpaket ausgewiesenen Dienstanbieter, ausgewiesen durch seine Identifikation des Service, entspricht.
Vorzugsweise definiert der Sollwert registrierte Endpunkte, wobei das Datenpaket eine Identifikation eines Service und eine Identifikation eines Clients umfasst, wobei überprüft wird, ob das Datenpaket zwischen Endpunkten ausgetauscht wird, die für die im Datenpaket ausgewiesene Identifikation des Service und Identifikation des Client registriert sind, insbesondere wobei geprüft wird, ob Sender-Endpunkt und Empfänger-Endpunkt des Datenpakets eine registrierte Kombination bilden. Die registrierte Kombination stellt eine weitere besonders gute Information für die Erkennung auffälliger Datenpakete dar.
Vorzugsweise umfasst das Datenpaket Information über einen Nachrichten-Typ, wobei geprüft wird, ob das Datenpaket zwischen Dienstnehmer und Dienstanbieter in einer dem Nachrichten-Typ entsprechenden Richtung ausgetauscht wird und/oder wobei abhängig von Information über einen Sender-Endpunkt und/oder einen Empfänger-Endpunkt des Datenpakets eine Richtung definiert ist, wobei geprüft wird, ob das Datenpaket zwischen Dienstnehmer und Dienstanbieter in dieser Richtung ausgetauscht wird. Die Richtung stellt eine weitere besonders gute Information für die Erkennung auffälliger Datenpakete dar.
Vorzugsweise wird während einer Service Discovery-Phase geprüft, ob für ein Datenpaket, mit dem Information über einen Endpunkt übermittelt wird, der einen Service anbietet, dieser Endpunkt ein als Dienstanbieter registrierter Endpunkt ist und/oder ein für diesen Service als Dienstanbieter registrierter Endpunkt ist. Damit sind bereits in dieser Phase auffällige Datenpakete erkennbar.
Vorzugsweise wird während einer Service Discovery-Phase geprüft, ob für ein Datenpaket, mit dem Information über einen Endpunkt übermittelt wird, der einen Service anfragt, dieser Endpunkt ein als Dienstnehmer registrierter Endpunkt ist und/oder ein für diesen Service als Dienstnehmer registrierter Endpunkt ist. Damit sind für bestimmte Services bereits in dieser Phase auffällige Datenpakete noch zuverlässiger erkennbar.
Vorzugsweise wird eine Anomalie oder ein Angriff auf das Kommunikationsnetz erkannt, wenn das Kriterium nicht erfüllt ist. Dies stellt eine zuverlässige Erkennung der Anomalie oder des Angriffs abhängig von kommunikationsschichtübergreifender Information aus dem Datenpaket dar.
Vorzugsweise wird vor einer Überprüfung des Kriteriums geprüft, ob das Datenpaket zu einer dienste-orientierten Kommunikation gehört, wobei die Überprüfung des Kriteriums ausgeführt wird, wenn das Datenpaket zu einer dienste-orientierten Kommunikation gehört und anderenfalls unterbleibt. Damit werden nur relevante Datenpakete analysiert.
Eine Vorrichtung zur Analyse dienste-orientierter Kommunikation in einem Kommunikationsnetz umfasst eine Analyseeinrichtung, die in einem Verbindungselement, insbesondere einen Automotive-Ethernet-Switch, zur Verbindung von Datenleitungen im Kommunikationsnetz für die Übermittlung von Datenpaketen angeordnet oder mit diesem Verbindungselement zur Kommunikation verbunden oder verbindbar ist, wobei die Analyseeinrichtung ausgebildet ist, das Verfahren auszuführen. Damit ist eine Analyse und eine Anomalieerkennung in einem Automotive-Netzwerk effektiv möglich.
Weitere vorteilhafte Ausführungsformen ergeben sich aus der folgenden Beschreibung und der Zeichnung. In der Zeichnung zeigt:

1 eine schematische Darstellung eines Kommunikationsnetzes,
2 eine schematische Darstellung von Protokollschichten für das Kommunikationsnetz,
3 einen SOME/IP Header,
4 ein SOME/IP-SD Paket,
5 eine SOME/IP IPv4 Endpunkt Option,
6 Schritte in einem Verfahren zur Analyse dienste-orientierter Kommunikation im Kommunikationsnetz.

Um ein NIDPS für ein Automotive-Netzwerk bereitzustellen, sind Unterschiede von Automotive- zu Enterprise-Netzwerken zu berücksichtigen. Diese sind beispielsweise deren Netzwerkstruktur, Netzwerkdynamik und deren Netzwerkknoten.
Netzwerkstruktur:
Ein Enterprise-Netzwerk folgt typischerweise einem Client-Server-Modell, in dem es eine kleinere Anzahl an dedizierten Server-Netzwerkknoten gibt, die Dienste an eine typischerweise höhere Anzahl an Client-Netzwerkknoten anbieten. Automotive-Netzwerke bestehen aus ECUs, auf denen sowohl Server- wie auch Client-Applikationen ausgeführt werden.
Enterprise-Netzwerke sind im Allgemeinen wesentlich größer und komplexer als Automotive-Netzwerke. Die Gesamtheit eines Enterprise-Netzwerks ist typischerweise wesentlich segmentierter, physisch oder logisch separiert in verschiedene Zonen und Sub-Netzwerke. ECUs in typischen Automotive-Netzwerken sind, falls überhaupt, durch sogenannte „Gateways“ nur in sehr wenige Teilnetzwerke separiert oder logisch auf Ethernet-Ebene über sogenannte „Virtual Local Area Networks“ (VLANs) getrennt.
Netzwerkdynamik:
Enterprise- und Automotive-Netzwerken unterscheiden sich in der Dynamik, mit der sich das Netzwerk verändert und betrieben wird.
In Enterprise-Netzwerken können Netzwerkknoten beliebig ausgetauscht werden. Für Veränderungen bei Server-Netzwerkknoten kann typischerweise noch eine Anpassung in der Konfiguration der Verteidigungssysteme, wie bspw. das NIDPS, durchgeführt werden. Dagegen sind solche Anpassungen bei Netzwerknoten, die Clients sind, nicht möglich. Dies liegt daran, dass Clients sich von wechselnden Standorten zum Netzwerk verbinden und häufig ausgetauscht werden. Weiterhin lässt sich nicht genau vorhersagen, welche Applikationen auf einem Client ausgeführt werden.
ECUs in Automotive Netzwerken werden, wenn überhaupt, sehr selten ausgetauscht und werden dann häufig auch nur durch eine identische Kopie ausgetauscht. Daher ist es sehr unwahrscheinlich, dass sich an der Funktionsweise des Netzwerks etwas ändert. In einem Automotive-Netzwerk sind die Netzwerkknoten durchweg bekannt. Ebenso sind die darauf jeweils laufenden Server- und Client-Applikationen wohldefiniert und Details über die Netzwerkkommunikation können vorgegeben sein.
In Enterprise-Netzwerken können Knoten von Außerhalb Verbindungen in ein Unternehmensnetzwerk hinein aufbauen. In einem Automotive-Netzwerk sind alle Kommunikationsknoten des Netzwerks Teil des internen Fahrzeugnetzwerks.
In Enterprise-Netzwerken können typischerweise verschiedene Benutzer den gleichen Client verwenden können. In ECUs von Automotive-Netzwerken gibt es keine Benutzer, sondern lediglich Server- und Client-Applikationen, die ihren Dienst verrichten.
Netzwerkknoten:
Hinsichtlich der Ressourcen sind die Netzwerkknoten eines Enterprise-Netzwerks im Allgemeinen um ein vielfaches ressourcenstärker - zum Beispiel in Bezug auf Speicher und Performanz - als ECUs eines Automotive-Netzwerks.
Hinsichtlich der Software sind in Enterprise-Netzwerken die Netzwerkknoten meist mit weit verbreiteten Standard-Betriebssystemen und Standard-Software ausgestattet, für die Security-Schwachstellen bekannt sind. Deshalb liegt ein Schwerpunkt von NIDPS-Systemen in Enterprise-Netzwerken darin, signaturbasiert zu erkennen, wenn versucht wird, bekannte Security-Schwachstellen auszunutzen. Die Netzwerkknoten in Automotive-Netzwerken sind oft mit weniger verbreiteter Software ausgestattet. Ein Großteil der Signaturen aus NIDPS-Systemen für Enterprise-Netzwerke ist nicht anwendbar, und es gibt keine größeren Datenbanken über spezifisch für Automotive-Netzwerke bekannte Schwachstellen.
Zwar ist die grundsätzliche Aufgabe eines NIDPS, d.h. Detektieren und Reagieren auf Anomalien im Netzwerkverkehr, bei Enterprise- und Automotive-Netzwerken gleich. Aus den oben genannten Punkten wird allerdings ersichtlich, dass sich die grundsätzliche Funktionsweise eines effizienten NIDPS für Automotive-Netzwerke grundsätzlich von der eines NIDPS für Enterprise-Netzwerke unterscheiden muss. Aufgrund dieser funktionalen Unterschiede zwischen Enterprise-Netzwerken und Automotive-Netzwerken lassen sich NIDPS für Enterprise-Netzwerke nicht effizient für Automotive-Netzwerke einsetzen.
Ein NIDPS für ein Automotive-Netzwerk muss sich die bekannte und statische Netzwerkstruktur sowie die wesentlich geringere Dynamik der Netzwerkteilnehmer zunutze machen, um Anomalien mit begrenzten Ressourcen effizient detektieren zu können.
Im Folgenden werden Aspekte einer dienste-orientierte Architektur und Aspekte von dienste-orientierten Protokollen beschrieben. Eine dienste-orientierte Architektur auch bekannt als service-oriented architecture (SOA) ist ein Architekturmuster der Informationstechnik aus dem Bereich der verteilten Systeme, um Dienste von IT Systemen zu strukturieren und zu nutzen. Typischerweise läuft die Interaktion zwischen einem Dienstanbieter („Service“) und einem Dienstnehmer („Client“) im Netzwerk nach folgendem Muster ab:

1) Ein Dienstanbieter veröffentlicht oder registriert seinen Dienst.
2) Die Softwarekomponente, die einen Dienst benutzen möchte, sucht ihn in einem Verzeichnis.

Wird ein passender Dienst gefunden, kann zum nächsten Schritt übergegangen werden.

3) Die benutzende Komponente erhält vom Verzeichnis eine Referenz (Adresse), unter der sie auf den Dienst zugreifen kann. Der Funktionsaufruf wird an diese Adresse gebunden.
4) Der Dienst wird aufgerufen. Eingabeparameter werden an den Dienst übermittelt und Ausgabeparameter als Antwort auf den Aufruf zurückgeliefert.

Die Schritte 1) bis 3) dienen dazu, mit Hilfe eines zentralen Verzeichnisses angebotene Services zu identifizieren und herauszufinden, wie sie angesprochen werden können. Dies wird auch als „Service Discovery“ bezeichnet. In manchen dienste-orientierten Protokollen wird „Service Discovery“ auch ohne zentrales Verzeichnis nach dem sogenannten „Publish/Subscibe“-Muster umgesetzt, indem Komponenten ihre angebotenen Dienste per Multicast annoncieren („publish“) und Dienstnehmer sich, wenn nötig, für bestimmte Dienste registrieren („subscribe“).
Im Allgemeinen existieren Identifier, um in Datenpaketen der dienste-orientierten Kommunikation auf einzelne Dienstanbieter und Dienstnehmer zu verweisen. Diese Identifier werden im Folgenden mit „Service ID“ für Dienstanbieter oder „Client ID“ für Dienstnehmer bezeichnet. In spezifischen dienste-orientierten Kommunikationsprotokollen können auch andere Bezeichnungen dafür verwendet werden. Im Allgemeinen existieren auch Identifier, um einen Nachrichten-Typ eines Daten-Pakets zu bezeichnen. Im Folgenden wird dieser Identifier mit „Message Type“ bezeichnet. Zum Beispiel wird mit dem Nachrichten-Typ „Request“ eine Anfrage eines Dienstnehmers an einen Dienstanbieter bezeichnet und mit dem Nachrichten-Typ „Response“ wird die Antwort eines Dienstanbieters an einen Dienstnehmer bezeichnet.
Middleware, die eine dienste-orientierte Kommunikationsinfrastruktur realisieren, sind beispielsweise die Scalable Service-Oriented Middleware over IP (SOME/IP) oder die Data Distribution Service (DDS). Beide werden im Automobilbereich eingesetzt.
Diese Middlewares definieren entsprechende Kommunikationsprotokolle, die die Art und Weise spezifizieren, wie Daten innerhalb der dienste-orientierten Middlewares ausgetauscht werden. Für SOME/IP spricht man hier allgemeinhin vom SOME/IP-Protokoll.
1 stellt eine schematische Darstellung eines Kommunikationsnetzes 100 dar. Das Kommunikationsnetz 100 umfasst einen ersten Endpunkt 102 einer Kommunikationsbeziehung und einen zweiten Endpunkt 104 einer Kommunikationsbeziehung. Der erste Endpunkt 102 und der zweite Endpunkt 104 sind über ein Verbindungselement 106, insbesondere einen Automotive-Ethernet-Switch, verbunden. Im Beispiel werden Daten in der Kommunikationsbeziehung über Frames ausgetauscht. Das Verbindungselement 106 ist ausgebildet, einen Frame zu empfangen und anhand von Informationen aus dem Frame weiterzuleiten. Das Kommunikationsnetz 100 ist im Beispiel ein Automotive-Ethernet-Netzwerk. Die Information aus dem Frame ist im Beispiel Information aus der Sicherungsschicht des OSl-Modells. Die Endpunkte können Steuergeräte in einem Fahrzeug sein, die über das Automotive-Ethernet-Netzwerk kommunizieren. Das Kommunikationsnetz 100 umfasst eine Analyseeinrichtung 108. Die Analyseeinrichtung 108 umfasst beispielsweise ein NIDPS. Die Analyseeinrichtung 108 ist beispielweise im Automotive-Ethernet-Switch angeordnet. In 1 wird die Analyse in einem Verbindungselement 106 der Kommunikation dargestellt. Die Analyse kann stattdessen oder zusätzlich auch auf einem Endpunkt der Kommunikation, beispielsweise dem ersten Endpunkt 102 oder dem zweiten Endpunkt 104 stattfinden. Ein Teil der Analyseeinrichtung 108 oder die Analyseeinrichtung 108 insgesamt kann auch außerhalb des Verbindungselements 106 angeordnet und mit dem Kommunikationsnetz 100 oder dem Verbindungselement 106 über eine separate Schnittstelle oder über das Kommunikationsnetz 100 verbunden oder verbindbar sein. Im Beispiel sind Datenleitungen 110 zur Verbindung im Kommunikationsnetz 100 angeordnet. Es können auch zumindest teilweise drahtlose Verbindungen vorgesehen sein.
Der erste Endpunkt 102 und der zweite Endpunkt 104 sind im Beispiel registrierte Endpunkte. Die registrierten Endpunkte sind beispielsweise in einer Tabelle in der Analyseeinrichtung 108 gespeichert. Die Tabelle kann abhängig von einer Auslegung des Kommunikationsnetz 100 oder einer Definition von im Fahrzeug verfügbaren Dienstanbietern und Dienstnehmern statisch gespeichert sein. Es kann auch eine Datenbank dafür eingesetzt werden. Die registrierten Endpunkte können auch in einem Betrieb des Kommunikationsnetzwerks 100 gelernt und abgespeichert werden. Der erste Endpunkt 102 und der zweite Endpunkt 104 können sowohl Sender-Endpunkt als auch Empfänger-Endpunkt in der dienste-orientierten Kommunikation sein. Der erste Endpunkt 102 und der zweite Endpunkt 104 können sowohl Dienstanbieter als auch Dienstnehmer in der dienste-orientierten Kommunikation sein. Es können auch eine registrierte Kombination oder mehrere registrierte Kombinationen einander für die dienste-orientierte Kommunikation zugeordneter Endpunkte vorgesehen oder abgespeichert sein. Es kann auch eine Richtung für eine dienste-orientierte Kommunikation für eine derartige Kombination oder für einzelne registrierte Endpunkte vorgegeben oder gespeichert sein.
In 2 sind Protokollschichten für das Kommunikationsnetz nach dem OSI-Modell dargestellt. Nach dem OSl-Modell sind unter einer Anwendungsschicht 202 eine Darstellungsschicht 204, eine Sitzungsschicht 206, eine Transportschicht 208, eine Vermittlungsschicht 210, eine Sicherungsschicht 212 und eine Bitübertragungsschicht 214 angeordnet.
Die im Folgenden als dienste-orientierte Kommunikationsprotokolle bezeichneten Protokolle sind demgegenüber als Anwendungen 216 zusammengefasst. Beispiele für Anwendungen 216 sind HTTP, UDS, FTP, SMTP, POP, Telnet, DHCP, OPC UA, SOCKS, SOME/IP, DDS. Mit darunterliegenden Protokollen 218 sind die anderen Protokolle bezeichnet. Beispiele für darunter liegende Protokolle 218 sind TCP, UDP, SCTP, IP (IPv4, IPv6), ICMP, Ethernet, Token Bus, Token Ring, FDDI.
In der folgenden Beschreibung wird eine Funktionsweise am Beispiel von SOME/IP beschrieben. Diese Funktionsweise ist auf andere dienste-orientierte Kommunikationsprotokolle, wie DDS, entsprechend anwendbar.
SOME/IP definiert neben dem eigentlichen Kommunikationsprotokoll einen eigenen Mechanismus zur Service Discovery, also um Dienste zur Laufzeit zu finden und zu verwalten. SOME/IP spezifiziert dazu neben dem SOME/IP Protokoll das SOME/IP Service Discovery (SOME/IP-SD) Protokoll. Über SOME/IP-SD wird z.B. übertragen, welchen der Endpunkte ein SOME/IP Service oder ein SOME/IP Client verwendet. Dadurch kann ein SOME/IP Client einen SOME/IP Service finden und umgekehrt. Dadurch ist eine Kommunikation zwischen SOME/IP Service und SOME/IP Client und umgekehrt möglich.
In 3 ist ein SOME/IP Header dargestellt. In 4 ist ein SOME/IP-SD Paket dargestellt. In 5 ist eine SOME/IP-SD IPv4 Endpunkt Option dargestellt.
Die Überprüfung der Funktionsweise einer auf SOME/IP basierenden dienste-orientierten Middleware erfolgt wie im Folgenden beschrieben mit Informationen von Protokollen, die typischerweise unter dem Protokoll liegen, das die dienste-orientierte Kommunikation im Kommunikationsnetz 100 realisiert.
In einem Datenpaket service-orientierter Kommunikation werden beispielsweise in den Headern der darunterliegenden Protokollschichten sogenannte „Endpunkte“ der Kommunikation identifiziert. Diese werden beispielsweise anhand ihrer MAC-Adresse, IP-Adresse oder Port-Nummer identifiziert.
Vorzugsweise sind die Endpunkte der Kommunikationsbeziehungen in einem bestimmten Fahrzeug, dessen Kommunikation analysiert wird, statisch und im Voraus definiert. In diesem Fall wird dem NIDPS die folgende Information oder eine Teilmenge davon als „Systemwissen“ zur Verfügung gestellt:

- Ports der Transportschicht, die für dienste-orientierte Kommunikation verwendet werden.
- Registrierte Endpunkte, die von Dienstanbietern („Services“) und die von Dienstnehmern („Clients“) verwendet werden.
- Registrierte Identifier für Dienstanbieter - „Service ID“ - und für Dienstnehmer - „Client ID“.
- Für jede „Service ID“ eine Liste von registrierten Endpunkten, die den durch „Service ID“ bezeichneten Dienst anbieten dürfen.
- Für jede „Client ID“ eine Liste von registrierten Endpunkten, die den durch „Client ID“ bezeichneten Dienst in Anspruch nehmen dürfen.
- Registrierte Kombinationen von Dienstnehmern und Dienstanbietern:
- registrierte Kombinationen von „Client ID“ und „Service ID“ und/oder registrierte Kombinationen von Endpunkten, d.h. welcher Endpunkt Dienstnehmer (Client) für welchen Dienstanbieter (Service) sein darf.

Ein Verfahren zur Analyse für die Anomalie-Erkennung wird anhand der 6 beschrieben. Eine Identifikation eines Service, d.h. eines Dienstes, der in der dienste-orientierten Kommunikation angeboten wird, wird im Folgenden mit „Service ID“ bezeichnet. Eine Identifikation eines Clients, d.h. eines Dienstnehmers eines Dienstes, der in der dienste-orientierten Kommunikation angeboten wird, wird im Folgenden mit „Client ID“ bezeichnet.
Das Verfahren startet beispielsweise, wenn das NIDPS ein Datenpaket erhält. Vorzugsweise werden die im Datenpaket enthaltenen Header nacheinander analysiert. Es kann auch eine Analyse eines bestimmten Headers oder mehrerer bestimmter Header durchgeführt werden.
In einem Schritt 602 wird geprüft, ob das Datenpaket zu einer dienste-orientierten Kommunikation gehört. Falls dies der Fall ist wird eine Schritt 604 ausgeführt. Anderenfalls wird das Verfahren beendet.
Im Schritt 604 wird vom NIDPS geprüft, ob das Datenpaket zwischen registrierten Endpunkten ausgetauscht wird.
Vorzugsweise prüft das NIDPS, ob das Datenpaket von einem registrierten Endpunkt versendet wird. Vorzugsweise prüft das NIDPS, ob das Datenpaket an einen registrierten Endpunkt versendet wird.
Wenn das Datenpaket zwischen registrierten Endpunkten versendet wird, wird ein Schritt 606 ausgeführt. Anderenfalls wird ein Schritt 616 ausgeführt.
Im Schritt 606 wird vom NIDPS geprüft, ob das Datenpaket zwischen Endpunkten ausgetauscht wird, die für die im Datenpaket ausgewiesenen „Service ID“ oder „Client ID“ registriert sind.
Vorzugsweise prüft das NIDPS für Sender-Endpunkt und Empfänger-Endpunkt des Datenpakets, ob sie entweder dem im Datenpaket ausgewiesenen Dienstanbieter, ausgewiesen durch seine „Service ID“, oder dem in der Nachricht ausgewiesenen Dienstnehmer, ausgewiesen durch seine „Client ID“, entsprechen. Vorzugsweise prüft das NIDPS, ob Sender-Endpunkt und Empfänger-Endpunkt des Datenpakets eine registrierte Kombination bilden.
Wenn das Datenpaket zwischen Endpunkten ausgetauscht wird, die für die im Datenpaket ausgewiesenen „Service ID“ oder „Client ID“ registriert sind, wird ein Schritt 608 ausgeführt. Anderenfalls wird der Schritt 616 ausgeführt.
Im Schritt 608 wird vom NIDPS anhand der Endpunkte geprüft, ob das Datenpaket zwischen Dienstnehmer und Dienstanbieter in der dem Nachrichten-Typ entsprechenden Richtung ausgetauscht wird.
Für ein Datenpaket wird vorzugsweise geprüft, ob es in der dem Nachrichten-Typ entsprechenden Richtung zwischen Dienstnehmer und Dienstanbieter verschickt wird. Für SOME/IP ist diese Information aus dem SOME/IP Header alleine nicht zu extrahieren. Wie in 3 ersichtlich, enthält der SOME/IP Header keine Information darüber, ob das Datenpaket von einem SOME/IP Service zu einem SOME/IP Client verschickt wird oder umgekehrt. Die Analyse des Sender- und des Empfänger-Endpunktes erlaubt hingegen eine solche Analyse. Dies erlaubt dem NIDPS zu überprüfen, ob ein bestimmter Endpunkt wie vorgesehen als Client oder als Service interagiert.
Wenn das Datenpaket zwischen Dienstnehmer und Dienstanbieter in der dem Nachrichten-Typ entsprechenden Richtung ausgetauscht wird, wird ein Schritt 610 ausgeführt. Anderenfalls wird der Schritt 616 ausgeführt.
Im Schritt 610 wird vom NIDPS geprüft, ob die Endpunkte, die während der „Service Discovery“-Phase als Endpunkte von Services übermittelt werden, registrierte Endpunkte für Services sind.
Beispielsweise wird Informationen in SOME/IP-SD Paketen überprüft. Wie in 4 dargestellt, besteht ein SOME/IP-SD Paket aus einem Header, einem sogenannten „Entries Array“ und „Options Array“. 5 zeigt einen Eintrag im „Options Array“, in dem ein IPv4-Endpunkt, also eine IPv4 Adresse, eine Port Nummer sowie eine Information über das verwendete Transportprotokoll, übermittelt wird. Dies erlaubt dem NIDPS zu überprüfen, dass nur Endpunkte, die auch für eine SOME/IP-Kommunikation vorhergesehen sind, in SOME/IP-SD-Paketen als Endpunkte übertragen werden.
Wenn die Endpunkte, die während der „Service Discovery“-Phase als Endpunkte von Services übermittelt werden, registrierte Endpunkte für Services sind, wird ein Schritt 612 ausgeführt. Anderenfalls wird der Schritt 616 ausgeführt.
Im Schritt 612 wird vom NIDPS geprüft, ob Informationen über Endpunkte, die während der „Service Discovery“-Phase übermittelt werden, registrierte Endpunkte für entweder die relevante „Service ID“ oder die relevante „Client ID“ sind.
Diese Prüfung berücksichtigt vorzugsweise, dass sowohl Dienste einer speziellen „Service ID“ in „publish“-Nachrichten sowie Dienstnehmer einer speziellen „Client ID“ in „subscribe“-Nachrichten ihre Endpunkte in verschiedenen „Service Discovery“ Nachrichten mitteilen.
Wenn Informationen über Endpunkte, die während der „Service Discovery“-Phase übermittelt werden, registrierte Endpunkte für entweder die relevante „Service ID“ oder die relevante „Client ID“ sind, wird ein Schritt 614 ausgeführt. Anderenfalls wird der Schritt 616 ausgeführt.
Im Schritt 614 wird als Ergebnis der Analyse des Datenpaket festgestellt, dass kein Angriff auf das Kommunikationsnetz 100 identifiziert wurde. Diese Information wird vorzugsweise ausgegeben.
Anschließend endet das Verfahren für dieses Datenpaket. Für weitere Datenpakete wird ebenso verfahren.
Im Schritt 616 wird als Ergebnis der Analyse des Datenpaket festgestellt, dass ein Angriff auf das Kommunikationsnetz 100 vorliegt. Diese Information wird vorzugsweise ausgegeben.
Anschließend endet das Verfahren für dieses Datenpaket. Für weitere Datenpakete wird ebenso verfahren.
Die beschriebenen Schritte können in dieser oder einer anderen Reihenfolge ausgeführt werden. Es müssen nicht für jedes Paket alle oder dieselben Schritte ausgeführt werden.
Mit dem Verfahren kann in einem Automotive-Ethernet-Netzwerk der Netzwerkverkehr an den vorhandenen Ethernet-Ports analysieren werden. Abhängig von der Analyse können Anomalien identifiziert werden, die durch einen Angreifer im Netzwerk verursacht werden. Diese Analyse läuft im Beispiel am Automotive-Ethernet-Switch ab, an dessen Hardware-Ports oder Switch-Ports die Datenpakete eintreffen. Die Analyse kann auch an einem beliebigen anderen Teilnehmer am Automotive-Ethernet-Netzwerk in einem Fahrzeug erfolgen. Es kann vorgesehen sein, auf im Automotive-Netzwerk Anomalien im Netzwerkverkehr zu identifizieren und auf diese Angriffe zu reagieren.
Aufgrund der Verwendung von Informationen der Protokolle, die, nach dem OSI-Modell, unter den Protokollen liegen, die eine dienste-orientierte Middleware realisieren, wird folgendes erreicht:

- Sicherstellung, dass Datenpakete nur von erlaubten Netzwerkteilnehmern versendet werden. Netzwerkteilnehmer können beispielsweise mit „Endpunkten“ identifiziert werden. Die Endpunkte werden z.B. durch IP-Adresse, Port-Nummer und Information, welches Transportprotokoll verwendet wird, identifiziert.
- Überprüfung, zwischen welchen Netzwerkteilnehmern Datenpakete innerhalb der dienste-orientierten Kommunikation ausgetauscht werden. Die ist insbesondere dann vorteilhaft, wenn diese Information aus dem Datenpaket eines dienste-orientierten Kommunikationsprotokolls nicht notwendigerweise verfügbar ist.
- Überprüfung, dass nur erlaubte Endpunkte während der Findungsphase, der sogenannten „Service Discovery“, eines dienste-orientierten Kommunikationsprotokolls an Netzwerkteilnehmer kommuniziert werden.

Claims

Verfahren zur Analyse dienste-orientierter Kommunikation in einem Kommunikationsnetz (100), dadurch gekennzeichnet, dass ein Datenpaket einen ersten Header einer Anwendungsschicht (216) für dienste-orientierte Kommunikation umfasst, und das einen zweiten Header einer von der Anwendungsschicht verschiedenen Protokollschicht (218) für Kommunikation im Kommunikationsnetz (100), insbesondere einen zweiten Header einer Darstellungsschicht (204), einer Sitzungsschicht (206), einer Transportschicht (208), einer Vermittlungsschicht (210), einer Sicherungsschicht (212) oder einer Bitübertragungsschicht (214), umfasst, wobei für das Datenpaket abhängig von Information über einen Sender und/oder Empfänger des Datenpakets aus dem ersten Header und abhängig von Information über einen Sender und/oder Empfänger aus dem zweiten Header analysiert wird, ob das Datenpaket ein Kriterium erfüllt oder nicht, wobei das Kriterium einen Sollwert für den Sender und/oder Empfänger im ersten Header abhängig vom Inhalt des zweiten Headers definiert, und/oder wobei das Kriterium einen Sollwert für den Sender und/oder Empfänger im zweiten Header abhängig vom Inhalt des ersten Headers definiert.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Sollwert wenigstens einen registrierten Endpunkt (102, 104) definiert, wobei abhängig vom Inhalt der Header geprüft wird (604), ob das Datenpaket von einem registrierten Endpunkt (102, 104) versendet wird und/oder ob das Datenpaket an einen registrierten Endpunkt (102, 104) versendet wird.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass der Sollwert registrierte Endpunkte (102, 104) definiert, wobei abhängig vom Inhalt der Header geprüft wird (604), ob das Datenpaket zwischen für die dienste-orientierte Kommunikation registrierten Endpunkten (102, 104) ausgetauscht wird.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass der Sollwert wenigstens einen registrierten Endpunkt (102, 104) definiert, wobei das Datenpaket eine Identifikation eines Service umfasst, wobei für einen Sender-Endpunkt (102, 104) des Datenpakets geprüft wird (606), ob dieser dem im Datenpaket ausgewiesenen Dienstanbieter, ausgewiesen durch seine Identifikation des Service entspricht, und für einen Empfänger-Endpunkt (102, 104) des Datenpakets geprüft wird (606), ob dieser dem im Datenpaket ausgewiesenen Dienstnehmer, ausgewiesen durch seine Identifikation des Client, entspricht.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass der Sollwert wenigstens einen registrierten Endpunkt (102, 104) definiert, wobei das Datenpaket eine Identifikation eines Client umfasst, wobei für einen Sender-Endpunkt (102, 104) des Datenpakets geprüft wird (606), ob dieser dem im Datenpaket ausgewiesenen Dienstnehmer, ausgewiesen durch seine Identifikation des Client, entspricht, und für einen Empfänger-Endpunkt (102, 104) des Datenpakets geprüft wird (606), ob dieser dem im Datenpaket ausgewiesenen Dienstanbieter, ausgewiesen durch seine Identifikation des Service, entspricht..
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass der Sollwert registrierte Endpunkte (102, 104) definiert, wobei das Datenpaket eine Identifikation eines Service und eine Identifikation eines Clients umfasst, wobei überprüft wird (606), ob das Datenpaket zwischen Endpunkten (102, 104) ausgetauscht wird, die für die im Datenpaket ausgewiesene Identifikation des Service und Identifikation des Client registriert sind, insbesondere wobei geprüft wird, ob Sender-Endpunkt (102, 104) und Empfänger-Endpunkt (102, 104) des Datenpakets eine registrierte Kombination bilden.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass das Datenpaket Information über einen Nachrichten-Typ umfasst, wobei geprüft wird (608), ob das Datenpaket zwischen Dienstnehmer und Dienstanbieter in einer dem Nachrichten-Typ entsprechenden Richtung ausgetauscht wird und/oder wobei abhängig von Information über einen Sender-Endpunkt (102, 104) und/oder einen Empfänger-Endpunkt (102, 104) des Datenpakets eine Richtung definiert ist, wobei geprüft wird (608), ob das Datenpaket zwischen Dienstnehmer und Dienstanbieter in dieser Richtung ausgetauscht wird.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass während einer Service Discovery-Phase geprüft wird, ob für ein Datenpaket, mit dem Information über einen Endpunkt (102, 104) übermittelt wird, der einen Service anbietet, dieser Endpunkt (102, 104) ein als Dienstanbieter registrierter Endpunkt (102, 104) ist (610) und/oder ein für diesen Service als Dienstanbieter registrierter Endpunkt (102, 104) ist (612).
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass während einer Service Discovery-Phase geprüft wird, ob für ein Datenpaket, mit dem Information über einen Endpunkt (102, 104) übermittelt wird, der einen Service anfragt, dieser Endpunkt (102, 104) ein als Dienstnehmer registrierter Endpunkt (102, 104) ist (610) und/oder ein für diesen Service als Dienstnehmer registrierter Endpunkt (102, 104) ist (612).
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass eine Anomalie oder ein Angriff auf das Kommunikationsnetz (100) erkannt wird, wenn das Kriterium nicht erfüllt ist.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass vor einer Überprüfung des Kriteriums geprüft wird (602), ob das Datenpaket zu einer dienste-orientierten Kommunikation gehört, wobei die Überprüfung des Kriteriums ausgeführt wird, wenn das Datenpaket zu einer dienste-orientierten Kommunikation gehört und anderenfalls unterbleibt.
Vorrichtung zur Analyse dienste-orientierter Kommunikation in einem Kommunikationsnetz (100), dadurch gekennzeichnet, dass die Vorrichtung eine Analyseeinrichtung (108) umfasst, die in einem Verbindungselement (106), insbesondere einen Automotive-Ethernet-Switch, zur Verbindung von Datenleitungen (110) im Kommunikationsnetz für die Übermittlung von Datenpaketen angeordnet oder mit diesem Verbindungselement (106) zur Kommunikation verbunden oder verbindbar ist, wobei die Analyseeinrichtung (108) ausgebildet ist, das Verfahren nach einem der Ansprüche 1 bis 10 auszuführen.
Computerprogramm, dadurch gekennzeichnet, dass das Computerprogramm computerlesbare Instruktionen umfasst, bei deren Ausführung durch einen Computer ein Verfahren nach einem der Ansprüche 1 bis 10 ausgeführt wird.
Computerprogrammprodukt, dadurch gekennzeichnet, dass das Computerprogrammprodukt eine computerlesbares Speichermedium umfasst, auf dem das Computerprogramm nach Anspruch 12 gespeichert ist.