CN115398428A - Method for handling data anomalies, in particular in a motor vehicle - Google Patents

Abstract

A method for handling data anomalies is proposed, in particular in a motor vehicle, wherein at least one sensor (24, 26, 28) for identifying anomalies acquires data (211), wherein the sensor (24, 26, 28) checks the acquired data (211) for the presence of anomalies, and in the event of an anomaly being identified, an event (220, 221) is generated as a function of the associated data (211), wherein a decision is made as to whether the event (220, 221) is to be further processed, in particular stored and/or at least partially further transmitted.

Description

Method for handling data anomalies, in particular in a motor vehicle

Technical Field

The invention relates to a method for handling data anomalies, in particular in a motor vehicle.

Background

DE 102018209407 A1 has disclosed a device and a method for handling anomalies in a communication network, in particular of a motor vehicle. At least one detector analyzes a data stream in a communication network, wherein the at least one detector identifies at least one anomaly by a rule-based anomaly identification method if at least one parameter of a data packet in the data stream deviates from a nominal value, wherein the at least one detector sends information about the at least one identified anomaly via the communication network.

Automatic creation of protocols, histories or reports (logs), especially when anomalies or events are identified, should be done in the event of high event incidence and/or long time attacks, without overloading and denying the corresponding services. The log record or entry of the corresponding event report should be authentic, complete, and available. A non-deterministic history of complete (long lasting) attacks should be created for the attacker if possible. Manipulations and in particular deletions by attackers should be avoided. Outside the control device, the logging entries should be protected against unauthorized analysis. The logger should reliably send event reports, e.g. via an interface to an external node. The event entry may be deleted locally after successful transmission to the external node, particularly preferably after confirmation, in particular authenticated, of the receiving instance. Furthermore, the logger should send a so-called heartbeat signal, which shows the network connection. Accumulation of events should be feasible to reduce the number of log record entries to be processed.

Under normal operating conditions, events (Events) are not or rarely triggered, for example in the order of one event per hour. In the worst case, an attacker can have full control over the interface, in particular the ethernet interface. At full bandwidth, e.g., 100Mbit, an attacker can send up to 128000 UDP (User Datagram Protocol, a network Protocol) frames per second. Each such frame may trigger an event (an anomaly is identified in the data stream). Such attacks are assumed to occur at a frequency of one attack over the life cycle of the vehicle. The allowed number of so-called write cycles of a memory, in particular a flash memory, is limited and has to be taken into account. Likewise, the number of active operating hours is limited. Likewise, the availability of the upper level external data logger is also limited. Therefore, the corresponding logged events or event reports must be cached. All logging entries or event reports should be able to be transferred to a superordinate data logger at least once a day.

The deterministic behavior and limited resources of embedded systems are often problematic for conventional IDS or IDPS systems (Intrusion Detection systems, systems for automatically recognizing attacks on computer networks or computer interfaces, or IDPS systems, which do not forward corresponding data in the event of an Intrusion attempt being recognized, and thus prevent an Intrusion attempt).

Rather, it is desirable to describe an improved method for identifying anomalies. This object is achieved by the features of the independent claims.

Disclosure of Invention

This is achieved by a method according to the features of the independent claim.

This is done by deciding whether the event is to be further processed, in particular stored and/or at least partially further transmitted, so that different events can be recorded with different priorities. Thereby allowing events with higher priority to be stored more frequently than events with lower priority.

In a suitable development, it is provided that the decision whether or not to further process the event is made randomly and/or as a function of the number of occurrences of the event of a particular event type. Whereby events are selected in a non-deterministic manner for the attacker. Thereby performing event reduction. Thereby simplifying further processing of the selected event.

In a suitable development, it is provided that an event of a specific event type is processed further when it first occurs. Thus, each event type always selects one event with associated metadata. The occurrence of anomalies can thus be roughly understood.

In a suitable development, it is provided that, for an event having an event type which has already occurred at the time of a preceding event, a random decision is made whether the event is to be processed further. This way, the event is selected in a non-deterministic manner for the attacker, but the first occurrence of the event is always reliably selected beforehand.

In a suitable development, it is provided that the associated number of respectively occurring events is determined for different event types. Thereby generating useful additional information useful for later evaluation. Thus, the respective event types may also be correlated.

In a suitable development, it is provided that different priority groups are respectively assigned to specific event types, wherein events of higher priority groups are further processed, in particular randomly, with a higher probability than events of lower priority groups. It is by combining into different priority groups that the individual events can be selected in a simplified manner according to their importance. However, by randomly selecting the selected event within the priority group, the attacker still cannot understand or cannot understand the behavior deterministically.

In a suitable development, it is provided that different priority groups are each assigned a specific offset or range, from which at least one event to be processed further of the respective priority group is selected, wherein the offset or range of the priority group with the higher priority is smaller than the offset or range of the priority group with the lower priority. It is thus possible to always randomly select how many events are selected according to the priority average within the offset. Thus, more events are randomly selected for events having a higher priority group, and fewer events are randomly selected for events having a lower priority group.

In a suitable development, it is provided that, from a plurality of events of the same event type and/or priority group, a random decision is made as to which event of the events of the same event type and/or priority group is to be processed further. Events from different sources may be handled with the same priority. Thereby simplifying priority handling.

In a suitable development, provision is made for the random decision to be made using a random number and/or a random number range, in particular a vehicle-specific and/or control device-specific random number. Thereby ensuring non-deterministic anomaly-reducing behavior. Even in the case where the random number is disclosed in one vehicle, the acquired knowledge cannot be transferred to another vehicle. By using different random numbers in the fleet, it is ensured that different events are selected for each vehicle. This increases data diversity in the event of a fleet attack and enables a more extensive assessment or full reconstruction of the attack.

In a suitable development, it is provided that the events to be processed further are at least partially stored in a memory, in particular in a volatile or buffer memory and/or in a non-volatile memory (208) and/or in the context of an event report, and/or are provided with further information, in particular general metadata, such as the number of events occurring, time signals, number of events not processed further, length. Useful additional information can thus be generated, which is helpful for later evaluation. It is by archiving the length of each event that the fill level of the buffer can be inferred without having to read the fill level separately.

A suitable development provides that a plurality of sensors for identifying anomalies are provided, each sensor acquiring data from a different data source, in particular a communication system and/or a host or microcontroller, wherein each sensor checks the acquired data for the presence of an anomaly, generates an event on the basis of the associated data when an anomaly is identified, and forwards the event to an event manager. It is in the case of different data sources that the event manager ensures an upper level perspective when the event to be selected is properly selected.

Drawings

Further advantageous embodiments result from the further dependent claims and from the following description and the drawings. In the attached drawings

Figure 1 shows exemplary components of anomaly identification,

FIG. 2 shows an exemplary structure or interaction of received data, an exemplary structure or interaction of events derived from the data, a structure of associated selected events and an event report,

figure 3 shows a more accurate structure of the event manager,

figure 4 shows a flow chart for selecting an event to be further processed,

figure 5 shows a flow chart of counter incrementing,

figure 6 shows a flow chart of the storage of the non-volatile memory,

figure 7 shows a schematic overview of randomly selecting an event to be stored,

figure 8 shows the allocation of certain variables used in figure 7,

figures 9-14 illustrate different communication flows between the event manager, the communication adapter, additional IDS instances, and the backend.

Detailed Description

In conjunction with the aspects described below, deviations from normal behavior, which may occur in the data 211 of, in particular, a networked system (for example, data of a communication system or system data) in real operation for various reasons, are referred to below as anomalies. The reasons for this may for example be of the following type: defective or completely failed sensors provide erroneous data or no data at all, system components are damaged, and the system is manipulated by external, local or physical attacks (e.g., hacking).

The identification of anomalies in the data 211 is carried out by means of a so-called intrusion detection system IDS or IDPS. Hereinafter, IDS denotes a system that monitors abnormality of the data 211. The data may be, for example, data 211 at the time of a data connection in a communication network via which the control device 20, such as a gateway, communicates on different communication channels (for example via a bus system such as 25 or the internet 27). However, other data 211, such as system data within the control device (or host 29 or microcontroller or processor disposed in the control device or within a chip) should also be checked for anomalies by the IDS system. Anomalies in the sensed data 211 are made by the appropriate sensors 24, 26, 28. The sensors 24, 26, 28 are adapted to the respective source of the data 211, in the embodiment the bus system 25, 27 or the host 29.

According to fig. 1, a control device, such as a gateway 20, is arranged in a vehicle 18. The control device or gateway 20 comprises processor(s), memory, working memory (e.g. as an integral part of the host system 29) and interfaces for communication via a communication network. The gateway 20 for example handles instructions for data connection. Data 211 in the form of data packets is generated by this communication. Data 211, such as system data, is also generated during operation of the host 29. In the normal state, nominal values are observed, for example, as to the recipient address and the destination address, whether the correct program flow (for example for the host 29) is complied with, the time stamp, the frequency or frequency of occurrence of the data 211 of a particular data packet. The data 211 of the data packet is exchanged between further control devices or components, not shown in detail in the vehicle 18, to accomplish a specific task. The gateway 20 serves to couple a plurality of communication systems or interfaces, such as a CAN bus 25, an ethernet connection 27 and a data connection, to a host system 29, which host system 29 is an integral part of the control device 20 or gateway. However, other communication systems (e.g. further wired bus systems, such as LIN, CAN-FD, etc.) or wireless networks (e.g. WLAN or bluetooth) may be coupled to each other via the gateway 20 for data exchange. Typically, intrusion identification IDS or anomaly identification is used in the control device to monitor all data 211 (data 211 received over the communication system and data 211 generated by the host 29 within the control device 20) for the presence of corresponding anomalies. In an embodiment, IDS functionality mechanisms are illustratively described for gateway 20. In general, however, the functionality of the described anomaly identification or intrusion identification IDS can be implemented in any control device or in any electronic component. In particular, the use is not limited to the vehicle 18. Rather, any communication component, such as a communication module in the internet (internet of things) or in a networked production system, may be equipped with the described functionality.

