Method for protecting vehicle in terms of vehicle safety technology

Abstract

To provide a method for protecting a vehicle in terms of vehicle safety technology.SOLUTION: The present invention relates to a method for protecting a vehicle in terms of vehicle safety technology. Furthermore, the invention relates to a computer program, a device and a storage medium for this purpose.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to a method for information-technological protection of a vehicle. Furthermore, the invention relates to a computer program, an apparatus and a storage medium for this purpose. [Background technology]

[0002] In the field of IT security, in particular host-based and network-based solutions are already known, which, however, generally do not take into account, for example, personal safety. Furthermore, in many cases, for example, only detection services are widespread, or only basic defenses of IT security risks, which are for example only performed offline and not while the vehicle is in operation. It may also often be the case that defense mechanisms against detected security risks are not yet available, and the detected security risks remain until an update, which makes it impossible to use the vehicle, for example, until the detected security risk is eliminated. In the prior art, in particular detection (IDS) is followed by response (IPS), with the response being what is possible from the point of view of attack security and seems necessary at the time. However, in particular in the automotive context, it may be necessary to take into account not only attack security, but also personal safety and here possibly further non-functional properties such as availability and reliability.

[0003] In the context of the present invention, personal safety preferably concerns the avoidance of personal injury, and attack security concerns the avoidance of attacks on the vehicle, in particular attacks on the vehicle's software and hardware. Summary of the Invention

[0004] The subject of the present invention is a method with the features of claim 1, a computer program with the features of claim 8, an apparatus with the features of claim 9 and a computer-readable storage medium with the features of claim 10. Further features and details of the invention emerge from the respective dependent claims, the description and the drawings. Features and details stated in relation to the method according to the invention naturally also apply in relation to the computer program according to the invention, the apparatus according to the invention and the computer-readable storage medium according to the invention and vice versa, respectively, and therefore are or can always be cross-referenced with respect to the disclosure of the individual aspects of the invention.

[0005] The subject of the invention is in particular a method for vehicle safety-technical protection of a vehicle, comprising: - detecting an attack on the vehicle by a detection module, the detection module providing a description of the attack; - evaluating the description of the attack by a decision module, the decision module evaluating at least one measure against the attack based on a personal safety provision and an attack security provision; The personal safety provision represents the safety of at least one occupant of the vehicle or at least one road user, and the attack security provision represents the safety against an attack on the vehicle; providing instructions for taking at least one action based on the evaluation; Steps and - executing, by an execution module, at least one action based on the provided instructions, the execution module adjusting the provided instructions; The method includes:

[0006] A personal safety provision may be, for example, a provision of a specification or rule formulated with respect to the safety of at least one occupant of a vehicle or at least one road user. Here, simply, it may be ensured that a vehicle can continue to operate or travel such that, for example, an accident does not endanger at least one occupant or at least one road user. The at least one road user may be, for example, a pedestrian or a driver of another vehicle. Furthermore, personal safety may concern aspects such as the reliability and / or availability of a vehicle, since these aspects may also affect at least one occupant or at least one road user. Here, in general, the reliability of a technical product or system is a characteristic that indicates, in particular, how reliably a function assigned to the product or system is fulfilled within a certain time interval. In general, the availability of a technical system is, in particular, the probability or degree to which a system fulfills certain requirements at a certain time or within an agreed time frame. An attack security provision may be, for example, a provision of a specification or rule formulated with respect to security against attacks on a vehicle. Here, for example, financial, legal or data protection aspects may also be taken into account. The combination of attack security and personal safety can be called vehicle safety, and this combined protection provides in particular vehicle-technical protection of the vehicle. The attack can be of information-technical or electronic nature, for example a hacking attack. The measures are, for example, disabling a process on the system being attacked, or reconfiguring a firewall. The instructions can include one or more measures and can further indicate, for example, the purpose of the measures and / or a time provision for executing the measures. The execution module can advantageously send a feedback to the decision module, for example after the execution of the measures. A method including at least the above-mentioned steps can be advantageous to take into account both attack security (i.e. security) and personal safety (i.e. safety) in the context of a motor vehicle. Thus, further advantageously, possible measures that take these goals into account can be found and executed during a function (e.g. autonomous driving).The detection module and / or the decision module and / or the execution module can advantageously call up or send information to the vehicle state. The vehicle state can be considered as a black box that encapsulates relevant status information. Urgent information can be exchanged via a direct feedback loop available between the functional groups of the decision module and the execution module. Furthermore, the detection module and / or the decision module and / or the execution module can advantageously have a connection to a Vehicle Security Operations Center (VSOC). The VSOC is preferably a back-end service and can receive information about potential attacks from the functional group of the detection module, information about defense measures that have been invoked from the functional group of the decision module, and information about successfully executed defense measures from the functional group of the execution module. In the VSOC, information from all vehicles of the fleet can be processed (e.g. also manually by security experts).

