Method and device for analyzing service-oriented communication

Abstract

The invention relates to a device and a method for analyzing service-oriented communication in a communication network, wherein a data packet comprises a first header of an application layer (216) for service-oriented communication and comprises a second header of a protocol layer (218) different from the application layer for communication in the communication network, in particular a second header of a presentation layer (204), a session layer (206), a transport layer (208), a network layer (210), a data link layer (212) or a physical layer (214), wherein the data packet is analyzed based on information about a sender and / or a receiver of the data packet from the first header and based on information about the sender and / or the receiver from the second header to determine whether the data packet meets a criterion, wherein the criterion defines a rated value for the sender and / or the receiver in the first header based on the content of the second header and / or wherein the criterion defines a rated value for the sender and / or the receiver in the second header based on the content of the first header.

Description

Technical Field

[0001] The present invention is based on a method and a device for analyzing service-oriented communications, in particular in a communication network of a vehicle, for example an automotive Ethernet network. Background Art

[0002] Service-oriented communication (dienste-orientierte Kommunikation) uses service-oriented communication protocols and a service-oriented network architecture implemented using service-oriented middleware.

[0003] In order to detect attacks on communication networks, an efficient analysis of service-oriented communications is particularly desirable. Summary of the invention

[0004] This is achieved by the subject matter of the independent claims.

[0005] A method for analyzing service-oriented communication in a communication network provides that a data packet includes a first header of an application layer for service-oriented communication, and a second header of a protocol layer different from the application layer for communication in the communication network, in particular a second header of a presentation layer, a session layer, a transport layer, a network layer, a data link layer or a physical layer, wherein the data packet is analyzed based on information about a sender and / or a receiver of the data packet from the first header and based on information about the sender and / or the receiver from the second header: whether the data packet meets a criterion, wherein the criterion defines a rated value for the sender and / or the receiver in the first header based on the content of the second header, and / or wherein the criterion defines a rated value for the sender and / or the receiver in the second header based on the content of the first header. This analysis enables a particularly effective NIDPS to be provided for a vehicle network. This analysis of service-oriented communication is particularly performed for attack identification in the communication network. Attack identification is performed, for example, by a "Network Intrusion Detection and Prevention System" (NIDPS). NIDPS enables the identification and reaction to anomalies in the network traffic of distributed computer systems communicating via a communication network. NIDPS can be understood as a system that is typically used to detect and prevent attacks on corporate networks, so-called enterprise networks. NIDPS can also be used in automotive networks. An automotive network is a vehicle's internal network with "electronic control units" (ECUs) as network nodes.

[0006] The rating preferably defines at least one registered endpoint, wherein it is checked based on the content of the header whether a data packet is sent by a registered endpoint and / or whether a data packet is sent to a registered endpoint. This enables a data packet to be identified as a strange data packet when the sender or receiver is an unregistered endpoint. The other endpoint of the communication does not have to be registered. This enables a registered endpoint to communicate with a previously unregistered endpoint.

[0007] The rating preferably defines registered endpoints, wherein it is checked based on the content of the header whether data packets are exchanged between endpoints registered for service-oriented communication. This enables data packets to be identified as peculiar data packets when they are not sent between registered endpoints.

[0008] The rating preferably defines at least one registered endpoint, wherein the data packet comprises a service identification, wherein for a sender endpoint of the data packet it is checked whether the sender endpoint corresponds to a service provider identified in the data packet, the service provider being identified by its service identification, and for a receiver endpoint of the data packet it is checked whether the receiver endpoint corresponds to a service user identified in the data packet, the service user being identified by its client identification. This information is another particularly good information for identifying unusual data packets.

[0009] The rating preferably defines at least one registered endpoint (102, 104), wherein the data packet comprises a client identification, wherein for a sender endpoint (102, 104) of the data packet, it is checked (606) whether the sender endpoint corresponds to a service user certified in the data packet, said service user being certified by its client identification, and for a receiver endpoint (102, 104) of the data packet, it is checked (606) whether the receiver endpoint corresponds to a service provider certified in the data packet, said service provider being certified by its service identification.

[0010] The rated value preferably defines a registered endpoint, wherein the data packet comprises a service identification and a client identification, wherein it is checked whether the data packet is exchanged between endpoints registered for the service identification and the client identification indicated in the data packet. In particular, it is checked whether the sender endpoint and the receiver endpoint of the data packet form a registered combination. The registered combination is another particularly good information for identifying unusual data packets.