A communication component, such as a control device or gateway 20, includes at least one anomaly identification 22. The data 211 input via the interfaces of the respective communication systems 25, 27, 29 are each guided via so-called sensors 24, 26, 28 (IDS sensors for short) for detecting anomalies or for detecting intrusions. So that corresponding sensors 24, 26, 28 are arranged in the gateway 20. Such sensors 24, 26, 28 are used to identify whether the acquired data 211 shows an anomaly. To this end, corresponding filtering algorithms or rule sets are stored in the sensors 24, 26, 28 for detecting and classifying anomalies. If the sensor 24, 26, 28 determines an anomaly, the corresponding packet of data 211 is classified as an event 220 (intrusion attempt). Generally, depending on the source 25, 27, 29, the sensors 24, 26, 28 may classify different anomalies as events 220 (assigning a respective event 220 to a particular event type 218) and identify these anomalies. The sensors 24, 26, 28 aggregate the particular event related metadata 216 into associated events 220 according to the respective event type 218 (the different anomaly types in the data 211). In addition, event related metadata 216 may also contain data or data components of exception data 211. The events 220 generated in this manner are forwarded to the event manager 30. The sensors 24, 26, 28 are typically designed to forward associated data 211 of the communication system (e.g., the bus system 25, 27) to a specified address without exception. In the event of an abnormality being identified, the sensors 24, 26, 28 may be designed not to forward the associated data 211 of the communication system (e.g. the bus system 25, 27) to the specified address. Alternatively, the sensors 24, 26, 28 may also be used to reduce the event 220 (reduced event or pre-reduced event 221). This reduction can relieve the event manager 30 of the burden, for example, by forwarding only a small portion of the useful data of the data packet or data 211 containing the anomaly. This is particularly advantageous in the case of large amounts of data, as occurs in ethernet connections.

Thus, for example, IDS CAN sensor 24 is used to identify anomalies in the case of CAN bus 25, IDS ethernet sensor 26 is used to identify anomalies in the case of ethernet system 27, and IDS host sensor 28 is used to identify anomalies in the case of host system 29. Depending on the communication path and communication protocol, additional IDS sensors may also be provided, which are capable of detecting anomalies in the respective sources or the sources of anomalies and classifying them if necessary.

The IDS CAN sensor 24 detects related events 220 of the associated event type 218, such as invalid CAN-ID, invalid message frequency, invalid message length, and the like. The IDS ethernet sensor 26 detects related events 220 of the associated event type 218 for the ethernet 27, such as invalid address or MAC address, invalid message frequency, invalid message length, etc. The IDS host sensor 28 detects relevant events 220, such as invalid code execution, program corruption, stack counters, etc., for the associated event type 218 for the host system 29. The respective event type 218 is typically provided with an event-specific event ID. There are a number of predefined event types 218 for different data sources with associated unique event IDs.

The following additional exceptions may be considered as events 220 for additional event types 218. These are, for example, events 220 or event types 218 that can be assigned to a firewall, such as frame loss due to buffer memory fullness, filter violations (stateless/stateful), transmission rate limits enabled or disabled, monitor mode activation or deactivation, context switches. Additional exceptions involving the host system 29 may also be considered as events 220, with associated event types 218, such as too high a CPU load, memory access violations, errors in code execution, detection of an ECU reset, corruption of log entries in non-volatile memory, log memory overflow, rejection of events, MAC address port changes, and the like.

The event manager 30 is used to further process the input events 220 or event related metadata 215 contained in the respective events 220. In particular, the event manager 30 is used for aggregating, formatting or preparing the events 220 and/or prioritizing and/or reducing/selecting and/or storing or keeping or permanently storing the selected and/or reduced events 220, 221 for the events 220. In particular, the event manager 30 determines which incoming events 220 should be further processed. The event selected from the input events 220 is referred to as a selected event 226. The corresponding selection should be made as non-deterministically as possible. Furthermore, the event manager 30 particularly preferably sets further generic metadata 217 for the entered event 220 or the selected event 226. Events 220 transmitted by different sensors 24, 26, 28 can thus be observed at a higher level, for example by adding the number of events occurring, the associated time stamp or time signal 224, etc. in the context of the generic metadata 217. Furthermore, it is ensured that a sufficient number of convincing events 220 can be stored as selected events 226 even in the case of so-called event bursts.

The event manager 30 exchanges signals with an intrusion-aware or anomaly-aware communication adapter 32. The communication adapter 32 serves as a communication means for exchanging data between the event manager 30 and further components 34, 36 of the control device or gateway 20 outside the anomaly identification 22. In particular, the communication adapter 32 serves as an interface for exchanging data between the event manager 30 and additional IDS instances 34 (preferably within the vehicle 18) and/or backend 36 (preferably outside the vehicle 18). The further IDS instance 34 may be provided only optionally.

To improve security, the event manager 30 may make reductions and prioritization of events 220, 221 that are random, non-deterministic to attackers, and hidden. Non-volatile storage of the selected event 226 may thus be conducted randomly, non-deterministically to an attacker, and hidden. The selection of the random control may be based on, for example, the individual random number 273 of the particular control device. Likewise, the event manager 30 may also randomly store the counter reading 231 of the event counter 204. In addition to the event related metadata 216, the event manager 30 also randomly stores the added generic metadata 217 as the selected event 226.

To improve security, the communication adapter 32 may upload or send event reports 242 to other IDS instances 34 randomly, non-deterministically to an attacker, and hidden. The uploading of random control may be based, for example, on the individual random number 273 of the particular control device (or gateway 20). So that certain events 220 can be transmitted periodically and cryptographically within the scope of the event report 242. However, even without a new event 220, so-called virtual events can be transmitted periodically and cryptographically in the format of an event report 242. This serves to prevent data exchange between the communication adapter 32 and another IDS instance 34 or backend 36 from being eavesdropped or randomly hidden.

In connection with fig. 2 it is exemplarily shown how the data 211 is further processed by the sensors 24, 26, 28 and sent to the event manager 30 in case an anomaly is identified, until the event manager sends an event report 242 via the communication adapter 32.

Fig. 2a shows an exemplary data packet of data 211, which may be present in a network frame (e.g., CAN, ethernet). The data 211 has a header 214 comprising, for example, a source address and a destination address (e.g., MACa, MACb). Furthermore, the data 211 comprises useful data 213.

As discussed in more detail below, the sensors 24, 26, 28 may optionally randomly select a useful data area 219 that is forwarded to the event manager 30. The sensors 24, 26, 28 have determined that this is an anomaly according to a particular event type 218 (event ID, ID). Thus, the sensors 24, 26, 28 generate event related metadata 216 as shown in FIG. 2 b. Depending on the event type 218 (or ID), different information of the anomaly may be stored in the event related metadata 216. In the exemplary embodiment, the source and destination addresses (MACa, MACb), the event type 218 and the selected useful data area 219 are used as the event-related metadata 216.

Alternatively, the event-related useful data 213 can also be forwarded to the event manager 30 in its entirety in the context of the event 220.

Alternatively, the event 220 may also not comprise the event related useful data 213, for example when the host 29 is used as a source. This may be an event type 218, such as information about lost data frames due to buffer fullness, activation or deactivation of an observation mode, too high a load on the CPU, corruption of an entry in the non-volatile memory 208, logging buffer overflow, event mitigation being valid, and so forth.

Further, for different event types 218, additional event related information within the scope of the event related metadata 216 may be part of the event 220. In the case of event type 218 "context transform," event related metadata 216 may include, for example, a context, such as a 32-bit sized context. In the case of an event type 218 "memory access violation" or "code execution violation," the event related metadata 216 may include, for example, an access address (e.g., 32 bits), a program counter (e.g., 32 bits), a task ID (e.g., 8 bits). In the event type 218 "control device reset detected" case, the event related metadata 216 may include, for example, the reason (e.g., 8 bits) for the reset, such as POR (return point), software reset, exception, and the like.

The underlying ethernet related events 220 may be recorded as event related metadata 216, such as static/state related filter violations (specific rule ID or ID of specific event type 218, e.g. 16 bits), ID of the filter rule leading up to the event 220 (if available), physical port address, physical port ID via which the frame was obtained, source address (e.g. MAC address, e.g. 48 bits), destination address (e.g. MAC address, e.g. 48 bits), possible IP address of source or destination, designation of UDP/TCP port (e.g. 16 bits, optional if present in the frame). Alternatively, static/state-related filter violations may also be recorded together, such as rule ID, physical port, frame (number of bytes), specific number of bytes to store the received frame, selected useful data area 219 (specific number of bytes), selected useful data area 219 of bytes of the original frame, useful data area 219-index (e.g., 16 bits), starting byte of selected useful data area 219 in the original frame. Additional ethernet related events may also be included in the event 220 communicated to the event manager 30, such as "transmission rate limited (valid/invalid)" for event type 218 is a rule ID with an associated ID of the filter rule that caused the event 220, "change context" for event type 218 is a context (e.g., 32 bits), and "address hop" or "MAC hop" for event type 218 is an old port (the physical port ID originally assigned to the address), a new port (the physical port ID where the address was most recently observed), an address (preferably a MAC address). However, event types 218 may also occur without metadata 216, such as "frame lost due to buffer full" or the like.