[0007] Within the scope of the present invention, detection is - monitoring the vehicle by means of at least one sensor, whereby at least events in the vehicle are recorded by the at least one sensor, the events being characteristic of the possible presence of an attack on the vehicle; It may be advantageous to further comprise:

[0008] At least one sensor may be attached to an element of the vehicle architecture, where the at least one sensor may perform measurements of the vehicle's environment or the vehicle itself, in particular at least one functionally relevant part of the vehicle. Exemplary functions of the at least one sensor may be accessing protocols, invoking the at least one sensor by hooking or triggering, or reading the vehicle's network traffic. Furthermore, the at least one sensor may also capture various status information of the vehicle. The at least one sensor may advantageously collect a number of data relevant to the detection and description of attacks based on events and status information.

[0009] Furthermore, detection - filtering the recorded events to provide a selection of the recorded events as eligible events, the eligible events being identified by the filter using at least one defined criterion, the at least one defined criterion being specific to the possible presence of an attack on the vehicle. It is contemplated that the present invention may further include the following.

[0010] At least one criterion may be a collection of events or status information, which may be known from expert knowledge or past execution of the method. It is also conceivable that an event must exceed a defined threshold or occur a defined number of times in order to be provided by the filter as a qualifying event. Thus, the filter may advantageously provide a pre-selection, reducing the amount of data sent for further calculations and thus increasing, for example, the calculation performance. This may advantageously provide real-time applications.

[0011] Optionally, the detection comprises: - analyzing the events, in particular the qualified events, by a recognition module and classifying the events, in particular the qualified events, as attacks by the recognition module based on deviations from at least one defined attack signature and / or expected behavior. It is also possible that the above-mentioned formula (1) is further included.

[0012] The recognition module can be based on various pattern recognition techniques to which machine learning models can be applied, and advantageously allows to accurately determine whether an attack on the vehicle has occurred with a high probability, which requires the implementation of measures.

[0013] The evaluation is, - providing or evaluating at least one measure by an attack security controller of the decision module, the attack security controller providing or evaluating at least one measure based on a description of the attack, taking into account the attack security provisions; - providing or evaluating at least one measure by a personal safety controller of the decision module, the personal safety controller providing or evaluating at least one measure based on a description of the attack, taking into account personal safety provisions; It may also be possible to further include at least one of:

[0014] A separate provision and / or evaluation of at least one measure by the attack security controller and the personal safety controller advantageously allows for an improved individual consideration of attack security provisions and personal safety provisions. In the context of the present invention, a "controller" may for example be configured as a software module.

[0015] Within the scope of the present invention, the evaluation - providing instructions for the execution of at least one measure by a mediator module of the decision module, the mediator module communicating with the attack security controller and the personal safety controller to provide instructions taking into account the attack security provisions and the personal safety provisions. Further advantages are realizable when the method further includes:

[0016] Thus, in short, the mediator module can advantageously assume a mediation function in order to take into account both the requirements of the offensive security controller and the requirements of the personal safety controller. It can be arranged that the requirements of the personal safety controller have priority and are subordinated to the requirements of the offensive security controller only in exceptional cases. Multiple iterations of communication between the offensive security controller and the personal safety controller can be provided by the mediator module in order to find an optimal solution with at least one measure.

[0017] Within the scope of the present invention, the implementation - monitoring and adjusting the provided instructions by a corresponding controller of the execution module, the corresponding controller being connected to at least one actuator, and the action being executed by the at least one actuator. Further advantages can be achieved when the composition further comprises:

[0018] The response controller can monitor and regulate the execution of the instructions and plan and regulate the individual actions of the actuators. The response controller can ensure that potential prerequisites (e.g. regarding the vehicle state) for the action are met. At least one actuator is responsible in particular for the execution of individual parts of the action. In an alternative, the execution of the action can be performed by multiple distributed actuators. Exemplary actions executed by at least one actuator are termination of a process, modification of a firewall configuration, intentional or deliberate reduction of functionality, restoration or securing of functionality. It can be contemplated that the response controller and / or the at least one actuator are configured to send feedback. The feedback by the at least one actuator can be sent to the response controller after the at least one action is executed. The response controller can further send feedback of the actuator or further feedback to the decision module after the at least one action is executed.