[0011] The data packet preferably comprises information about the message type, wherein it is checked whether the data packet is exchanged between the service user and the service provider in a direction corresponding to the message type, and / or wherein the direction is defined based on information about the sender end point and / or the receiver end point of the data packet, wherein it is checked whether the data packet is exchanged between the service user and the service provider in this direction. The direction is another particularly good information for identifying unusual data packets.

[0012] During the service discovery phase, it is preferably checked whether the data packets with which the information about the endpoint providing the service is transmitted are the endpoint registered as a service provider and / or the endpoint registered as a service provider for the service. Thus, already in this phase, unusual data packets can be identified.

[0013] During the service discovery phase, it is preferably checked whether the data packet with which the information about the endpoint of the queried service is transmitted is an endpoint registered as a user of the service and / or is an endpoint registered as a user of the service for the service. Thus, for a specific service, already in this phase, it is possible to more reliably identify unusual data packets.

[0014] If this criterion is not met, an attack or an anomaly on the communication network is preferably detected. This means that the anomaly or attack is reliably detected based on cross-communication layer information from the data packets.

[0015] Before checking the criterion, it is preferably checked whether the data packet belongs to a service-oriented communication, wherein if the data packet belongs to a service-oriented communication, the criterion is checked, but otherwise not. Thus, only the relevant data packets are analyzed.

[0016] The device for analyzing service-oriented communication in a communication network comprises an analyzing device, which is arranged in a connecting element, in particular an automotive Ethernet switch, for connecting a data line in the communication network for transmitting data packets or is connected or connectable to the connecting element for communication, wherein the analyzing device is designed to implement the method. This effectively makes it possible to perform an analysis and detect anomalies in the automotive network. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Further advantageous embodiments are apparent from the following description and the accompanying drawings. In the drawings:

[0018] Figure 1 A schematic diagram showing a communication network,

[0019] Figure 2 a schematic diagram showing the protocol layers for a communication network,

[0020] Figure 3 Shows the SOME / IP header,

[0021] Figure 4 Shows SOME / IP-SD packet,

[0022] Figure 5 Shows the SOME / IP IPv4 endpoint options.

[0023] Figure 6 Steps in a method for analyzing service-oriented communication in a communication network are shown. DETAILED DESCRIPTION

[0024] In order to provide NIDPS for a vehicle network, the differences between a vehicle network and an enterprise network may be taken into account, such as their network structure, network dynamics and their network nodes.

[0025] Network structure:

[0026] Enterprise networks typically follow a client-server model, where there are a relatively small number of dedicated server network nodes that provide services to a typically higher number of client network nodes. Automobile networks consist of ECUs on which both server and client applications are executed.

[0027] Enterprise networks are usually much larger and more complex than automotive networks. Typically, the enterprise network as a whole is significantly more segmented, physically or logically separated into different zones and subnetworks. The ECUs in a typical automotive network are only separated into very few subnetworks, if at all, via so-called "gateways" or logically separated at the Ethernet level via so-called "Virtual Local Area Networks" (VLANs).

[0028] Network dynamics:

[0029] Enterprise networks and vehicle networks differ in terms of the dynamics with which the networks are changed and operated.

[0030] In an enterprise network, network nodes can be replaced at will. For changes in the case of server network nodes, adaptation can typically also be performed in the configuration of the defense system, such as NIDPS. On the contrary, such adaptation is impossible in the case of client network nodes. This is because the client is connected to the network from an unfixed position and is often replaced. In addition, it is not possible to accurately predict which applications are executed on the client.

[0031] ECUs in a car network are only rarely replaced, if at all, and are therefore often replaced only with identical copies. It is therefore very unlikely that changes will occur in the way the network functions. In a car network, the network nodes are completely known. The server applications and client applications that run on them are also well defined and can predetermine the details regarding the network communication.

[0032] In an enterprise network, nodes can establish connections to the enterprise network from the outside. In a car network, all communication nodes of the network are part of the internal vehicle network.

[0033] In an enterprise network, different users may typically be able to use the same client. In the ECU of a car network there are no users, but only server applications and client applications that implement their services.

[0034] Network Nodes:

[0035] With regard to resources, the network nodes of an enterprise network are often many times more resource-intensive (eg with regard to memory and performance) than the ECUs of an automotive network.