The forwarding of the event-related useful data 213 is therefore dependent in particular on the source of the data 211 with the associated event type 218. The metadata 216 is transmitted to the event manager 30 as events 220 or reduced events 221 (due to the random selection or reduction of the useful data area 219 to be transmitted in the sensors 24, 26, 28).

If the event manager 30 selects the event 220, 221 for further processing (selected event 226), as explained in more detail below, then general metadata 217 is also added to the event related metadata 216, resulting in the metadata 215 shown in FIG. 2 c. The generic metadata 217 is typically generated in the event manager 30. This is for example how many global events 220 the output signal of the event counter 204, i.e. the current counter reading 231, is or how many events of a specific event type 218 the current event 220 is. In addition, the generic metadata 217 may include, for example, a time signal 224 regarding when the event 220 occurred. Further, the metadata 217 may include a length 232 (size of data) that the event related metadata 216 or the complete metadata 215 has. This is advantageous for later memory management of the buffer memory 206.

The following general metadata 217 is exemplarily presented. This may be, for example, an event type 218 in a range of event IDs (e.g., 8 bits). This event ID of event Type 218 is unique and may, for example, include TLV-based encoding (TLV: type-Length-Value, type-Length Value). The general metadata 217 includes a length 232, for example, between 8 and 16 bits in size. The size of the data (metadata 215) follows a length field in bytes, up to 255 bytes. TLV-based encoding may also be provided. Also included is a time signal 224, i.e., a timestamp (e.g., 64 bits). For example, the time 224 is illustrated in terms of an absolute time value (in milliseconds) that has elapsed since a reference time point such as 1 month 1 day 1970 to illustrate a unique timestamp. Further, the generic metadata 217 may include a counter reading 231 or output value 231 (e.g., 32 bits) of the event type counter 204 and/or a counter reading 231 (e.g., 32 bits) of the global (event) counter 204, the sum of all counter readings 231 of the event counters 204 for each event type 218.

The event related metadata 216 is taken over in the form that the respective sensors 24, 26, 28 form. This event 220, with corresponding metadata 215 formed by both the sensors 24, 26, 28 and the event manager 30, is stored in the buffer memory 206 of the event manager 30. In a similar manner, further events 226 (exemplarily denoted 215_1, 215_8, 215 _190in the embodiment according to fig. 2 d) selected or reduced by the event manager 30 are stored in the buffer storage 206, as will be explained in more detail below.

From the selected events 226 stored in the buffer memory 206, which are exemplarily denoted 215_1, 215_8, 215_190 (metadata 215 event number 1, metadata 215 event number 8, metadata 215 event number 190) as an example of the selected events 226 in the embodiment according to fig. 2d, an event report 242 is now generated. The event report includes selected events 226 (215_1, 215_8, 215 _190in this example) stored in the buffer memory 206. These selected events 226 are preceded by a variable 254 (e.g., a random number, a time or counter, etc.) that has changed with respect to each event report 242. In addition, event report 242 also includes authentication information 256. By which authentication can be made between the communication adapter 32 or event manager 30 and the unit (IDS instance 34, backend 36, etc.) receiving the event report 242. The event report 242 includes a fixed length 258. To achieve this fixed length 258, the data 254, 215_1, 215_8, 215_190, 256 are still filled with so-called padding data 255. These padding data 255 do not contain information related to the event. As shown in fig. 2d, the data shown in the event report 242 is provided with encryption 258 prior to transmission. The event report 242 encrypted in this manner by encryption 258 is sent by the communication adapter 32 and decrypted and authenticated by the additional IDS instance 34 or backend 36, as described.

The IDS sensors 24, 26, 28 forward the event 220 or the reduced event 221 to the event manager 30. It is in ethernet networks that in the case of an attack attempt, when there are a large number of events 220 to be forwarded with a large amount of data or event related metadata 216, the memory 206, in particular the volatile memory or buffer memory 206, may soon be unable to accommodate all the events 220 anymore. This is due to the high data transmission rate or the large amount of data that can be transmitted. Thus, it makes sense that one or more IDS sensors 24, 26, 28 have pre-selected the to-be-forwarded event 220 and/or the data reduction (reduced event 221) according to certain criteria. These standards should be characterized by low predictability.

In the case of IDS sensors 24, 26, 28, and particularly in the case of IDS ethernet sensors 26, it is preferable to select specific events to be forwarded 220 with random control for added security and/or to reduce events to reduced events 221. The random or arbitrary selection or reduction of a particular event 220 or data block of an ethernet frame is non-deterministic and hidden from an attacker. The selection or reduction of random control may be based on, for example, the individual random number 273 of the particular control device. In the simplest case, the same random number 273 may also be used for other random-based scenarios, as a reference in the event manager 30 for decrementing or prioritizing all events 220, random associative storage of events 220, etc. Alternatively, the corresponding random number can also be regenerated again in the control device.

The incoming message or data 211 typically has corresponding header information 214 (e.g., specific address data) and subsequent useful data 213. Usually contains a lot of header information that is not absolutely necessary for the anomaly evaluation. According to the invention, only the absolutely necessary specific address parts, such as the address of the source (e.g. MAC address, e.g. 48 bits), the address of the destination (e.g. MAC address, e.g. 48 bits) and the ID number causing the exception (event type 218), are forwarded as a component of the reduced event 221 in the range of the event related metadata 216. Other information, such as possibly the physical port or port ID of the received frame, the IP address of the source or target, a description of the UDP/TCP port of the source or target (if such information is included in the frame), need not be transmitted in its entirety or in event 220.

However, the useful data area 219 to be forwarded or selected is randomly selected from the useful data 213 of the input data 211, as already explained in connection with fig. 2a and 2 b. Thus, for example, the number of the start data (start of the storage area to be transferred of the useful data, for example the byte number xyz) can be set at random (for example, a data area whose initial value is determined at random, for example the useful data byte number 538 for this event 220, is transferred). The offset (the amount of data transferred, e.g., 10 bytes) of the selected useful data area 219 may be fixedly selected. In addition to the minimum address information (source address, destination address), the useful data bytes numbered 538 to 547 are thus forwarded to the event manager 30 as selected useful data region 219 in the range of events 221 reduced in this way. Alternatively, the offset (the amount of useful data transferred) of the selected useful data region 219 can also be changed, preferably randomly. Preferably, the selected useful data region 219, in particular the start region or the end region of the selected useful data region 219, depends on the random number 273. The random number 273 is particularly preferably dependent on the control device or the gateway 20. It is particularly preferred that the random number 273 is unique, i.e. is given only once for this particular control device.

However, the random number 273 may alternatively be updated. Thereby yielding the following advantages. By updating the random number, different events 220 are recorded or selected in case the attack sequence (sequence of events 220) is identical. This is also the case when the attack is directed only to a single control device/vehicle 18, rather than to the entire fleet. The following assumptions/examples:

1. multiple repetition of the same attack sequence (event 220 sequence)

2. Updating random numbers between attack sequences 273

3. Not all events 220 (incident) can be recorded or selected within the scope of an attack sequence. Followed by event reduction for event report 242

4. The event report 242 with the reduced events 221 is forwarded completely to the upper level instance 34, 36 between the two attack sequences. Thus, after repeating the same attack sequence multiple times, the complete attack sequence can be reconstructed from event reports 242.

The sensor 26 can preferably adapt the selection of the random number 273 or different regions of the random number 273 to the size of the input data 211, in particular to the size of the input useful data 213. If the useful data 213 has a smaller data area, the random number 273 has to be selected such that the selection of the particular reduced useful data area 219 also falls only within this small data area of the useful data 213. Therefore, the random number 273 or the area of the random number 273 under consideration must be correspondingly small. However, if the input useful data 213 has a very large data area, the random number 273 or the area of the random number 273 under consideration must be selected so large that the selection of a particular reduced useful data area 219 can also cover this large data area of the useful data 213. Thus, the random number 273 is correspondingly larger.

By uniquely assigning random numbers 273 to the respective control devices 20, it is possible to combine complete messages with a complete data field (also to the further control devices and correspondingly detected and relayed there in a reduced manner also by correspondingly equipped sensors 26) by combining a number of reduced events 221 from a plurality of control devices when carrying out the analysis in back-end 36 in the presence of the further control devices. This is because, as described, further control devices with the same sensor function now also randomly select further useful data regions 219 (with further randomly selected start or end addresses), which, after merging a plurality of reduced events 221, can cover a large part of the (useful) data region 213 or the entire data region of the useful data 213 on the basis of sub-regions of different control devices or of the selected useful data region 219. The event 220 can thus be reconstructed from the reduced event 221 or the selected useful data region 219 by different control devices by, for example, providing the sub-data regions 538-547 (of the selected useful data region 219) from one control device, the sub-data regions 548-557 (of the further selected useful data region 219) from the further control device, the sub-data regions 558-567 (of the further selected useful data region 219) from the further control device, and combining the respectively selected useful data regions 219 again into the complete (useful) data region 213, for example in the higher-level control device or in the backend 36. This is particularly the case when a so-called broadcast attack is performed on the entire fleet or a so-called multicast attack is performed on a part of the fleet.

The start and/or end of the forwarded or selected useful data area 219 is preferably re-determined randomly after a specific event (periodically, start of the control device, reset of the control device, etc.). For this purpose, the random number 273 may be regenerated, for example. Alternatively, other ranges of random numbers 273 may be used to generate the start and/or end of the data region to be forwarded or the selected useful data region 219.