[0019] The vehicle may be configured as, for example, an automobile and / or a passenger car and / or an autonomous vehicle. The vehicle may be equipped with vehicle equipment for providing, for example, autonomous driving functions and / or driver assistance systems. The vehicle equipment may be configured to control and / or accelerate and / or decelerate and / or steer the vehicle in an at least partially automated manner.

[0020] A subject of the invention is also a computer program, in particular a computer program product, comprising instructions which cause a computer to carry out the method according to the invention when said computer program is executed by a computer. The computer program according to the invention therefore offers the same advantages as those detailed with reference to the method according to the invention.

[0021] The subject of the invention is also a data processing device designed to carry out the method according to the invention. As this device, for example, a computer running the computer program according to the invention can be considered. The computer can comprise at least one processor for executing the computer program. It is also possible to provide a non-volatile data memory in which the computer program is stored and from which it can be read by the processor for execution.

[0022] A subject of the invention may also be a computer-readable storage medium comprising a computer program according to the invention and / or containing instructions which, when executed by a computer, cause the computer to carry out the method according to the invention. The storage medium is configured, for example, as a data storage device, such as a hard disk and / or a non-volatile memory and / or a memory card. The storage medium may, for example, be integrated into the computer.

[0023] Additionally, the methods according to the present invention may be performed as computer-implemented methods. Further advantages, features and details of the invention will become apparent from the following description, in which exemplary embodiments of the invention are described in detail with reference to the drawings, in which the features claimed and described herein may each individually or in any combination be essential to the invention. [Brief description of the drawings]

[0024] [Figure 1] 1 is a schematic diagram of a method, a vehicle, an apparatus, a storage medium, and a computer program according to an exemplary embodiment of the present invention. [Diagram 2] FIG. 1 is a schematic diagram of an intrusion detection and prevention system (IDPS) according to an exemplary embodiment of the present invention. [Diagram 3] FIG. 2 is a schematic diagram of a process for defending against an attack according to an exemplary embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0025] In FIG. 1 a method 100 according to an exemplary embodiment of the invention, a vehicle 1, an apparatus 10, a storage medium 15 and a computer program 20 are diagrammatically shown. According to the exemplary embodiment of FIG. 1, the method 100 for information-technological protection of a vehicle 1 comprises a first method step 101, in which an attack on the vehicle 1 is detected by the detection module 5. Here, an attack description 17 is provided by the detection module 5. In a second method step 102, the attack description 17 is evaluated by the decision module 8. Here, the decision module 8 evaluates at least one measure against the attack based on personal safety and attack security. Here, personal safety represents the safety of at least one occupant of the vehicle 1 or at least one road user, and attack security represents security against an attack on the vehicle 1. Based on the evaluation, instructions for performing at least one measure are provided. In a third method step 103, at least one measure is performed by the execution module 13 based on the provided instructions, which execution module 13 adjusts the provided instructions.

[0026] The following description will refer specifically, at least in part, to the exemplary embodiment of FIGS. In the context of the present invention, an in-vehicle IDPS is specifically logically divided into three blocks, which can be further divided into individual logical components, as shown in FIG. 2. It should be noted that this diagram preferably illustrates only logical connections and functional dependencies, and does not impose any restrictions on the number or location of individual components or functional elements. In a concrete IDPS instantiation of this functional chain, individual logical components may appear in multiple (distributed) instances, and the functionality of multiple logical components may be covered by a single component. The functional elements can be connected to each other in different ways in multiple distributed forms and can be distributed in various vehicle architectures.

[0027] The functional group Detection Module 5 can observe, process and analyze events to determine whether the system is under attack. When an attack is recognized, an attack report is created which may preferably correspond to an attack description 17. The attack description 17 may also provide information regarding the security or probability of a potential attack, for example for a self-learning system. The functional group Detection Module 5 can be divided into the following functional elements:

[0028] The functional element Sensor 2 preferably records all events that may contain Indicators of Compromise (IoC), i.e. events that may indicate a potential intrusion or intervention, as well as other relevant status information. Sensor 2 may perform observation or monitoring of the system. The task of Sensor 2 is in particular to collect and transmit event information.

[0029] The functional element Filter 3 preferably processes events from one or more sensors and identifies whether an event can be considered an IoC and whether it should be sent further. Filter 3 preferably performs a pre-selection of events relevant for this decision (i.e., a minimum of information transmission and processing load). Filter 3 can also forward status information from the sensors that is not necessarily considered an IoC but contains relevant information required by the Recognition Module 4 to determine whether the system is under attack. The term "qualifying events" can be used for the events processed by Filter 3 (note: since Sensor 2 collects unfiltered events, Filter 3 is particularly responsible for discarding irrelevant events, thereby reducing the amount of information that needs to be transmitted and processed in subsequent steps).