[0036] Regarding software, in enterprise networks, network nodes are mostly equipped with widely popular standard operating systems and standard software for which security vulnerabilities are known. Therefore, the focus of NIDPS systems in enterprise networks is to identify based on signatures when trying to fully exploit known security vulnerabilities. Network nodes in automotive networks are often equipped with less popular software. Most of the signatures from NIDPS systems for enterprise networks are not applicable, and there is no large database on vulnerabilities known specifically for automotive networks.

[0037] Although the basic task of NIDPS, i.e., detecting and reacting to anomalies in network traffic, is the same in both enterprise networks and automotive networks, it is clear from the above points that the basic mode of action of an efficient NIDPS for automotive networks must in principle be different from the basic mode of action of NIDPS for enterprise networks. Due to these functional differences between enterprise networks and automotive networks, NIDPS for enterprise networks cannot be efficiently used in automotive networks.

[0038] NIDPS for automotive networks must utilize known and static network structures as well as the significantly lower dynamics of the network participants in order to be able to efficiently detect anomalies with limited resources.

[0039] In the following, service-oriented architecture aspects and service-oriented protocol aspects are described. Service-oriented architecture, also known as service-oriented architecture (SOA), is an architectural pattern in information technology from the field of distributed systems for structuring and using the services of IT systems. The interaction between service providers ("services") and service users ("clients") in a network typically runs according to the following pattern:

[0040] 1) Service providers publish or register their services.

[0041] 2) A software component that wants to use a service looks up the service in the catalog.

[0042] If you find a suitable service, you can move to the next step.

[0043] 3) The using component obtains a reference (address) from the directory under which it can access the service. Function calls are bound to this address.

[0044] 4) Invoke the service. Input parameters are passed to the service, and output parameters are provided back as a response to the call.

[0045] Steps 1) to 3) are used to identify the provided services with the aid of a centralized directory and to find out how to respond to them. This is also called "Service Discovery". In some service-oriented protocols, "Service Discovery" is implemented even without a centralized directory according to the so-called "Publish / Subscribe" model, in that components announce ("publish") their provided services via multicast and, if necessary, service users register ("subscribe") for specific services.

[0046] Usually, there are identifiers for referring to individual service providers and service users in data packets of service-oriented communication. These identifiers are referred to below as "service ID" for "service provider" or "client ID" for service users. Other names may also be used for this in specific service-oriented communication protocols. Usually, there is also an identifier for indicating the message type of the data packet. In the following, this identifier is referred to as "message type". For example, a request from a service user to a service provider is referred to as the message type "request", and the service provider's reply to the service user is referred to as the message type "response".

[0047] Middleware that implements a service-oriented communication architecture is, for example, Scalable Service-Oriented Middleware over IP (SOME / IP) or Data Distribution Service (DDS), both of which are used in the automotive field.

[0048] These middleware define corresponding communication protocols, which specify how data are exchanged within the service-oriented middleware. For SOME / IP, the SOME / IP protocol is usually mentioned here.

[0049] Figure 1 A schematic diagram of a communication network 100 is shown. The communication network 100 comprises a first endpoint 102 of a communication relationship and a second endpoint 104 of the communication relationship. The first endpoint 102 and the second endpoint 104 are connected via a connecting element 106, in particular an automotive Ethernet switch. In this example, data is exchanged in the communication relationship via frames. The connecting element 106 is constructed to receive frames and forward them based on information from the frames. In this example, the communication network 100 is an automotive Ethernet network. In this example, the information from the frames is information from the data link layer (Sicherungsschicht) of the OSI model. The endpoints can be control devices in a vehicle, which communicate via the automotive Ethernet network. The communication network 100 comprises an analysis device 108. The analysis device 108 comprises, for example, a NIDPS. The analysis device 108 is arranged, for example, in an automotive Ethernet switch. In Figure 1 1 shows an analysis in the connection element 106 of the communication. Alternatively or additionally, the analysis can also be performed at the end points of the communication, for example the first end point 102 or the second end point 104. A part of the analysis device 108 or the analysis device 108 as a whole can also be arranged outside the connection element 106 and connected or connectable to the connection element 106 or to the communication network 100 via a separate interface or via the communication network 100. In this example, the data line 110 is arranged in the communication network 100 for the connection. A wireless connection can also be provided at least partially.