The processed reduced events 221 are forwarded from the sensor 26 to the event manager 30. Thus, the event manager 30 does not obtain the complete data stream of the network frames from the sensor 26, but only obtains reduced events 221 with reduced data size. The reduction of the to-be-forwarded event 221 is illustratively described based on the IDS ethernet sensor 26. However, in principle this can also be implemented in other IDS sensors 24, 26, 28. However, it is this event 220 that will quickly result in an overflow of the buffer memory 206 due to the high information content in ethernet frames having a high transmission rate. In the case of IDS CAN sensors 24, the corresponding data 211 is present anyway at a lower data rate and smaller data volume, so that here the events 220 that tend to be complete CAN be forwarded and stored. In principle, however, the data can also be reduced there, as described correspondingly.

Therefore, the following steps for reducing the events 220 in the sensors 24, 26, 28 are in principle performed. Data 211 is received from sensors 24, 26, 28 and/or data 211 is evaluated to determine if an anomaly exists. If there is an exception, the data 211 is decremented. The reduction is made by reducing the address area or header 214 and/or the data area or useful data 213. The reduction of the address region 214 may be performed by selecting a destination address and/or a source address. The reduction of the useful data 213 takes place randomly. The useful data 213 are randomly reduced by randomly selecting a start value and/or an end value of a sub-region of the useful data 213. The offset amount of the data area (the number of data transferred) is set to a specific value. The reduced event 221 is communicated to the event manager 30. The reduced events 221 contain reduced address data and/or reduced or selected useful data 219. The update of the random number 273 is performed according to a particular system state (periodically, startup, reset, etc.). Alternatively, the update of the random number 273 may be performed randomly and/or time-controlled. The random number 273 or range of random numbers 273 used to specify the beginning or ending region of the selected useful data region 219 may depend on the size of the useful region 213 of the received data 211.

The structure of the event manager 30 is shown in more detail with respect to fig. 3. The event manager 30 has a plurality of functional blocks that interact with each other. Each event 220 or reduced event 221 detected by the sensors 24, 26, 28 reaches block 202. Block 202 is used to select incoming events 220 or decreasing events 221 that should be further processed. In particular, block 202 is used to prioritize and reduce events 220, 221.

Each event 220 or each decremented event 221 also reaches a block 204, which block 204 serves as a counter 204 for the events 220, 221. Upon occurrence of an event 220, 221, the corresponding counter, in particular the global event counter 205, is incremented. The counter 204 particularly preferably has different counters Z1, Z2,. Zn for different event types 218 (ID 1, ID2,. IDn), as detailed above in connection with the corresponding sensors 24, 26, 28. The global event counter 205 in turn represents the sum of all counter readings for the counters Z1, Z2,. IDn of the different event types 218 (ID 1, ID2,. IDn). The output signal 231 of the block 204 or counter contains the counter readings of all events 220, 221, i.e. the counter readings of the respective event related counters Z1, Z2, a. The corresponding output signal 231 of block 204 is fed to block 210 to transmit the event 220. The block 204 is arranged to receive a reset signal 222 representing a reset request to one or more counters or event counters 204, 205. Block 204 obtains a signal from block 202 for a reduction state 225, e.g., "event reduction active". In block 202, event reduction is effective, for example, when only a reduced number of particular events 220, 221 are further processed as selected events 226. This is the case in particular when, for example, a large number of events 220, 221 are entered in the region of a so-called event burst, with an accompanying increase in the filling level 228 of the buffer memory 206. In this case, additional events 220 should be generated, for example "event decrementing active" using event type 218 as described above. Then for this event 220' with the associated event type 218, there is also a corresponding counter or counter reading.

The events processed by block 202 arrive at block 206 as selected events 226, and block 206 serves as a memory or buffer for the selected events 226 delivered from block 202 and includes corresponding logic for doing so. In response, the memory 206 reports the fill level or memory footprint 228 back to the block 202. The memory 206 is preferably a volatile memory, in particular a buffer memory of the RAM. Furthermore, the time signal 224, in particular the global time signal 224 arrives at the memory 206 or at a block for buffering selected events 226. The memory 206 is an integral part of the event manager 30.

The particular event 236 stored or buffered in the memory 206 reaches block 210, and the block 210 is used to transmit an event report 242 based on the selected event 226 or stored event 236. The block 210 for transmitting events also obtains an output signal 231 of the event counter 204, e.g. a counter reading of the counter Z1, Z2.. Zn and/or a counter reading of the global event counter 205 for the respective event type 218. Block 210 for transmitting events, in particular event reports 242, exchanges signals 244 with cryptographic module 212. The cryptographic module performs cryptographic operations such as encryption operations, authentication and verification operations, and random number generation. Encrypted communication from block 210 to the outside may be performed by means of a cryptographic module 212. In particular, the cryptographic module 212 encrypts the event report 242 using the encryption 257 shown in fig. 2d. Likewise, the cryptographic module 212 may also use the authentication information 256 to authenticate the event report 242, see also fig. 2d. Block 210 may reside in the communication adapter 32 and/or the event manager 30. Block 210 outputs a corresponding event report 242. The block 210 receives a request command 240 requesting a read of a corresponding event 236 stored in the memory 206, 208. The request command 240 may be made periodically and/or in response to an explicit request. In addition, block 210 sends a signal 239 to memory 206 (event release). Thus, typically after successful transmission of an associated event report 242 also containing a stored event 236 or selected event 226, the notification memory 206 or 208 allows overwriting or deletion of the stored and further transmitted event 236, 226.

Further, an additional memory 208, in particular a non-volatile memory, is provided in the event manager 30. The counter readings of the particular event 234 and/or event counter 204 that were cached in the buffer memory 206 are permanently stored in the further, in particular non-volatile memory 208. To this end, the memory 208 exchanges data with the event counter 204 and/or with the buffer memory 206.

The manner in which block 202 operates to prioritize and reduce events 220 is described in more detail below based on FIG. 4. The mechanism described below is used to select whether metadata 215 that is additionally helpful (and takes up a lot of memory) for events 220, 221 should be stored. In further overview, the block 202 is arranged to select an event to be further processed from the events 220, 221 delivered to the event manager 30 as the selected event 226. For each event type 218 of the obtained events 220, 221, track whether it is the first occurrence of that particular event type 218 or whether an event 220 with that event type 218 has been sent to the memory or buffer 206; i.e., query 301. If the event type 218 is the first occurrence, block 304 follows, in which the corresponding event 220 is transmitted to the buffer 206 as the selected event 226 and stored there. Otherwise, block 302 follows. In step 302 it is decided, based on certain criteria, whether events 220, 221 that have occurred with respect to the event type 218 should still be stored. This is done, for example, after the event 220, 221 has been randomly selected, in particular the event 220, 221 has been selected based on the random number 273. The random selection may particularly preferably be based on a control device-specific or vehicle-specific random number 273. An intelligent algorithm should be used to make the random selection to limit the overflow of the buffer memory 206 in a worst case attack scenario (long time attacks with so-called incident bursts). On the other hand, a reasonable number of stored events 236 or selected events 226 or log entries in a normal scenario should be retained in order to detect as wide a range as possible during the entire attack. To this end, in step 303, the event 220 selected in step 302 is transferred as the selected event 226 to the memory 206 for storage.

Thus, if an event, i.e. a query 303, is now selected according to step 302 according to random criteria, this event 220, 221 is also sent to the memory 206 as the selected event 226, step 304. Otherwise, the program flow ends without storing the event 220, 221 in the memory 206 or without additionally storing additional metadata 215 for the event 220. The monitoring of the first occurrence of event type 218 is reset when memory 206 has been read out and notified via block 210. If an event 220, 221 is not selected or discarded, a status "event rejected" is triggered for each discarded event 220, 221. A further counter 204 which detects the number of unselected events 220 is particularly preferably provided for this purpose.

For additional priority settings, the events 220, 221 may optionally be grouped according to the respective event type 218, and a separate instance for randomly decrementing the event for each event type 218 may be set. The priority setting may also be additionally implemented by forming a group. This means that event types 218 are assigned to different priority groups. A priority group having the highest priority (Prio 1) is assigned a specific event type 218 (e.g., an event type 218 having ID numbers ID1, ID6, ID14, ID23, etc.), a priority group having the next lower priority (Prio 2) is assigned an associated additional event type 218 (e.g., an event type 218 having ID numbers ID2, ID5, ID12, ID27, etc.), a priority group having the next lower priority (Prio 3) is assigned an associated additional event type 218 (e.g., an event type 218 having ID numbers ID3, ID9, ID13, ID19, etc.), and so forth. For different priority groups (Prio 1, prio2, prio 3.. The), a different number of events 220 are randomly selected on average as the selected events 226 (N1: the number of selected events for priority group 1 (Prio 1), nx: the number of selected events for priority group x (Prio _ x)). In the priority group with high priority, more events 220 are randomly selected on average than in the priority group with low priority (N1 > N2.). This can be achieved, for example, by selecting the regions B1, B2.. Bx from which the event 220 is selected (with the associated priority group Prio1, prio2.. Prio _ x) or by selecting the smaller the number, the higher the priority (B1 < B2.).

The selected event 226 is stored in the volatile memory 206. However, the selected event 226 should not be stored immediately in the non-volatile memory 208 because storing too frequently may damage the non-volatile memory 208. The selected events 226 may be randomly stored in the non-volatile memory 208, such as explained in more detail in conjunction with fig. 6.