[0030] The functional element, the recognition module 4, is preferably able to process the qualifying events from the filter(s) 3 and possibly the current vehicle state 14 and identify whether these observations should be classified as attacks. Different recognition methods can be used for this classification, which are essentially based on matching known attack signatures (signature-based) or on recognizing deviations from expected behavior (anomaly-based). If the recognition module 4 determines that the system, i.e. in particular the vehicle 1, is under attack, it preferably creates an attack description 17 including the details of the attack. For example, the recognition module 4 receives at its input an event reporting an attempt to access a restricted resource and decides to classify this as an attack. The recognition module 4 can then create an attack description 17 including information about the affected resource and the responsible process.

[0031] If the vehicle 1 already has an IDS solution, possibly provided by a third party, this can be integrated into the IDPS architecture. Such a solution can be assumed to behave like a black box that outputs information as soon as it recognizes an attack. An adapter can then convert this information into an input that the recognition module 4 can understand.

[0032] The functional group decision module 8 receives the attack description 17 from the functional group detection module 5, possibly checks the current vehicle state 14 and decides whether a response is necessary. If a response is necessary, IDPS defensive measures can be selected and checked for the respective attack security and personal safety features. In some cases, the best IDPS defensive measures can be selected from the point of view of attack security and checked from the point of view of personal safety. If this check fails in at least one respect, alternative IDPS defensive measures can be selected, if possible, that achieve the defensive objective in another way. It may also be the case that no such defensive measures are found and existing measures from the safety concept (of the vehicle 1 or the control device) can be executed. This is also the case when time constraints such as fault-tolerant time intervals (FTTI) related to personal safety must be observed. In particular, such a response consists of a combination of IDPS defensive measures executed in a certain order. These selected measures are preferably further sent in the form of a detailed instruction sequence to the response controller 9, which further provides feedback on the executed IDPS defensive measures.

[0033] The functional group decision module 8 can be divided, for example, into the following functional elements which are able to agree on the action to be taken: The attack security controller 6, which is a functional element, preferably has the task of deciding which IDPS defensive measures should be selected from an attack security perspective, i.e., which are the most effective steps to thwart the attack and limit its consequences. In one example, the attack security controller 6 decides to disable the architectural element from which the attack originates (e.g., external communications).

[0034] The functional element, personal safety controller 7, can ensure that IDPS defensive measures do not impair the safety of vehicle 1, i.e. in particular personal safety. The personal safety controller 7 can also propose defensive measures, for example from an existing safety concept. In this way, the personal safety controller 7 can in particular determine and check which IDPS defensive measures constitute a safe situation for use and, finally, can also block certain measures if the requirements are not met. If a fast security response to an attack is required (i.e. in particular compliance with the FTTI security provisions), the personal safety controller 7 can activate defensive measures preferentially, i.e. from an existing safety concept. By way of example, under the assumption that the disabling of an architectural element violates the safety concept, the personal safety controller 7 finds concomitant or alternative steps (i.e. IDPS defensive measures) to keep vehicle 1 safe and finally, if possible, the architectural element is disabled upon request from the personal safety controller 7.

[0035] The functional element Mediator 11 can coordinate the communication between the functions responsible for personal safety and attack security, and is in particular responsible for the final decision on the proposed defensive measures. In the context of the present invention, Mediator 11 is also synonymously called Mediator module. Mediator 11 preferably also creates a list of IDPS defensive measures (possibly several possible lists in parallel), Mediator 11 respecting constraints, in particular in terms of the safety schedule. In this case, Mediator 11 can also further send part of the list to Execution module 13, taking into account its feedback.

[0036] Functional group Execution Module 13 is preferably responsible for executing the IDPS defensive actions decided upon by functional group Decision Module 8. Functional group Execution Module 13 may also provide feedback if execution is delayed for any reason or is not possible at all. Status feedback regarding the progress of the execution may also be useful to Decision Module 8. This functional group can be divided into the following functional elements:

[0037] The functional element Response Controller 9 may in particular receive the instruction sequence and be responsible for coordinating and scheduling the individual steps of the IDPS defense measures by the actuators. The Response Controller 9 preferably ensures that each measure is executed only if given preconditions from the decision are fulfilled, taking into account the vehicle state 14. Furthermore, the Response Controller 9 preferably provides feedback on the executed measures to the functional group Detection Module 5. By way of example, if a measure consists of several steps, which are interdependent and must be executed in a certain order, the Response Controller 9 may monitor the execution of the individual steps and adjust the actions of the actuators accordingly.