[0050] In this example, the first endpoint 102 and the second endpoint 104 are registered endpoints. The registered endpoints are stored, for example, in a table in the analysis device 108. The table can be stored statically depending on the design of the communication network 100 or the definition of the service providers and service users available in the vehicle. A database can also be used for this. The registered endpoints can also be learned and stored during the operation of the communication network 100. In service-oriented communication, the first endpoint 102 and the second endpoint 104 can be both transmitter endpoints and receiver endpoints. In service-oriented communication, the first endpoint 102 and the second endpoint 104 can be both service providers and service users. For the endpoints assigned to service-oriented communication, a registered combination or multiple registered combinations with each other can also be set or stored. For this combination or for each registered endpoint, the direction for service-oriented communication can also be pre-given or stored.

[0051] exist Figure 2 The protocol layers for a communication network according to the OSI model are shown in . According to the OSI model, presentation layer 204 , session layer 206 , transport layer 208 , network layer 210 , data link layer 212 , and physical layer 214 are arranged below application layer 202 .

[0052] In contrast, protocols, which are referred to below as service-oriented communication protocols, are grouped together as application programs 216. Examples for application programs 216 are HTTP, UDS, FTP, SMTP, POP, Telnet, DHCP, OPC UA, SOCKS, SOME / IP, DDS. Other protocols are represented by the following protocol 218. Examples for the following protocol 218 are TCP, UDP, SCTP, IP (IPv4, IPv6), ICMP, Ethernet, Token Bus, Token Ring, FDDI.

[0053] In the following description, the working mode is described by taking SOME / IP as an example. The working mode can be correspondingly applied to other service-oriented communication protocols, such as DDS.

[0054] In addition to the actual communication protocol, SOME / IP also defines its own mechanisms for service discovery, i.e. for discovering and managing services at runtime. In addition to the SOME / IP protocol, SOME / IP specifies the SOME / IP Service Discovery (SOME / IP-SD) protocol for this purpose. For example, it is transmitted via SOME / IP-SD which of the endpoints is used by a SOME / IP service or a SOME / IP client. This allows a SOME / IP client to discover a SOME / IP service and vice versa. This makes communication between a SOME / IP service and a SOME / IP client possible, and vice versa.

[0055] exist Figure 3 The SOME / IP header is shown in Figure 4 The SOME / IP-SD packet is shown in Figure 5 The SOME / IP-SD IPv4 Endpoint Option is shown in FIG.

[0056] As described below, the functioning of a service-oriented middleware based on SOME / IP is examined using information of a protocol typically underlying a protocol that implements service-oriented communication in the communication network 100 .

[0057] In data packets of service-oriented communications, the so-called “endpoints” of the communication are identified, for example, in headers of the underlying protocol layers. For example, these endpoints are identified by their MAC addresses, IP addresses or port numbers.

[0058] The end points of the communication relationship in the specific vehicle whose communication is to be analyzed are preferably statically and predefined. In this case, the following information or a subset thereof is provided to the NIDPS as “system knowledge”:

[0059] -Ports at the transport layer, which are used for service-oriented communication.

[0060] - Registered endpoints used by service providers ("services") and by service users ("clients").

[0061] - A registered identifier for the service provider - "Service ID" and a registered identifier for the service user - "Client ID".

[0062] - For each "service ID", allows providing a list of registered endpoints for the service represented by the "service ID".

[0063] - For each "client id", a list of registered endpoints that are allowed to use the service represented by the "client id".

[0064] - Registered combinations of service users and service providers: Registered combinations of "client ID" and "service ID" and / or registered combinations of endpoints, i.e. which endpoint is allowed to be a service user (client) for which service provider (service).

[0065] according to Figure 6 A method for analyzing to identify anomalies is described. A service provided in service-oriented communication, i.e., a service identifier, is hereinafter referred to as a "service ID". A client provided in service-oriented communication, i.e., a service user identifier, is hereinafter referred to as a "client ID".

[0066] The method starts, for example, when the NIDPS obtains a data packet. The headers contained in the data packet are preferably analyzed successively. It is also possible to analyze a specific header or multiple specific headers.

[0067] In step 602, it is checked whether the data packet belongs to a service-oriented communication. If this is the case, step 604 is carried out. Otherwise, the method ends.

[0068] In step 604, the NIDPS checks whether data packets are exchanged between registered endpoints.

[0069] The NIDPS preferably verifies whether the data packet is sent by a registered endpoint. The NIDPS preferably verifies whether the data packet is sent to a registered endpoint.

[0070] If data packets are sent between registered endpoints, then step 606 is performed. Otherwise, step 616 is performed.

[0071] In step 606, it is checked by the NIDPS whether the data packets are exchanged between the endpoints registered for the "Service ID" or "Client ID" evidenced in the data packets.