One or more of the memories 206, 208 may handle selected events 226 having different sizes. The memory 206 is shown here by way of example in fig. 7. The memory includes a free memory area 250 and a filled memory area 252. In the populated storage area 252, a plurality of selected events 226 or 226 are stored. These entries 226 may each have a different size. Due to the non-rigid partitioning of the storage area, the storage space is optimally utilized. If the memory 206 is full, the new selected event is discarded 226. However, in principle, the memory 206 is inhibited from being filled by a self-adjusting mechanism as described below. So that when the fill level 228 of the memory 206 is very high, on average, much fewer events 220 are randomly selected than when the fill level 228 of the memory 206 is low. However, if the selected event 226 is discarded due to the buffer 206 being full, an event counter for the new event type 218 "logging buffer overflow (memory 206 overflow)" is implemented to determine the number of discarded events or entries. This may be done, for example, by informing the counter 204 of the state 230 of the memory 206, as shown in fig. 3, or by the signal 230 always sending a pulse to the counter 204 when a further selected event 226 cannot be stored due to the memory 206 being full.

Once all stored events 236 or selected events 226 have been successfully reported to, for example, an external data logger in the control device via block 210 in the context of event report 242, buffer 206 is freed to overwrite or delete the corresponding event 226 (signal 239 release event). Writing the event 236, particularly to non-volatile memory 208 such as flash memory, may advantageously be mapped by non-AUTOSAR storage mechanisms to ensure memory efficiency and performance requirements. However, there is also the possibility to use the standard AUTOSAR storage mechanism.

The event counter 204 is described in more detail in connection with fig. 5. For each event type 218, a separate counter Z1, Z2. The event counters 204 each start with a value of zero. It is first determined whether the counter reading is still less than the maximum value, INQUIRY 260. If this is the case, upon occurrence of an event 220, 221 of a particular event type 218, the counter Z1, Z2.. Zn of the respective event type 218 is incremented, step 262. Otherwise, the counter reading is kept at a maximum value so that no overflow occurs. The event counter 204 may be reset to zero upon request. For example, counter 204 may be implemented as a 32-bit counter.

Non-volatile storage of the event counter 204 and/or the particular selected event 226 in the non-volatile memory 208 is described with respect to FIG. 6. Data should be stored in the non-volatile memory 208 at regular intervals. Such time intervals are for example in the range of seconds, minutes to hours, for example data is stored every 30 minutes. The point in time of storage should be chosen randomly so that an attacker cannot predict the write behavior. The storage period may be controlled randomly, e.g. at certain intervals (e.g. within 30 minutes, etc., however, the exact storage time point within e.g. 30 minute intervals is randomly controlled). The random variable (for specifying the storage time point) may be generated or selected according to the control device-individual or vehicle-individual random number 273.

Alternatively, the time-controlled storage time can be selected randomly by multiplying a random number by the basic time interval. So that for example a certain basic time interval is 15 seconds, which basic time interval is multiplied by a random number range, for example a 3 bit random number or random number 273. The random number 273 itself may be periodically and/or randomly updated. Alternatively, the random number 273 may be individually given device-specifically or vehicle-specifically, for example, during production and manufacture. Alternatively, a specific range of the random number 273 may be selected, on the basis of which a factor dependent on the range of the random number 273 is formed.

Once a new selected event 226 occurs and may be stored in the non-volatile memory 208, the selected event 226 is stored in a non-volatile manner. Furthermore, if a state transition of the control device (which may also be caused by an attacker) occurs, e.g. due to a reset or sleep mode being requested, resulting in a loss of the current RAM content (and thus in a loss of the buffer memory 206), the storing of the selected event 226 (in the memory 206) and/or further information (like the specific counter reading 232 of the event counter 204) in the non-volatile memory 208 is initiated.

Data should be stored in a redundant manner so that recovery can occur even if portions of the data are corrupted. After being read from the non-volatile memory 208, the authenticity and integrity of the stored data should be checked or ensured. Preferably, the non-volatile memory 208 is disposed in a trusted area. It is assumed here that the memory inside the IC is classified as Trusted (Trusted). A standard automotive NVM (non-volatile memory) handler may be used for this purpose.

A state diagram for storing selected events 226 in the non-volatile memory 208 is illustratively shown in fig. 5. When this state 264 is reached, data may in principle be stored in the non-volatile memory 208 in the state 264. Cannot be stored in the non-volatile memory 208 in state 266. The transition from state 264 to state 266 occurs after the store is performed. The transition back to the state 264 where storage can occur is performed in a time-controlled manner. Preferably, the time is random, as already described. When the control device is not ready for a sleep state or reset, the system remains in state 266 (no storage).

FIG. 7 shows a more accurate illustration of the components of the event manager 30. The plurality of events 226 are stored in a buffer memory or memory 206 and form a filled memory area 252. Illustratively, event number 2 (226.2), event number 4 (226.4), event number 8 (226.8), event number 13 (226.13), event number 25 (226.25), event number 38 (226.38), event number 77 (226.77), and event number 97 (226.97) are stored in the buffer memory 206 as the selected event 226. These selected events 226 are selected from a series of occurrences of event 220 (numbered 0 through, e.g., 200) according to a particular procedure, as described below, and stored as selected events 226 in buffer memory 206.

The unfilled or remaining areas of the buffer memory 206 form a free storage area 250.

The corresponding fill level 228 of the illustrated memory footprint is formed in an embodiment by the last stored selected event 226.97. The storage area of the buffer memory 206 is now divided into a plurality of regions 267 between 0 and 100% or fill level regions 267. In an embodiment, these are, for example, ten (fill level) zones 267.1-267.10. In an embodiment, the zones 267 are always selected to be the same size, in an embodiment these are 10% apart. In an embodiment, the memory 206 has exactly the current region 267.4, i.e., the fourth region 267.4, which is between 30% and 40% of the full memory footprint.

The current storage region 267.4 in which the current fill level 228 of the memory 206 is located is determined in a function block 268. The current fill level zone 267 (used in the embodiment for the fourth zone 267.4) reaches block 270.

The offset 271 for the next event is determined in block 270. The offset 271 indicates from how many events 220 the next event 226 to be stored in the memory 206 should be selected. This number of events 220 (offset 271) from which the next event 226 to be stored should be selected, in particular randomly, depends on the respective fill level 228 or the associated storage region 267. When the fill level 228 or storage region 267 is low (the fill level 228 of the memory 206 is lower), the event 20 is stored faster, so the offset 271 is smaller. As the fill level 228 or the storage area 267 increases, the offset 271 increases, i.e. fewer events 220 are stored or only events 220 are selected from a larger number (offset 271). Overflow of the memory 206 can thereby be delayed or prevented in a targeted manner. Within the offset 271, the next event 226 to be stored is randomly selected. For each offset 271, only one event 220 (within the offset 271) is always randomly selected or stored. Thus, by varying the offset size according to the fill level 228 of the memory 206, more or fewer events 220 on average are randomly selected or stored. Thus, as long as the fill level 228 of the memory 206 is within a certain range 227, the event manager 30 always selects the event 226 to be selected from the same associated offset 271 until the fill level 228 reaches the next region 227 with a changed, typically increased offset 271.

If the storage region 267 defined by the lower or upper limit value is left, the next offset 271 of the new region may be increased or decreased, for example by a certain multiple or by a certain divisor.

The corresponding scenario in the table according to fig. 8, which results in the memory 206 being occupied, is exemplarily shown, as shown in fig. 7. The offset 271 may exemplarily be selected for different fill levels 228 or storage regions 267, as explained below. Thus, for example, for a memory region between 0 and 10% (267.1), the offset 271 may be assigned to 2 (from zero to 2, and thus from three events 220), to 8 (from 0 to 8, and thus from 9 events 220), for a memory region between 10% and 20% (267.2), to 32 (from 0 to 32, and thus from 33 events 220), for a memory region between 20% and 30% (267.3), and to 128 (from 0 to 128, and thus from 129 events 220), and so on. For example, a corresponding increase in the offset 271 of the next storage region 267 can be achieved by a corresponding factor (4) or the like. Both the storage region 267 and the offset value 271 can be freely configured and are therefore adapted to the respective desired conditions, such as memory size, etc.

In a subsequent block 272 of fig. 7, the next event 220 to be stored should now be selected randomly (according to the random number 273 exemplarily shown in fig. 7) according to the fill level 228 or the storage region 267. It must be ensured here that the offset 271, i.e. the number of events 220 or the range of next events 220 to be considered, from which the respective event 220 to be stored should be randomly selected, may be covered by the random number 273 or a corresponding range of random numbers 273. The size of the range of random numbers 273 to be considered is selected according to the corresponding offset 271. If the random number 273 is bit-encoded, for example, as exemplarily shown in fig. 7, a temporary range 273 _tempof the random number temporarily having a size of two bits is first selected, for example, for an offset 271 (0-2) equal to 2. When the offset 271 is 8 (0-8), a range x of 4-bit random numbers 273.X _vis selected. When the offset 271 is 32 (0-32), a temporary range 273 uv of random numbers of 6 bits in size is selected. When the offset 271 is 128 (0-128), a temporary range of 8-bit-sized random numbers 273 u v is selected. A temporary range of random numbers 273 v can be found in column 4, where it is exemplarily illustrated for the specific random number 273 of fig. 7. It is then checked whether the portion of the random number 273 contained in the temporary range 273_temp is less than or equal to the offset 271 of the next storage area 276. If this is the case, the provisional range 273_yis actually used as the random number range as well as the part 273.X of the random number. The corresponding query in column 5 may be answered with "true". For these cases, the temporary portion of the random number 273.X _, v coincides with the selected random number portion 273. X. If this is not the case (answer the query in column 5 with "false"), the temporary portion of the random number 273.X _, is reduced. This can be done by omitting a bit, preferably the Most Significant Bit (MSB). For the value of the random number thus found in this range 273.X, it can now be ensured that this value lies within the offset 271 of the next memory zone 267.