[0038] A functional element, the actuator 12, preferably receives respective instructions for defensive measures, executes these instructions accordingly and provides feedback regarding its execution to the corresponding controller 9. By way of example, the actuator 12 may be instructed to terminate a process or to reconfigure firewall settings, i.e. to blacklist an IP address.

[0039] In addition to the functional groups and elements of the in-vehicle IDPS functional chain, Figure 2 also shows the connections, among others, to the vehicle state 14. The vehicle state 14 can be considered as a black box that encapsulates the status information relevant to the IDPS system. However, all urgent information can be exchanged via the direct feedback loop available between the functional groups Decision Module 8 and Execution Module 13. The vehicle state 14 can also be used to synchronize multiple instances of the IDPS functional chain, especially if the emphasis is on different aspects, e.g. vehicle functional aspects to be considered within the IDPS chain of vehicle architecture elements and vice versa. Examples in this regard are, among others, the current driving situation, actuator status, security state, firewall configuration, diagnostic mode, software / firmware versions.

[0040] FIG. 2 also shows, in particular, a connection to a Vehicle Security Operations Center (VSOC 16). VSOC 16 is preferably a back-end service and can receive information about potential attacks from the functional group Detection Module 5, information about triggered defensive measures from the functional group Decision Module 8, and information about successfully executed defensive measures from the functional group Execution Module 13. In VSOC 16, information from all vehicles 1 of the fleet can be processed (e.g. manually by security experts). If the analysis reveals an attack that requires a fleet-wide response, VSOC 16 can send corresponding instructions to the functional group Decision Module 8 of the individual vehicles 1. In particular, VSOC 16 is not a key component of the in-vehicle IDPS functional chain, but an element of an IDPS in a fleet-wide framework.

[0041] In fact, a single component may take on the tasks of multiple logical components. As an example, in a network-based IDPS, Sensor 2 may observe the entire network traffic. Instead of duplicating the entire traffic and forwarding it to Filter 3, it may be advantageous to combine Sensor 2 with Filter 3 to reduce the number of messages forwarded.

[0042] Additionally, in an IDPS, there may be multiple instances of a single component as a complement or to provide redundancy as the architecture is distributed across various physical (or virtual) components.

[0043] If solutions already exist for individual functional elements or functional groups of the function chain (e.g. AutoSAR or standalone IDS solutions for Linux), they can be integrated by user-defined adapter elements that enable interfacing to other functional elements or groups of the function chain.

[0044] Regarding the input, the sensor 2 is preferably attached to an element of the vehicle architecture, where the sensor 2 can make observations of the environment. In particular no further explicit inputs are made. The output of the sensor 2 can be an event resulting from the observations made by the sensor 2. The sensor 2 reports its observations, for example in a specific format. The sensor 2 can be influenced by its observations. The sensor 2 can be stateless and not take into account the state of the vehicle 1. The sensor 2 preferably observes activities at the elements of the vehicle architecture and collects information. The sensor 2 generates events that can be further processed by the filter 3 or the recognition module 4. Exemplary functions of the sensor 2 can be accessing protocols, firing the sensor 2 by hooks or triggers, or reading network traffic.

[0045] The input of the Filter 3 may be the events reported by the Sensor 2. The output may be the qualified events. For each received event, the Filter 3 may decide, possibly based on inputs from multiple sensors, whether the event can be considered an IoC or relevant status information required by the Recognition Module 4 and therefore should be forwarded as a qualified event. If not, e.g. when the event is considered not relevant (i.e. not an IoC), the event is not forwarded. The Filter 3 may be state-dependent (i.e. has local state that may affect its decision), but is preferably independent of the vehicle state 14. The Filter 3 may also output a reliability assessment based on a self-learning algorithm. The Filter 3 preferably identifies IoCs and other status information at the input and forwards only the relevant ones as output. This pre-selection may significantly reduce the number of qualified events forwarded to the Recognition Module 4 for further analysis. An exemplary function is the reception of static sensor inputs.

[0046] Here, it can be provided that the forwarding of an event as a qualified event only occurs if a threshold value (e.g. n=10) is reached, thus advantageously reducing the data traffic to the recognition module 4 (e.g. by 10%).