[0072] The NIDPS preferably verifies for the sender endpoint and the receiver endpoint of the data packet whether the sender endpoint and the receiver endpoint correspond to the service provider certified in the data packet (certified by its "service ID") or to the service user certified in the message (certified by its "client ID"). The NIDPS preferably verifies whether the sender endpoint and the receiver endpoint of the data packet constitute a registered combination.

[0073] If data packets are exchanged between endpoints that are registered for the “service ID” or “client ID” documented in the data packet, step 608 is performed. Otherwise, step 616 is performed.

[0074] In step 608, it is checked by the NIDPS according to the endpoint whether data packets are exchanged between the service user and the service provider in the direction corresponding to the message type.

[0075] For a data packet, it is preferably checked whether the data packet is sent between the service user and the service provider in the direction corresponding to the message type. For SOME / IP, this information cannot be extracted from the SOME / IP header alone. Figure 3 As can be seen in the SOME / IP header, the SOME / IP header does not contain information about whether a data packet is sent from a SOME / IP service to a SOME / IP client or vice versa. Analysis of the sender endpoint and the receiver endpoint allows such analysis. This allows the NIDPS to verify whether a specific endpoint is interacting as a client or as a service as set up.

[0076] If data packets are exchanged between the service user and the service provider in the direction corresponding to the message type, step 610 is performed. Otherwise, step 616 is performed.

[0077] In step 610, it is checked by the NIDPS whether the endpoint transmitted as the endpoint of the service during the "service discovery" phase is a registered endpoint for the service.

[0078] For example, check the information in the SOME / IP-SD packet. Figure 4 As shown in , a SOME / IP-SD packet consists of a header, a so-called “entries array” and an “options array”. Figure 5 The entries in the "option array" are shown in which the IPv4 endpoints, i.e. the IPv4 address, the port number and information about the transport protocol used are transmitted. This allows the NIDPS to check that only the endpoints predicted also for SOME / IP communication are transmitted as endpoints in the SOME / IP-SD packets.

[0079] If the endpoint transmitted as the endpoint of the service during the "service discovery" phase is a registered endpoint for the service, step 612 is performed. Otherwise, step 616 is performed.

[0080] In step 612, it is checked by the NIDPS whether the information about the endpoint transmitted during the "Service Discovery" phase is a registered endpoint for the relevant "Service ID" or the relevant "Client ID".

[0081] This check preferably takes into account that not only the service of a special "Service ID" in a "Publish" message but also the service user of a special "Client ID" in a "Subscribe" message announces its endpoints in different "Service Discovery" messages.

[0082] If the information about the endpoint transmitted during the "Service Discovery" phase is a registered endpoint for the relevant "Service ID" or the relevant "Client ID", step 614 is implemented. Otherwise, step 616 is implemented.

[0083] In step 614, it is determined as a result of the analysis of the data packet that no attack was identified on the communication network 100. This information is preferably output.

[0084] Then, the method is terminated for the data group, and the other data groups are processed in the same manner.

[0085] In step 616, as a result of the analysis of the data packets it is determined that there is an attack on the communication network 100. This information is preferably output.

[0086] Then, the method is terminated for the data group, and the other data groups are processed in the same manner.

[0087] The steps described may be performed in this order or in another order. It is not necessary to perform all or the same steps on each packet.

[0088] The method can be used to analyze network traffic at existing Ethernet ports in an automotive Ethernet network. Based on the analysis, anomalies caused by an attacker in the network can be identified. In this example, the analysis is performed at an automotive Ethernet switch, where a data packet arrives at its hardware port or switch port. The analysis can also be performed in the vehicle at any other participant in the automotive Ethernet network. It can be provided that anomalies in the network traffic are identified on the automotive network and a response to the attack is taken.

[0089] Due to the use of information of a protocol underlying the protocol implementing the service-oriented middleware according to the OSI model, the following aspects are achieved:

[0090] - Ensure that data packets are only sent by permitted network participants. For example, network participants can be identified by "endpoints". Endpoints are identified, for example, by IP addresses, port numbers and information about which transport protocol is used.

[0091] - Checking between which network participants data packets are exchanged within the service-oriented communication. This is advantageous in particular when information from the data packets of the service-oriented communication protocol is not necessarily available.

[0092] - Verify that during the discovery phase of the service-oriented communication protocol, the so-called "service discovery", only allowed endpoints are communicated to the network participants.

Claims