Thus, for example, for an offset 271 (0-8) of 8, consider the first 4 bits of the random number 273 so as to also cover the number 8 itself (the size of the current offset 271), for which see the columns in FIG. 8 with buffer entries numbered 3, 4, 5. If the value of the 4-bit size of the associated temporary random number range 273.5 v < = offset 271-e.g. event number 25, 273.5=0b0111=7, then the 4-bit number is used directly. The associated query shows column 5 of fig. 8. The result is true since the condition is satisfied.

If the value > offset 271 of the 4-bit size of the associated temporary random number range 273.4 v > 273.4= -e.g. event number 13, 273.4= -0b1100 = -12, then the 4-bit number is not used directly, but the MSB (the most significant bit of the considered random number range 273.4) is truncated and the resulting 3-bit number 0b100= -4 is used. The truncated MSB does not have to be discarded but is input as the LSB (least significant bit) of the next range 273.5 v of random numbers to be considered. In this case the associated condition (corresponding random number range 273.3< = offset 271) is not met (the associated result is "false" in column 5). This process ensures that the random number 273 is fully used and is not unnecessarily depleted quickly.

In order to determine the size of the random number range 273.X (e.g., the number of bits required for the range of random numbers 273), it must be considered whether a variable (e.g., the number of bits required) representing the size of the offset 271 of the associated memory region 267 for the next event 220 is sufficient.

Thus in the embodiment according to fig. 8, according to line 1, in case the selected random number 273.1 is 2, the event number 2 (220.2, global event counter 285 is 2) is selected (after discarding events 220.0, 220.1 number 0 and number 1) as the selected event 226.2 when the offset 271 is 2 (from 0-2). According to line 2, at the next offset range 271 (still 0-2), the event number 1 associated with that offset range 271 is randomly selected. Event number 0 in the offset range 271 has been discarded (corresponding to a global counter reading 285 of 3), but event number 1 in the offset range 271 (corresponding to a global counter reading 285 of 4, giving rise to the selected event 226.4) is selected. According to line 3, the next offset range 271 is still at 2 (0-2) because the fill level 267 of the buffer 206 is still located in the region 267.1 between 0 and 10%. 273.3 is 2, so after discarding event numbers 0 and 1 in the offset range 271, event number 2 is selected (global counter reading 285 is 8, selected event 226.8). Since the subsequent fill level 267 is in the next fill level range 267.2, the new offset 271 now becomes 8 (0-8). As described above, now consider the next 4 bits of the range of nonce 273.4 v. Since the associated random number of the nonce range 273.4 v is 12, larger than the current offset 271 (query 12< =8 in column 5 yields "false"), the most significant bits of the nonce range 273.4 v are not used, but only the 3 less significant bits (binary 100, i.e., 4) within the selected random number range 273.4 are used. Thus, for this new offset range 271 of 8 (0-8), event number 0 (global counter reading 285 is 9) to number 3 is discarded, and event number 4 (global counter reading 285 is therefore 13) is selected as the selected event 226.13. Fig. 8 exemplarily combines corresponding values for the further fill level 267.

Thus, in block 272, it has now been randomly determined which event 220 is next selected as the selected event 226. The corresponding block 280 now monitors for the occurrence of a new event 220 (block 284). For example, it has been previously set that event 226.8 (8 th event) is stored and then event 226.13 (13 th event) should be stored. The block 280 thus waits for the event number 13, i.e. discards the next event number 9-12 and stores the event number 13 as the selected event 226.13 in the memory 206. A new fill level 228 of the memory 206 is determined based on the new selected event 226 having the data size of the metadata 215 (event related metadata 216 and generic metadata 217). This can be done particularly simply, for example, using the length 232 already contained in the metadata 215.

The random number 273 is selected differently for different control devices or vehicles 18. So that, for example, the random number 273 can be given once by the vehicle alone or by the control device alone during production. Alternatively, the random number 273 may be regenerated internally by itself according to a particular rule. This regeneration may occur, for example, during a system state transition (at boot, reset, transition to sleep mode, etc.) and/or periodically after a certain time.

Block 272 determines the next event hit 278 from the corresponding information (next event hit: next event hit 278 in next offset 271). The next event hit 278 arrives at block 280 (throw the dice), and the delivered event 220 is either discarded (event 220 is not stored in buffer memory 206) or selected as a selected event 226 for storage in buffer memory 206 at block 280 at random. If a selection is made (event hit 282, event hit), then block 284 follows. Block 284 is invoked at each event 220. However, block 284 itself invokes block 280 (for each event 220), and block 280 provides feedback to block 284 as to whether an event 220 should be selected. If the event 220 is selected via block 280, block 284 triggers the storage of the event 220 as the selected event 226 in the memory 206.

In block 284 (on event, when there is an event), the selected event 220 is read in for subsequent storage as the selected event 226 in the free area 250 of the buffer memory 206. Block 284 is always invoked at each new incoming event 220, 221. Block 284 is used to randomly select, including possible reductions and priority settings of the incoming events 220, 221.

In addition to the random selection in block 280, events 220 may also be randomly reduced, such as has been described with ETH sensor 26. So that a particular data area (preferably the beginning of a fixed data area or the end of a data area) can be randomly selected. Also, only certain reduced address data may be stored.

Also, where the occurrence of events 220 is high or generally the sensors 24, 26, 28 themselves (in the case of a particular source, e.g., ethernet) may select or reduce events 220, which is quasi-prefiltering similar to the event manager 30, so as to relieve the event manager 30 (to which events 220 from other sources are also input) of burden. If the sensors 24, 26, 28 have not forwarded the respective event 220 to the event manager 30, this should likewise be communicated to the event manager 30 as a separate event type 218 (similar to the reduced state 225 in the event manager 30). In general, however, the event-related selection of the event 220 may be made in the sensors 24, 26, 28 themselves and stored in a buffer memory of the sensors 24, 26, 28. Likewise, corresponding counters may also be provided in the sensors 24, 26, 28 for the respective event types 218, which may be communicated to the event manager 30 when needed. The events 226' selected by the sensors 24, 26, 28 may also be communicated to the event manager 30 upon request by the event manager 30 for possible forwarding to the superior instance 34 and/or the backend 36. Nevertheless, the processes described in connection with the event manager 30 for random selection and/or prioritization may still be run in the sensors 24, 26, 28. However, these processes may be limited to only the specific data 211 of the respective source, and thus the sensors 24, 26, 28 may only select the sensor-specific events 220.

To improve security, the communication adapter 32 may provide for event reports 242 to be sent to other IDS instances 34 randomly, non-deterministically to an attacker, and hidden.

As already described in connection with fig. 2d, an event report 242 is generated from the selected events 226 stored in the buffer memory 206. The event report includes selected events 226 stored in the buffer memory 206. These selected events 226 are preceded by a variable 254 (e.g., a random number, a time or counter, etc.) that changes with respect to each event report 242. In addition, event report 242 also includes authentication information 256. By which authentication can be made between the communication adapter 32 and the unit (IDS instance 34, backend 36, etc.) receiving the event report 242. The authentication information 256 may, for example, be formed by at least a portion of the data in the event report 242, preferably by all of the data in the event report 242 (except, of course, for the authentication information 256 to be formed). For this purpose, a corresponding algorithm is stored in the event manager 30. For authentication purposes, superordinate unit 34 and/or backend 36 may form associated authentication information 256' in the same manner from the corresponding data of the received event report 242 after decryption and compare with the actually received authentication information 256 (as transmitted in event report 242). If so, authenticity is assumed.

The event report 242 has a fixed length 258. To achieve this fixed length 258, the data 254, 215_1, 215_8, 215_190, 256 are also filled with so-called padding data 255. The padding data 255 does not contain information related to the event. As shown in fig. 2d, the data shown in the event report 242 is provided with encryption 258 prior to transmission. The event report 242 encrypted in this manner by encryption 258 is sent by the communication adapter 32 and decrypted and authenticated by the additional IDS instance 34 or backend 36, as described. Even if the variable 254 changed for each event report 242 differs by only 1 bit, for example, the subsequent encryption 258 results in the encrypted event report 242 being very different (and not just one bit) from the previous event report 242.

Thus, a particular event 220 may be transmitted periodically and cryptographically (using both the changing variables 254 in plain text as part of the event report 242 and the encryption 258 of the event report 242) within the scope of the event report 242. However, even without a new event 220, so-called virtual events (e.g. consisting of padding data 255) can be transmitted periodically and cryptographically. This serves to prevent data exchange between the communication adapter 32 and another IDS instance 34 or backend 34 from being eavesdropped or randomly hidden.

The communication flow between the event manager 30 and the communication adapter 32 within the control device or gateway 20, the communication flow between the communication adapter 32 and at least one additional IDS instance 34 within the vehicle 18, and the communication flow between the additional IDS instance 34 and the backend 36 are illustratively described below based on figures 9-14.