[0047] The input of the recognition module 4 may be a qualifying event from the sensor 2. The output may be an attack description 17, the description 17 including detailed information about the attack (including the architectural elements affected, the sensors and filters 3 involved, and optionally a confidence level). The recognition module 4 may use a combination of different recognition methods to determine whether the observed system is under attack and derive additional information if so. Each recognition method may use (part of) the input, the local state of the recognition module 4, and / or the vehicle state 14. Each attack description 17 is output with all relevant details about the attack, such details may also include a confidence level in order to make a decision as soon as possible. The recognition module 4 determines, among other things, whether the observed system is under attack. Once an attack is confirmed, the recognition module 4 creates an attack description 17, preferably including all relevant details about the attack. An exemplary functionality is the use, among other things, of different techniques (e.g. pattern recognition, outlier / anomaly recognition, artificial intelligence) to recognize the attack, on the received input.

[0048] The input of the attack security controller 6 can be the attack description 17, the notification of the mediator 11 (optionally the vehicle state 14 and VSOC 16), and / or the feedback of the response controller 9. The output can be the notification to the mediator 11 (optionally the vehicle state 14 and VSOC 16). When an attack is reported, the attack security controller 6 preferably uses the information obtained from the attack description 17, and optionally the vehicle state 14 and VSOC 16, as a basis for a decision on the appropriate IDPS defensive action. The attack security controller 6 can communicate with the mediator 11, which can further communicate with the personal safety controller 7. The attack security controller 6 preferably does not send the IDPS defensive action to the execution module 13 independently, but only through the mediator 11 to verify the personal safety. The attack security controller 6 preferably decides which IDPS defensive action (from the attack security point of view) should be taken to mitigate the reported attack and achieve a safe state. The attacking security controller 6 can do this (i.e., stay safe) in coordination with the mediator 11, repeating or alternating IDPS defensive actions as necessary. Example functions are disabling processes on the system under attack, reconfiguring a firewall (e.g., blacklists), or invoking a series of individual actions.

[0049] The inputs of the personal safety controller 7 can be the attack description 17, the notification of the mediator 11 (optionally the vehicle state 14 and VSOC 16), the response controller 9 feedback, and the output communication to the mediator 11 (optionally the vehicle state 14 and VSOC 16). Before IDPS defensive actions are invoked against an attack, the personal safety controller 7 can be queried by the mediator 11 and can suggest alternative or additional defensive actions for safety reasons. The personal safety controller 7 makes a decision, for example, relying on the input of the mediator 11 and optionally the vehicle state 14 and VSOC 16. However, the personal safety controller 7 preferably cannot make the final decision autonomously, but can coordinate with the mediator 11, which in turn coordinates with the attack security controller 6. The personal safety controller 7 is responsible for ensuring a safe state, particularly with respect to the occupants of the vehicle 1, and preferably does not allow IDPS defensive actions that compromise the safety of the vehicle 1, particularly with respect to the occupants of the vehicle 1. If urgent IDPS defensive measures are required for the reported attack, the personal safety controller 7 can propose to the mediator 11 appropriate defensive measures that must be activated within a given time, as far as the personal safety aspect allows. The personal safety controller 7 preferably has the task of ensuring that the IDPS defensive measures do not compromise the safety of the vehicle 1, i.e., in particular that the occupants of the vehicle 1 are protected, for example, from accidents. Furthermore, the personal safety controller 7 can take measures to maintain and / or restore the safety of the vehicle 1 or personal safety, if it is compromised by an attack. An exemplary function is to propose a set of concomitant IDPS defensive measures to guarantee personal safety, in particular if the IDPS defensive measures are urgent (i.e. FTTI).

[0050] The input of the mediator 11 (which may be synonymously referred to as the mediator module 11 in the context of the present invention) may be an attack description 17, a notification of the attacking security controller 6 or the personal safety controller 7 (optionally the vehicle state 14 and the VSOC 16), or a feedback of the response controller 9. The output may be a notification to the attacking security controller 6 and the personal safety controller 7 (optionally the vehicle state 14 and the VSOC 16), as well as an instruction sequence for the response controller 9. Upon receiving the attack description 17, the mediator 11 communicates with the attacking security controller 6 and the personal safety controller 7, if possible, to adjust the IDPS defensive measures. Based on this communication, the mediator 11 may send a corresponding instruction sequence to the response controller 9. If the personal safety controller 7 requests the execution of IDPS defensive measures within a certain time interval, the mediator 11 must preferably fulfill this request and forward it to the execution module 13 as soon as possible. The mediator 11 may communicate with the attacking security controller 6 and the personal safety controller 7, among others, to collect possible instruction sequences that can be forwarded to the response controller 9. An exemplary function is to collect communications between the attack security controller 6 and the personal safety controller 7 and to output corresponding instructions until an appropriate sequence of measures has been determined (or a temporary solution is preferred for time reasons, e.g. FTTI).