1. A method for analyzing service-oriented communications in a communication network, characterized in that A data packet comprises a first header of an application layer for service-oriented communication and a second header of a protocol layer different from the application layer for communication in a communication network, wherein the data packet is analyzed based on information about a transmitter and / or receiver of the data packet from the first header and based on information about the transmitter and / or receiver from the second header: whether the data packet meets a criterion, wherein the criterion defines a rated value for the transmitter and / or receiver in the first header based on the content of the second header, and / or wherein the criterion defines a rated value for the transmitter and / or receiver in the second header based on the content of the first header, wherein the rated value for the transmitter and / or receiver defines at least one registered endpoint, wherein the communication network is an automotive network.

2. The method according to claim 1, characterized in that The second header is a second header of a presentation layer, a session layer, a transport layer, a network layer, a data link layer or a physical layer.

3. The method according to claim 1, characterized in that Wherein, it is checked according to the contents of the first header and the second header whether the data packet is sent by a registered endpoint and / or whether the data packet is sent to a registered endpoint.

4. The method according to any one of claims 1 to 3, characterized in that The nominal values ​​for the sender and / or the receiver define registered endpoints, wherein it is checked based on the content of the first header and the second header whether the data packets are exchanged between the endpoints registered for the service-oriented communication.

5. The method according to any one of claims 1 to 3, characterized in that The rated values ​​for the sender and / or receiver define at least one registered endpoint, wherein the data packet includes a service identifier, wherein for the sender endpoint of the data packet it is checked whether the sender endpoint corresponds to a service provider certified in the data packet, the service provider being certified by its service identifier, and for the receiver endpoint of the data packet it is checked whether the receiver endpoint corresponds to a service user certified in the data packet, the service user being certified by its client identifier.

6. The method according to any one of claims 1 to 3, characterized in that The rated values ​​for the sender and / or receiver define at least one registered endpoint, wherein the data packet includes a client identification, wherein for the sender endpoint of the data packet it is checked whether the sender endpoint corresponds to a service user certified in the data packet, the service user being certified by its client identification, and for the receiver endpoint of the data packet it is checked whether the receiver endpoint corresponds to a service provider certified in the data packet, the service provider being certified by its service identification.

7. The method according to any one of claims 1 to 3, characterized in that The nominal values ​​for the sender and / or receiver define registered endpoints, wherein the data packets include a service identification and a client identification, wherein it is checked whether the data packets are exchanged between endpoints registered for the service identification and the client identification indicated in the data packets.

8. The method according to claim 7, characterized in that It is checked whether the sender endpoint and the receiver endpoint of the data packet form a registered combination.

9. The method according to any one of claims 1 to 3, characterized in that The data packets comprise information about a message type, wherein it is checked whether the data packets are exchanged between a service user and a service provider in a direction corresponding to the message type, and / or wherein the direction is defined based on information about a sender endpoint and / or a receiver endpoint of the data packets, wherein it is checked: Whether the data packets are exchanged in this direction between the service user and the service provider.

10. The method according to any one of claims 1 to 3, characterized in that During the service discovery phase it is checked whether, for the data packets with which information about an endpoint providing a service is transmitted, the endpoint is an endpoint registered as a service provider and / or is an endpoint registered as a service provider for the service.

11. The method according to any one of claims 1 to 3, characterized in that During the service discovery phase it is checked whether, for a data packet with which information about an endpoint of an interrogating service is transmitted, said endpoint is an endpoint registered as a user of the service and / or is an endpoint registered as a user of the service for said service.

12. The method according to any one of claims 1 to 3, characterized in that If the criteria are not met, an attack or anomaly on the communication network is identified.

13. The method according to any one of claims 1 to 3, characterized in that Before checking the criterion, it is checked whether the data packet belongs to a service-oriented communication, wherein the check of the criterion is carried out if the data packet belongs to a service-oriented communication and the check of the criterion does not take place otherwise.

14. A device for analyzing service-oriented communications in a communication network, characterized in that The device comprises an analysis device which is arranged in a connection element for connecting a data line in a communication network for transmitting data packets, or is connected to the connection element or can be connected to the connection element for communication, wherein the analysis device is designed to implement the method according to any one of claims 1 to 13.

15. The device according to claim 14, characterized in that The connection element comprises an automotive Ethernet switch.

16. A computer-readable storage medium having a computer program stored thereon, wherein the computer program comprises computer-readable instructions, which, when executed by a computer, implement the method according to any one of claims 1 to 13.

17. A computer program product, characterized in that The computer program product comprises a computer readable storage medium according to claim 16 on which a computer program is stored.

Images