Communication from a control device such as the gateway 20 to another IDS instance(s) 34 (e.g., a central event logger within the vehicle 18) should ensure that the other IDS instance 34 or event logger is informed of entries that were not read or events 236 or selected events 226 stored in the memory 206. The control device or gateway 20 should periodically send event reports 242 to the further IDS instance 34, preferably by means of so-called heartbeat signals (periodic signals that can be used to check whether the communicating participants are connected as prescribed). The heartbeat signal (including the event report 242) should be encrypted and authentic. Preferably, the communicated information should be exchanged between the control device or gateway 20 and the further IDS instance 34 both truly (using authentication information 256 if necessary) and encrypted, preferably randomly or using a random number 273. Preferably, the event report 242 should have a fixed length 257, should be encrypted and authenticated. Each encrypted event report 242 should be different from the previous event report 242 even if the transmitted status has not changed.

In addition, communications from additional IDS instances 34 to the control device or gateway 20 or associated communication adapter 32 should also feature the following functions. The data logger or IDS instance 34 should read in the events 236 or associated event reports 242 as quickly as possible in order to prevent overflow of the memory or buffer memory 206, among other things. The event report 242 should be able to be read out via the diagnostic interface, for example, upon request. Alternatively, the event report 242 may be transmitted entirely periodically. Even if no new selected event 226 is available in the scope of the new event report 242, the event report 242 should be transmitted or read out periodically, preferably truly and cryptographically or via concealment. The control device or gateway 20 should respond cryptographically and authenticated to the read request 240 with a response or event report 242 having a fixed length. Each encrypted response or event report 242 should be different from the previous response or event report 242 even if the content has not changed. This is illustratively done through a constantly changing variable 254 as already described.

According to fig. 9, the event manager 30 first selects a first selected event 226.1 and then selects a second selected event 226.2. These selected events are processed by the event manager 30 as described. Thus, the selected events 226.1, 226.2 are stored in the memory 206. The communication adapter 32 includes a signal 400, a time-dependent interrupt signal (Timer IRQ). The time-dependent signal 400 is preferably periodically developed to thereby periodically initiate the transmission of event reports 242 from the communication adapter 32 to additional IDS instances 34 in the vehicle 18. However, even in the absence of new events 226.1, 226.2, as described below, a signal (in the form of a "normal" event report 242) is sent from the communication adapter 32 to the further IDS instance 34 (see signal 406). However, it is particularly preferred that the sending of the event report 242 is not triggered upon acquisition of the event 220 or the selected event 226, but rather periodically (by passage of a periodic time). This is particularly advantageous because the transmission to the further IDS instance 34 and/or the backend 36 is also always performed periodically after a certain time has elapsed, i.e. after a certain time has elapsed. Whereby the behavior or anomaly identification of the event manager 30 is opaque to the attacker. An attacker never knows whether or not his attack has been detected, what has been detected and how the anomaly identification system works.

After the communication adapter 32 has received the signal 400 (Timer Interrupt), the communication adapter 32 requests the event report 242, signal 402, from the event manager 30. The event manager 30 creates a corresponding event report 242 that includes the previously selected events 226.1 and/or 226.2 (with corresponding general metadata 217 and event-related metadata 216) and the changed variables 254. Furthermore, corresponding padding data 255 is added, thereby reaching a fixed length 257 of the event report 242 (knowing the length of the authentication information 256 still to be formed). In addition, the event manager 30 generates authentication information 256 from the changed information 254, the selected events 226.1, 226.2, and the padding data 255 using a particular algorithm, for example. The authentication information 256 formed in this manner completes the event report 242. The complete event report 242 is then encrypted with key 258. The encrypted event report 242 arrives as signal 404 at the communications adapter 32. Encryption (using altered information 254 and/or key 258) and authentication (forming authentication information 256) may be performed in event manager 30 and/or communications adapter 32 if the corresponding security requirements are met.

Alternatively, the communication adapter 32 may encrypt the event report 242, for example, according to the random number 273. It is particularly preferred to always form a new random number 273 for encryption, for example by hashing. This further makes decryption of the transmitted message or encrypted event report 242 difficult. If necessary, the communications adapter 33 takes over the authentication using the authentication information 256 and/or the addition of the changeable variable 254 and/or the final encryption of the entire event report 242 with encryption 258.

Corresponding signals 406 are sent in response to the timer interrupt (signal 400) even if no new event report 242 is provided by the event manager 30 due to the occurrence of a new selected event 226. The dummy message, in the data format of event report 242, is then transmitted encrypted (using key 258) to the further IDS instance 34, either by random number or by a variable 254 that is constantly changing. The dummy message is always encrypted by a constantly changing variable 254 or new random number so that other messages or encrypted messages are always transmitted periodically (signal 406) even if no newly selected event 226 occurs. By means of which it can be checked whether the communication connection between the communication adapter 32 and the further IDS instance 34 as specified is functional.

After the further IDS instance 34 obtains the message sent from the communication adapter 32 (signal 406), the further IDS instance 34 sends an acknowledgement signal to the communication adapter 32 (408). After obtaining the acknowledgement signal 408, the communication adapter 32 generates a request to the event manager 30 to delete or overwrite the cached, if necessary reduced, selected event 226 or associated event report 242 again (signal 410).

In an alternative embodiment, the superior instance 34 and/or the backend 36 check the authenticity of the received encrypted event report 242. To this end, the superior instance 34 and/or the backend 36 decrypt the received message, i.e., the encrypted event report 242, using the known key 258. The event report 242 is then available in plain text. The event report 242 is authenticated using a corresponding algorithm for forming authentication information 256 (which is also used by the event manager 30 or the communication adapter 32 to create the authentication information 256). To this end, all data of the received and decrypted event report 242 (except for authentication information 256) is again used, and corresponding authentication information 256' is thus formed. The formed authentication information 256' is then compared to the authentication information 256 received in the context of the event report 242. If consistent, the received event report 246 is deemed authentic. In this variant, further data communication with the higher-level or lower-level instance is not possible until after authentication. In this embodiment, the signal 408 (acknowledgement signal) is sent to the communication adapter 32 after successful authentication, and then the communication adapter 32 sends a signal 410 to the event manager 30 to release coverage of the selected event 226.1, 226.2.

Preferably, the response or acknowledgement signals 408, 416 should also have a fixed length 257'. Preferably, the confirmation signal 408 should be authenticated and encrypted. Each response or acknowledgement signal 408 of the upper level instance 34 and/or the backend 36 should be different from each other even if the content has not changed.

An example of such an acknowledgement signal 408, 416 can be found in fig. 9. The acknowledgement signals 408, 416 have a similar structure as the event report 242. The validation signals 408, 416 include a variable 254' that may be varied. The variable 254' that is changeable changes for each newly transmitted acknowledgement signal 408, 416. The changeable variable 254' may again be implemented, for example, by a random number, a counter, a time.

Particularly preferably, the changeable variable 254' of the confirmation signal 408, 416 may be formed by using the changeable variable 254 of the just-transmitted event report 242. To this end, the superordinate instance 34, 36 is arranged to extract the changeable variable 254 from the received event report 242 and insert it into the acknowledgement signal 408, 416. Thus, in a subsequent step, the confirmation signal 408, 416 may also be authenticated by comparing the changeable variable 254' of the received confirmation signal 408, 416 with the changeable variable 254 of the previously transmitted event report 242. If they are identical, a true acknowledgement signal 406, 408 is deduced. Furthermore, the changeable variable 254' need not be generated in the upper- level instances 34, 36 itself. This may be followed by releasing the memory 206.

In addition, the confirmation signal 408, 416 includes specific data 255', e.g., in the form of any template. In addition, the confirmation signal 408, 416 includes authentication information 256'. Similar to the case of the event report 242, the authentication information 256' may again be formed by a specific algorithm that uses the remaining data of the confirmation signals 408, 416, i.e., the changeable variables 254' and data 255'. The authentication information 256' formed in this manner completes the confirmation signals 408, 416. The acknowledgement signal has a fixed length 257'. And then encrypted using key 258'. Optionally, such encryption 258' may also be omitted.