[0051] The input of the execution module 13 may be an instruction sequence (optionally vehicle state 14) for executing IDPS defensive measures. The output may include instructions for actuators, feedback to functional groups for defensive instructions (optionally vehicle state 14 and VSOC 16). The response controller 9 may monitor and regulate the execution of received IDPS defensive instructions. The response controller 9 may plan and regulate the actions of the actuators. The response controller 9 may ensure that all potential prerequisites (e.g. with respect to vehicle state 14) for IDPS defensive measures are met. As soon as an instruction sequence is invoked, it may be resolved completely or feedback on an interrupt may be given to the decision module 8 to resolve the problem. The response controller 9 is in charge of, among other things, coordinating the implementation of IDPS defensive measures.

[0052] Exemplary functions are to trigger execution of IDPS defensive steps only after the completion of the previous step, and to trigger and coordinate (possibly in parallel) execution of IDP defensive steps.

[0053] The actuator 12 inputs can be instructions to execute IDPS defensive actions. The outputs can be feedback to the response controller 9 (and optionally the vehicle status 14 and VSOC 16). The actuator 12 preferably executes received instructions and can provide feedback to the response controller 9 regarding the completion or cancellation of an action. The actuator 12 is specifically responsible for the execution of individual "atomic pieces" of IDPS defensive actions. Exemplary functions are terminating a process, changing a firewall configuration, degrading functionality, restoring or guaranteeing functionality.

[0054] The vehicle 1 should preferably always be in a safe state. Thus, a key point in an on-board IDPS may be the impact on personal safety and attack security, and thus their interaction. Ultimately, the goal of both areas may be to ensure a safe and uncompromised experience for road users, but attack security is, in particular, to protect the vehicle 1 from any kind of malicious damage, and personal safety is, in particular, to prevent any kind of personal injury. Basically, it may be in the interest of personal safety to prevent attacks on the vehicle 1, but there may be cases where the corresponding actions for the best IDPS defense in terms of attack security are not immediately safe to perform (e.g., turning off critical vehicle functions and / or autonomous vehicle functions to stave off attacks when traveling at high speeds), and therefore additional IDPS defense actions are necessary to achieve a safe state with respect to personal safety. On the other hand, there may also be cases where personal safety-oriented IDPS defense actions may undermine attack security, for example by opening a backup communication channel to a compromised architectural element that is intentionally isolated. Thus, there are trade-offs, particularly between personal safety and attack security, that must be weighed, preferably very carefully, within the scope of each, taking into account all constraints, ultimately resulting in a list of IDPS defensive measures to be implemented.

[0055] The functional element, attack security controller 6, preferably tracks the current attack security state of vehicle 1 and can ensure that in the event of an attack, the IDPS defense measures used keep the system safe with respect to attack security.

[0056] The functional element, personal safety controller 7, tracks the current personal safety related state of vehicle 1 and can initiate IDPS defensive measures to ensure that vehicle 1 remains safe with respect to personal safety. Thus, personal safety controller 7 can suggest IDPS defensive measures and provide the conditions under which IDPS defensive measures can be safely employed.

[0057] Ideally, appropriate (i.e., safe) IDPS defensive actions could be statically identified for a particular attack scenario and vehicle state, facilitating coordination between personal safety and attack security states by each control device and initiating the appropriate IDPS defensive actions.

[0058] In cases where this simple solution is not possible, measures to defend or block attacks can be established and decided dynamically. The two controllers responsible for processing must negotiate (coordinated and supervised by a mediator 11) as to which mechanisms will be applied to defend or block an intrusion or attack.

[0059] One possibility for the process in the functional group Decision Module 8 is shown in FIG. 3. The functional group Decision Module 8, and therefore all functional elements of this group, preferably receives the attack description 17 from the detection module 5, which starts the decision process. The attack security controller 6 and the personal safety controller 7 analyze the attack description 17, respectively (61, 71). If a response is required (18), which may be required whenever there is a possibility of an attack, the attack security controller 6 proposes appropriate IDPS defensive measures (19), which the personal safety controller 7 can check to ensure that the execution of the selected measures does not compromise the safety state with respect to personal safety (22). If the IDPS defensive measures cannot be safely executed in the current vehicle state 14, the personal safety controller 7 can add personal safety-related IDPS defensive measures (19), if possible, to enable the execution of the IDPS defensive measures. These additional personal safety-related IDPS defensive measures can be checked again by the attack security controller 6 to ensure that the vehicle security state is not further compromised (21). However, such violations may be tolerated if additional IDPS defensive measures are later added to restore the vehicle security state. This iteration (checking by the personal safety controller 7) may be repeated for as long as possible until there are no further violations of the personal safety state and the vehicle security state. As soon as such a match is found, an IDPS defensive measure (or a portion of this list) may be invoked (27).

[0060] 3 further shows a mediator 11 with multiple lists 23, 24, 25 of IDPS defensive actions. These may result from repeated communication between the attack security controller 6 and the personal safety controller 7, where actions are added to the lists 23, 24, 25 (26) after checking, among other things, whether the vehicle security state and the personal safety state, respectively, are ensured. Part of the mediator 11 may be a decision algorithm 28.

[0061] If no agreement can be reached in this way, IDPS defensive measures preferably cannot be activated, and such cases may be reported to VSOC16 for analysis of why no viable solution was found to mitigate the attack based on the reports received.

[0062] If an urgent response is required, the personal safety controller 7 can initiate such IDPS defensive measures through the mediator 11 with the required priority. The above description of the embodiments describes the invention only by way of example. Naturally, the individual features of the embodiments can be freely combined with one another, insofar as this is technically meaningful, without departing from the scope of the invention. [Explanation of symbols]

[0063] 1 vehicle 2 Sensors 3. Filters 4 Recognition Module 5. Detection Module 6. Attack Security Controller 7 Personal Safety Controller 8 Decision Module 9 Compatible Controllers 10 Computers, equipment 11 Mediator, Mediator Module 12 Actuator 13 Execution Module 14 Vehicle condition 15 Computer-readable storage medium 16 Vehicle Security Operations Center (VSOC) 17 Description of the attack 20 Computer Programs 23, 24, 25 List 28 Decision Algorithms 100 ways 101 Detection, first method step 102 Evaluation, second method step 103 Performing the third method step

Claims

1. A method (100) for vehicle safety-technical protection of a vehicle (1), comprising: - detecting (101) an attack on said vehicle (1) by a detection module (5), said detection module (5) providing a description (17) of said attack; - evaluating (102) said description (17) of said attack by a decision module (8), said decision module (8) evaluating at least one measure against said attack on the basis of personal safety provisions and attack security provisions, The personal safety provision represents the safety of at least one occupant or at least one road user of the vehicle (1), and the attack security provision represents the security against the attack on the vehicle (1), providing instructions for performing the at least one action based on the evaluation. Steps and - executing (103) said at least one action based on said provided instructions by an execution module (13), said execution module (13) adjusting said provided instructions; The method includes:

2. The detection (101) monitoring said vehicle (1) by means of at least one sensor (2), by means of which at least events in said vehicle (1) are recorded, said events being characteristic of the possible presence of said attack on said vehicle (1); The method (100) of claim 1 further comprising:

3. The detection (101) - filtering (3) the recorded events to provide a selection of the recorded events as eligible events, the eligible events being identified by a filter (3) using at least one defined criterion, the at least one defined criterion being specific to the possible presence of the attack on the vehicle (1). The method (100) of claim 2 further comprising:

4. The detection (101) - analyzing said events, in particular said qualified events, by a recognition module (4) and classifying said events, in particular said qualified events, as attacks by said recognition module (4) based on deviations from at least one defined attack signature and / or expected behavior. The method (100) according to claim 2 or 3, further comprising:

5. The evaluation (102) - providing or evaluating said at least one measure by an attack security controller (6) of said decision module (8), said attack security controller (6) providing or evaluating said at least one measure on the basis of said description (17) of said attack, taking into account said attack security provisions; - providing or evaluating said at least one measure by a personal safety controller (7) of said decision module (8), said personal safety controller (7) providing or evaluating said at least one measure on the basis of said description (17) of said attack, taking into account said personal safety provisions; The method (100) of any one of claims 1 to 4, further comprising at least one of:

6. The evaluation (102) providing said instructions for said execution of said at least one measure by a mediator module (11) of said decision module (8), said mediator module (11) communicating with said attack security controller (6) and said personal safety controller (7) and providing said instructions taking into account said attack security provisions and said personal safety provisions. The method (100) of claim 5 further comprising:

7. The execution (103), - monitoring and adjusting said provided instructions by a corresponding controller (9) of said execution module (13), said corresponding controller (9) being connected to at least one actuator (12) by means of which said actions are executed; The method (100) of any one of claims 1 to 6, further comprising:

8. A computer program (20) comprising instructions which, when executed by a computer (10), cause the computer (10) to carry out the method (100) of any one of claims 1 to 7.

9. A data processing apparatus (10) designed to carry out a method (100) according to any one of claims 1 to 7.

10. A computer-readable storage medium (15) comprising instructions which, when executed by a computer (10), cause the computer (10) to perform the steps of the method (100) of any one of claims 1 to 7.

Images