The receiving instance (e.g., superior instance 34, backend 36) and/or the communication adapter 32 or event manager 30 can in turn decrypt the confirmation signals 408, 412 (using the key 258') and use for authentication. For this purpose, the authentication information 256 ″ derived therefrom is determined again from the received data (changeable variables 254', data 255 ') using a correspondingly known algorithm and is compared with the authentication information 256' obtained. If consistent, authenticity is assumed. If the obtained authentication information 256' is correct, a signal 410 for releasing the memory 206 may be generated. If the authentication information 256' is incorrect, the signal 410 cannot be generated so that the selected event 226 contained in the memory 206 is (still) not deleted.

The further IDS instance 34 also periodically receives a timer interrupt signal 412, which is formed similarly to the signal 400 already described. In response to the interrupt signal 412, the further IDS instance 34 in turn sends an encrypted message, signal 414. The message may contain an event report 242 or vehicle related event report (including additional event reports) as necessary, as transmitted via signal 406 prior to communication adapter 32. As with the communication adapter 32, messages are encrypted by additional IDS instances 34, and in particular by a constantly changing variable 254' such as a random number 273. If the communication adapter 32 does not transmit an event report 242, for example because a new selected event 226 has not occurred, then the virtual message having the same data format as the event report 242 is again used and transmitted to the back end 36 in encrypted form (signal 414). The backend 36 sends an acknowledgement signal 416 and/or another notification or request to override the event 236, etc. cached in the buffer memory 206, to the further IDS instance 34. The acknowledgement signal 416 may be formed as described above.

After obtaining the signal 410 regarding event release, the event manager 30 selects additional selected events 226.3 and 226.4. A further flow may be taken from fig. 10. At the same time, the event manager 30 also selects a further event 226.5. The timer interrupt (signal 420) reacquires the communication adapter 32. The communications adapter now requests an event report 242 from the gateway 20 (signal 422). The event manager 30 sends an event report 242, signal 424, based on the selected event 226.3, 226.4, 226.5 to the communication adapter 32. After obtaining the event report 242, the communication adapter 32 sends the event report 242 encrypted and authenticated by the new changeable variable 254 (e.g., random number) to the other IDS instance 34, signal 426. The further IDS instance 34 acknowledges the acquisition by an acknowledgement signal 428. Acknowledgement signal 428 may be formed as described in connection with acknowledgement signal 408 (fig. 9). After obtaining the confirmation signal 428, the communication adapter 32 in turn sends a request to the event manager 30 to override or delete the selected event 226.3, 226.4, 226.5, i.e. signal 430, on which the event report 242 is based. While selecting a further selected event 226.6 between the transmission of signal 424 and the reception of signal 430. However, this selected event 226.6 cannot yet be overridden, because this selected event 226.6 is not yet the basis for the event report 242 that has been transmitted to the communications adapter 32. In this regard, the signal 430 is not involved in covering the selected event 226.6, but only in covering the selected events 226.3, 226.4, 226.5 that have been transmitted in the context of the last event report 242.

As already described, a timer interrupt also occurs at the further IDS instance 34 (signal 432). Thereby causing the additional IDS instance 34 to transmit the newly received event report 242 in signal 426 to the backend 36 in encrypted form, signal 434. The backend 36 acknowledges the acquisition of the corresponding message 434 by a corresponding acknowledgement signal 436, which acknowledgement signal 436 is sent to the further IDS instance 34. The acknowledgement signal 436 may be formed like the acknowledgement signal 408 or 416.

A further flow chart is shown in fig. 11. Another timer interrupt, signal 440, occurs again for the communication adapter 32. The communications adapter 32 then sends a request to the event manager 30 to send the event report 242, signal 442. The event manager 30 sends an event report 242, signal 444, containing the event 226.6 selected during this period. The communication adapter 32 encrypts the event report 242 using the new changeable variable 256 and sends the encrypted event report 242 to the additional IDS instance 34, signal 446. Upon acquisition, the further IDS instance 34 sends an acknowledgement, signal 448, upon which signal 448 the communication adapter 32 sends a request to the event manager 30 to override or release the already delivered event 226.6, i.e. 450.

The further IDS instance 34 again receives the timer interrupt, signal 452. The encrypted event report 242 is then vehicle-dependently transmitted to the backend 36, along with additional event reports from additional IDS systems, as necessary. The backend 36 sends an acknowledgement signal and/or a request to release or override the corresponding event, etc., i.e., signal 456, to the additional IDS instance(s) 34.

In the exemplary flow according to fig. 12, no new selected event 226 occurs between the transmission of the last event report 242 and the new occurrence of the timer interrupt (signal 460). After obtaining the timer interrupt 460, the communication adapter 32 sends a corresponding request signal 462 for the new event report 242 to the event manager 30. The event manager 30 generates an event report 242 with virtual content despite the occurrence of the new selected event 226, which is then sent to the communication adapter 32, signal 464. The additional IDS instance 34 and/or backend 36 may identify the virtual content as virtual content. The communication adapter 32 encrypts the received event report 242 with the new, changeable variable 254 with the virtual content and sends the encrypted and authenticated event report 242 to the other IDS instance 34, signal 466. The acquisition is confirmed by the further IDS instance 34, signal 468. Upon obtaining this signal, the communications adapter 32 re-sends the request signal to the event manager 30 to override the last selected event 226, i.e., signal 470. This is done even if there are no new selected events 226 in this constellation, for example.

The other IDS instance 34 regains the timer interrupt, signal 472. The further IDS instance 34 then encrypts the last obtained encrypted event report 242 sent by the communication adapter 32 and sends it, possibly in vehicle-related relation with further event reports from further IDS systems, to the backend 36. The backend 36 sends a request to the further IDS instance 34 for an acknowledgement signal 476 and/or an event on which the release is based, etc.

In the communications sequence of FIG. 13, communications adapter 32 regains the timer interrupt, signal 480. This timer interrupt 480 may be a special signal that causes the communication adapter 32 to request an event summary (rather than one of the common event reports 242), signal 482, from the event manager 30. The event manager 30 sends the event summary to the communication adapter 32, signal 484. The event summary may contain superior information such as the occurrence of different counter readings 231 for different event types 218, or new event types, etc. The event digest is again also encrypted by the communication adapter 32 through a new changeable variable 254, such as a random number, and transmitted to the other IDS instance 34, signal 486. Once the IDS instance 34 obtains the encrypted event digest from the communication adapter 32, the further IDS instance 34 forwards the event digest to the backend 36, particularly preferably in encrypted form. In an embodiment, no timer interrupt is set for the transmission process between the further IDS instance 34 and the backend 36 to initiate the communication process. Alternatively, however, the communication process can be initiated periodically, as is the case with the sending of a common event report.

In the communication sequence of figure 14, the backend 36 sends a request for event reporting, signal 490, to the further IDS instance 34. The further IDS instance 34 sends an encrypted request for event reporting, signal 492, to the communication adapter 32, for example, through the diagnostic interface. The encryption may again be performed by a variable 254', such as a random number, which may be changed, in particular, for each encryption. After obtaining the request 492, the communication adapter 32 sends a query for the event report 242, signal 494, to the event manager 30. After obtaining corresponding query 494, event manager 30 sends event report 242, i.e., signal 496, to communications adapter 32. The communication adapter 32 encrypts the event report 242, e.g., via a new changeable variable 254 such as a random number, and sends the event report to the other IDS instance 34, signal 498. After obtaining the encrypted event report 242, the additional IDS instance 34 sends the event report 242 to the backend 36. The back end 36 acknowledges the acquisition, signal 492, to the further IDS instance 34. The additional IDS instance 34 acknowledges to the communication adapter 32 that an acknowledgement signal 492, signal 494, was obtained. After obtaining the corresponding signal 494, the communication adapter 32 sends a corresponding request to the event manager 30 to at least release or cover the event 220 transmitted within the scope of the last event report 242.

The described method can be implemented in a computing unit, computer or controller, in particular in a control device of the vehicle 18. Also, the method may be created within the scope of a computer program arranged to perform the method when it is executed on a computer. Further, the computer program may be stored on a machine-readable storage medium. However, the program can be loaded wirelessly as software "over the air" or by wire through a diagnostic interface, for example.

Claims (12)

1. Method for handling data anomalies, in particular in a motor vehicle, wherein at least one sensor (24, 26, 28) for identifying an anomaly acquires data (211), wherein the sensor (24, 26, 28) checks the acquired data (211) for the presence of an anomaly, in the event of an anomaly being identified an event (220, 221) is generated depending on the associated data (211), wherein it is decided whether the event (220, 221) is to be further processed, in particular stored and/or at least partially further transmitted.

2. A method according to claim 1, characterized in that it is decided randomly and/or depending on the number of occurrences of an event (220, 221) of a certain event type (218) whether the event (220, 221) is to be further processed.

3. The method according to any of the preceding claims, characterized in that when an event (220, 221) of a specific event type (218) occurs for the first time, the event (220, 221) is further processed.

4. A method according to any of the preceding claims, characterized in that for an event (220, 221) having an event type (218) that has occurred at a previous event (220, 221), it is randomly decided whether the event (220, 221) is to be further processed.

5. The method according to any of the preceding claims, characterized in that the associated number of respectively occurring events (220, 221) is determined for different event types (218).

6. The method according to any of the preceding claims, characterized in that different priority groups are respectively assigned to specific event types (218), wherein events (220) of a higher priority group are further processed, in particular randomly, with a higher probability than events (220) of a lower priority group.

7. A method according to any of the preceding claims, characterized in that different priority groups are assigned a specific offset (271) or range, respectively, from which at least one event (220) to be further processed of the respective priority group is selected, respectively, wherein the offset (271) or range of the priority group with higher priority is smaller than the offset (271) or range of the priority group with lower priority.

8. The method according to any of the preceding claims, characterized in that it is randomly decided from a plurality of events (220, 221) having the same event type (218) and/or priority group which event of the events (220, 221) having the same event type (218) and/or priority group to be further processed.

9. Method according to any of the preceding claims, characterized in that the random decision is made using a random number (273) and/or a range (273. X) of random numbers (273), in particular vehicle-specific and/or control device-specific random numbers (273).

10. Method according to any of the preceding claims, characterized in that the events (220, 221) to be further processed are at least partially stored in a memory (206, 208), in particular in a volatile memory (206) or a buffer memory and/or in a non-volatile memory (208) and/or in the scope of event reports (242), transmitted and/or equipped with further information, in particular general metadata (217), such as the number of events (220, 221) occurring, a time signal (274), the number of events (220, 221) not further processed, a length (232).

11. A method according to any of the preceding claims, characterized in that the events (220, 221) to be further processed are randomly selected from a certain number or offset (271) of events (220, 221).

12. Method according to any of the preceding claims, characterized in that a plurality of sensors (24, 26, 28) for identifying anomalies are provided, each sensor obtaining data (211) from a different data source (25, 27, 29), in particular a communication system and/or a host (29) or a microcontroller, wherein each sensor (24, 26, 28) checks the obtained data (211) for the presence of an anomaly, generates an event (220, 221) on the basis of the associated data (211) when an anomaly is identified, and forwards the event (220, 221) to an event manager (30).

Images