Method for security check of a technical unit

Abstract

A method for a security check of a technical unit (1), wherein at least one first plausible model variant and, if necessary, a plurality of alternative model variants are determined, wherein the method is implemented on a test computer system (2) and wherein the method has the following steps: assigning known weaknesses to the components of the model variants; defining attack targets; creating at least one attack model related to the attack targets for each model variant; weighting the nodes of the attack model according to at least one evaluation variable; determining an evaluation of at least one test vector of the attack model with respect to the evaluation variable; determining a security value as the pessimistic value of all evaluations, and outputting a security confirmation when the security value meets a security criterion.

Description

[0001] This disclosure relates to a method for security checks of technical units implemented on a test computer system, a method for determining at least one reasonable configuration of technical units, a computer program product, and a test computer system.

[0002] Modern technological devices, particularly vehicles, possess a degree of complexity, comprising multiple embedded and interconnected components, each equipped with its own processor or microcontroller. However, this disclosure is not limited to vehicles but can also be used in conjunction with other units and technological devices having multiple interconnected components and collectively referred to herein as “technical units.” Other combinations of different devices are examples of technical units. For instance, a specific task may be performed by an autonomous computer unit (such as a tablet or smartphone) that communicates with another unit (such as an autonomous vehicle), for example, as a driving recorder. On the other hand, multiple vehicles may also communicate with each other (e.g., via radio) to perform common tasks, be coupled to each other in a manner such as a virtual tow bar, or a unit (e.g., a specialized vehicle in fields such as construction, agriculture, or emergency services) may be connected to one or more onboard devices. Such combined units can be considered technical units in the context of this disclosure.

[0003] Components of such technology units typically have their own memory and communication interfaces, and therefore can each be considered a separate computer system. These components are also known as "Embedded Systems (ES)" or "Cyber-Physical Systems (CPS)." The complexity of such technology units quickly becomes unreasonably high. For example, vehicles often have dozens of controllers, on which software with tens of millions of lines of code is implemented. The various wireless connectivity protocols used simultaneously can be cited as examples of communication interfaces. Due to the complexity and diversity of communication interfaces, a large attack surface ("Attack Surface") is formed against such vehicles. Here, attacks can be carried out not only via the actual communication interfaces but also, for example, via sensors (such as LiDAR or radar systems). For example, attacks can be launched using spoofed signals or by means of DoS / flooding.

[0004] In conjunction with this disclosure, an event that acts on the outside or inside of a technology unit is referred to as a “cyberattack”, the purpose of which is to influence the technology unit in an unauthorized manner and / or to forward the technology unit’s data to a third party in an unauthorized manner.

[0005] Such attacks could pose enormous potential risks due to the physical capabilities of vehicles (mass and speed, resulting high kinetic energy, and the potential for direct interaction with many people), their large numbers (convoys), and the development towards autonomous vehicles. This involves not only large numbers of land vehicles (such as cars, trucks, or rail vehicles) but also ships and aircraft.

[0006] This disclosure aims to protect such vehicles and other technological units from cyberattacks and contribute to their resilience. In conjunction with this disclosure, the ability of a technological unit to continue producing the intended results regardless of events that occur, such as cyberattacks, is referred to as "resilience."

[0007] To protect technical units from cyberattacks and make them resilient, it is effective to prevent vulnerabilities in development as much as possible, or to isolate potentially vulnerable individual components and take redundant security measures. In the conceptual phase, this is done through architectural measures (such as described, for example, in the publication "Secure Vehicular Communication Systems: Design and Architecture" from Papadimitratos, P., Buttyan, L., Holczer, T., Schoch, E., Freudiger, J., Raya, M., Ma, Z., Kargl, F., Kung, A., & Hubaux, 2008, IEEE Communications Magazine, 46(11), 100-109), while the implementation of the concept is carried out through corresponding development processes (such as best practices, source code review, etc.).

[0008] After the technical unit is fully assembled and the components are integrated, testing or security checks are required in each scenario to identify as many relevant vulnerabilities as possible (as well as those that only appear when combining subsystems). Such security checks are also known as cybersecurity testing.

[0009] To find weaknesses, having knowledge about their existence is helpful (however, there are also techniques for finding weaknesses that do not require prior knowledge, such as fuzzing). The weaknesses upon which security checks are based can be obtained, for example, from publicly accessible or paid databases or from internal databases. Internal databases can contain weaknesses discovered during their own vulnerability analysis; some previously undiscovered weaknesses may also be available for a fee on the dark web.

[0010] Security checks should enable manufacturers (e.g., "Original Equipment Manufacturers"—OEMs), government agencies (e.g., licensing bodies), and other stakeholders (e.g., consumer associations, commercial fleet operators, etc.) to assess specific cybersecurity risks of a technology unit or vehicle. This can be used for further vehicle development or improvement, acceptance or certification, and similar tasks.

[0011] For example, safety checks are required during new vehicle development at the OEM, during market launch / standardization / certification, and subsequently throughout the vehicle's entire lifecycle. The need for repeated security checks on the system testing layer, and therefore continuous cybersecurity checks, arises from changes in configuration, continuous software updates, changing environmental conditions (e.g., changes in vehicle-to-infrastructure (V2I), vehicle-to-vehicle (V2V): interaction partners), and newly known test vectors (also derived from their own security research). These security checks can be performed by the manufacturer, or by fleet operators, licensing bodies, and specialized third-party companies.

[0012] Due to the distributed development, production, configuration, and maintenance within the automotive value chain, knowledge about the specific internal implementation of technical units is either impossible or only very limited during safety checks. The system architecture, configuration data, and source code of the technical unit under test are largely unknown to stakeholders outside the manufacturer (such as users or authorities). Therefore, safety checks largely correspond to "black-box testing" or "grey-box testing"—tests developed with little or no knowledge of the internal functions or implementation of the unit under test.

[0013] This leads to the problem of selecting appropriate test cases and test or attack vectors for security checks. Due to the high complexity and the sheer number of test cases resulting from the diversity of combinations, even high-quality computer systems cannot fully handle these test cases within a real-time context.

[0014] Therefore, the objective of this invention is to provide a method and apparatus by which the number of test cases to be inspected can be reduced to a technically manageable level. Furthermore, the security checks should be able to be performed largely automatically.

[0015] These and other tasks are solved by a method for determining at least one first reasonable model variant of the configuration of a technical unit using a test computer system, wherein the technical unit has at least one data transmission device and a plurality of components capable of data communication via the data transmission device, and wherein the method includes the following steps:

[0016] - Establish a connection between the test interface of the test computer system and the data transmission device of the technical unit.

[0017] - Determine the initial instance of the model for configuring the technology units.

[0018] - Develop a specified instance of the model from an initial instance through a series of specified procedures, each of which has at least the following steps:

[0019] • Perform challenging actions when necessary.

[0020] • Identify the representative behaviors of the technology units.

[0021] • Analyze representative behavior and infer at least one characteristic of the actual configuration of the technical unit.

[0022] • Use at least one identified feature to specify the model.

[0023] At least one of the specified processes is performed automatically by the test computer system, and

[0024] - When at least one deterministic condition is met, a specified instance of the model is identified as the first reasonable model variant.

[0025] This method reduces the variety of test cases that must be tested for security checks to a number that can be fully processed by a test computer system within the available timeframe to check for security validation of technical units.

[0026] In conjunction with this disclosure, a unit having at least one electronic circuit (especially an integrated circuit, and if necessary, a processor, microcontroller, FPGA, artificial neural network, etc.) is referred to as a "component" of a technical unit, which has data communication capabilities and is directly or indirectly connected to at least one data transmission device of the technical unit. According to this disclosure, a component may also be narrowly referred to as an "electronic component" or a "data processing component".

[0027] In conjunction with this disclosure, a component that is connected to a single component or assigned to a single component regardless of the type of data communication is referred to as a “subcomponent” of the technology unit.

[0028] In conjunction with this disclosure, a general apparatus for transmitting data from a sender (e.g., a component, subcomponent, or external data source) to a receiver (e.g., a component, subcomponent, or external data source) is referred to as a "data transmission apparatus." The data transmission apparatus can be wired or wireless, wherein data communication is implemented via the appropriate data transmission apparatus according to a defined connection protocol. Examples of wireless connection protocols include, but are not limited to, 3G / 4G / 5G mobile networks, Bluetooth, WLAN, V2X, RFID, etc. Examples of wired connection protocols include, for example, CAN, FlexRay, MOST, (automotive) Ethernet, etc.

[0029] In conjunction with this disclosure, any computer system that implements the corresponding steps of the methods disclosed herein is referred to as a "test computer system".

[0030] In conjunction with this invention, the data connection between the test computer system and the data transmission device of the technical unit is referred to as a "test interface". The test interface can use any connection protocol that allows such communication. For example, the test interface can be a wireless or wired interface. The test interface can also support multiple different connection protocols when necessary (e.g., when the connection protocol used by the data transmission device of the technical unit is initially unknown). For example, a USB interface, Bluetooth interface, or diagnostic interface of the technical unit can be used as the interface. The establishment of a connection between the test interface and the data transmission device can be performed, for example, via a conventional plug connection or wirelessly. In this case, any process that enables the test computer system to communicate data with the data transmission device is referred to as "connection establishment". If necessary, the test computer system may have multiple independent test interfaces.

[0031] In conjunction with this disclosure, a set of defined features of a technical element is referred to as a "configuration", wherein the set of features may in particular include the following features:

[0032] - The number and type of existing components and / or sub-components

[0033] - Model information of existing components and / or sub-components

[0034] - The number and types of existing data transmission devices

[0035] - Connection protocols for existing data transmission devices

[0036] -Physical arrangement of components and / or sub-components in the technology unit

[0037] - The component's communication capability via one or more data transmission devices

[0038] - The number and type of child components of a component

[0039] -Identifier and version information of the firmware present on the component or subcomponent

[0040] -Identifier and version information of the software present on the component or subcomponent

[0041] - Intercommunication connections between components and / or sub-components

[0042] - The relative functional dependencies between components and / or sub-components (e.g., component A cannot function without component B).

[0043] - The responsibility of components and / or sub-components for the function of the entire system (distributed where necessary) (e.g., the control or combined action of multiple control chips on a vehicle's braking system).

[0044] - Component version (hardware, software, firmware)

[0045] - Chip version and revision number

[0046] -Possible metadata (e.g., manufacturer)

[0047] - Timing information (such as clock frequency, transmission speed, runtime (computation time), cycle time of loop tasks, etc.)

[0048] - Software configuration (e.g., task priority, allocated memory area, etc.).

[0049] In conjunction with this disclosure, a system mapping of the configuration of technical units, taking into account the units assigned to the technical units, is referred to as a "model" or "configuration model." Depending on the level of detail, the model may include some or all of the features defined for the configuration. On one hand, the model may include features of technical units whose consistency with the actual technical units has been confirmed; on the other hand, the model may also include features whose consistency with the technical units has not been confirmed. The model may also include "unknowns" or "placeholders" for features that are known to exist in the technical units but whose exact identity is unknown. In this case, the unassigned variable is called an unknown. A generic model node for which a feature is assigned without specific information is called a placeholder. For example, such a placeholder may be used for a component that is known to exist in the technical unit but whose component type and exact location are unknown. Placeholders may also be used for other features of the technical units (such as those for software, firmware, data transmission devices, etc.).

[0050] The representation or structure of the model can be arbitrarily chosen, wherein a structured structure in which the features of related units (such as components) are aggregated into model nodes can be shown, and the relationships between components (e.g., hierarchical dependencies, data flow, control flow, etc.) can be shown as connections between model nodes (generally referred to herein as "connection edges"). Modeling can be based on any suitable system in which a simple structure (e.g., a hierarchical arrangement of model nodes in a tree structure and an arrangement in a network structure) is sufficient for the teachings and reduces the complexity of the model to a reasonable level. However, this disclosure is not limited to these structures, as other structures can also be used for modeling.

[0051] For specific tests, the model may also need to include components that are not actually technical units but are related to them. In this case, the term "technical unit" is interpreted broadly and may also include such "external" components.

[0052] For example, the technical unit to be analyzed and modeled could be a vehicle, but it requires a communication partner for specific functions. This communication partner could be a second vehicle (in the case of V2x – Vehicle to Everything), or, in the case of connected vehicles, an application running in the cloud (V2C, Vehicle to Cloud). Where necessary, such a communication partner or its components can be included in the modeling of the technical unit, wherein the components and characteristics of this “external” communication partner can be used similarly to the components and characteristics of the actual technical unit in conjunction with the methods disclosed herein.

[0053] In conjunction with this disclosure, the configuration model corresponding to the deterministic conditions is referred to as the "first reasonable model variant". The consistency between the reasonable model variant and the actual configuration cannot be definitively confirmed, but it cannot be ruled out that it is consistent with the actual configuration of the technical units involved. The reasonable model variant may also include "placeholders" for components.

[0054] In conjunction with this disclosure, an incomplete model is typically referred to as an "initial instance of the model," but it is assumed that as many known features of the model as possible correspond to the actual technical unit. The model may also include unknowns or placeholders for features not yet identified. For example, the initial instance could be a general model of the technical unit. Where necessary, a more specific model than the initial model can also be selected (e.g., based on prior information such as the type name of the technical unit). The determination of the initial instance can be performed before or after the connection between the test computer system and the technical unit is established. For example, the initial instance of the model can be selected from a database based on user input in the test computer system (e.g., the type name of the technical unit). Where necessary, the test computer system can also autonomously select the initial instance based on data obtained from the technical unit after the connection is established. Where necessary, predefined test cases can also be executed on the technical unit to determine the initial instance based on experience with similar technical units.

[0055] In conjunction with this disclosure, a modified version of a model that has a higher consistency with the actual technical unit compared to the initial instance (and, if necessary, compared to the previously specified instance) is referred to as a “specified instance of the model”.

[0056] In conjunction with this disclosure, the generation of a specified instance of a model from an initial instance or from a previously specified instance is referred to as a “specified process.” The term “development of a specified instance of a model” refers to a series of specified processes executed iteratively.

[0057] In conjunction with this disclosure, the term "automatic implementation" means testing a computer system to perform a corresponding process without user intervention. Typically, it aims to reduce the number of required user interventions to the bare minimum.

[0058] In conjunction with this disclosure, an operation that induces characteristic behavior of a technical unit (e.g., characteristic data communication via a data transmission device of the technical unit) in a predetermined manner is referred to as a "challenge action." A challenge action may, for example, be data traffic transmitted from a test computer system to the data transmission device via a test interface. If necessary, the test computer system may also perform challenge actions via other interfaces, such as actuators acting on parts of the technical unit. If necessary, the test computer system may also instruct a user to perform a specific challenge action (e.g., to execute an operating element or manipulation component of the technical unit in a specific manner). For example, a challenge action may be a specially designed data communication or a cyberattack performed in a test manner. If necessary, purely passive observation of the technical unit may be performed instead of a challenge action.

[0059] In conjunction with this disclosure, any behavior from which at least one characteristic of the configuration of a technical unit can be inferred is referred to as a "characteristic behavior of the technical unit". Here, characteristic behavior can be, for example, the occurrence of specific data communication via a data transmission device or specific measurements characterizing the technical unit or its components. For example, by measuring the impedance of a wire used as a data transmission device, the number of components connected to that wire can be inferred. Characteristic behavior can also be determined via any other measurement.

[0060] The analysis of characterizing behavior and the inference of at least one characteristic of the actual configuration of a technical unit can be performed, for example, by querying a database that stores the characterizing behavior of known technical units or components. The database can be external or integrated into a test computer system, and can be automatically updated by the test computer system as needed.

[0061] In conjunction with this disclosure, the condition that an instance of the model is sufficiently determined such that a security check can be performed within a pre-given timeframe is referred to as a "deterministic condition." This may, for example, assess the number of possible configuration variations (or model variations) based on the instance. For instance, a deterministic condition might require that the number of possible variations of the instance be below a certain threshold. However, more complex deterministic conditions are also possible. For example, a deterministic condition may also consider the success rate of the last executed specified process to avoid prematurely terminating the development of the specified instance. Where necessary, a deterministic condition may further limit the number of model variations during the performance of security checks.

[0062] In an advantageous embodiment of the method disclosed herein, the step of determining the characterization of a technical unit may include having a test computer system listen to data transmitted via a data transmission device. Listening can, if necessary, determine numerous characteristics of the actual configuration of the technical unit after a challenge action.

[0063] In an advantageous manner, the features of the actual configuration of the technical unit can be selected from at least one feature of the components and / or at least one relationship between the components. For example, the relationship can be a functional relationship or a communication relationship. For example, a feature of a component can be its type name, and / or its model version, and / or firmware version, and / or the software running on the component and / or its version. The functional relationship between the components can be, for example, the arrangement of components communicating with each other on a particular data transmission device, the fact that a particular software is implemented by which component, or the fact that multiple components cooperate at a higher level of function. For example, a "higher level of function" can be a jointly achieved effect. For example, multiple sensors can cooperate on a braking system. However, these sensors do not necessarily have to communicate with each other. Their data can be processed by another unit (which may not even have been found in the specific model).

[0064] In another advantageous embodiment of the method disclosed herein, at least one alternative model variant, and preferably multiple alternative model variants, are created based on a first reasonable model variant. This allows components and features that could not be discovered during the development of a given instance to be considered in subsequent security checks. Here, multiple speculative assumptions are made about the unknown features, and a model variant is created for each assumption. Depending on the computational power of the test computer system and the complexity of the technical units, the total number of alternative model variants can be very high, exceeding the limits of what is mentally understandable and no longer allowing for “manual” processing. However, the number of alternative model variants is small enough to allow for computer-supported analysis (e.g., during security checks) within a reasonable timeframe.

[0065] Therefore, in conjunction with this disclosure, a change to the first reasonable model variant is referred to as an "alternative model variant," wherein at least one unknown feature or "placeholder" in the configuration is replaced by at least one specific feature whose characteristics are known but whose existence in the actual configuration of the technical unit is unknown. For example, the alternative model variant may also replace a single component with multiple components, through which the multiple components jointly implement a single component. For example, the alternative model variant can be completely defined such that all placeholders and unknowns can be replaced by speculative but specific assumptions. In conjunction with this disclosure, specific features of the configuration whose actual implementation in the technical unit has not yet been confirmed are referred to as "speculative assumptions."

[0066] On the other hand, this disclosure relates to a method for security checks of technical units implemented on a test computer system, wherein at least one first reasonable model variant and, if necessary, multiple alternative model variants are identified, and wherein the method comprises the following steps:

[0067] - Assign known weaknesses to the components of the model variant.

[0068] - Define the attack target,

[0069] - For each model variant, identify at least one attack model relevant to the attack target.

[0070] -Weigh the nodes of the attack model based on at least one evaluation variable.

[0071] - Determine the evaluation of at least one test vector for the attack model regarding the evaluation variables.

[0072] - The safety value is determined as the pessimistic value for all assessments, and

[0073] - Output a security confirmation when the security value meets the security criteria.

[0074] Therefore, this method allows for statements regarding the security of a technology unit even when the configuration and characteristics of not all technology units are known. The method can be implemented largely automatically, minimizing the training costs for users.

[0075] In conjunction with this disclosure, paths that exist within a technical element but may go undetected are referred to as “vulnerabilities” or “slots” on which cyberattacks can be launched. This can cause the evaluation of test vectors for attack models to no longer meet security guidelines.

[0076] In conjunction with this disclosure, the process of confirming (or denying) that a tested technology element meets specific security requirements is referred to as a "security check." For example, a security requirement may determine that there is a security validation against one or more attack targets.

[0077] In conjunction with this disclosure, an event that an attacker may have targeted is referred to as an "attack target." For example, an attack target could be gaining control over the software functionality of a component or damaging a specific component. Manipulating engine control, altering injection control, etc., are practical examples of attack targets in a vehicle environment. Attack targets typically constitute the initial nodes of an attack model (e.g., an attack tree or attack network).

[0078] In conjunction with this disclosure, the modeled description of the attack is referred to as an "attack model," in which points are assigned from an initial node (the attack target) regarding how to reach that target. These points form nodes assigned to the initial node, and further nodes can be assigned to these nodes hierarchically. In particular, the model has a tree-like or network-like structure. The concept of attack models is known in the field, for example, described as "attack trees" in publications such as "Attack Trees," Schneier, B. (1999), Dr. Dobb Journal, 24(12), 21-29, or in publications such as "Attack Net Pentration Testing," McDermott, JP (2000), Proceedings of the 2000 workshop on New security paradigms, 15-21, or in "Software fault tree and coloured Petri net-based specification, design and implementation of agent-based intrusion detection systems," Helmer et al. (2007), International Journal of Information and Computer Security. The attack model is described in the form of an attack network in "Security", 1(1), 109-142; a (non-exhaustive) overview of the attack model is provided in "An empirical evaluation of the effectiveness of attack graphs and fault trees in cyber-attack perception", Lalllie, HS, Debattista, K., & Bal, J. (2017), IEEE Transactions on Information Forensics and Security, 13(5), 1110-1122. Since then, the concept of attack models has been defined or refined in relevant publications. In conjunction with this disclosure, it is assumed that those skilled in the art have a solid knowledge of the concept of attack models.

[0079] In conjunction with this disclosure, the attack path from the node assigned in the level hierarchy of the attack model to the initial node is called the "test vector" (or also called the "attack vector"), and a series of steps required to achieve the attack target are defined.

[0080] Each node in the attack model is weighted using an evaluation variable that represents the cost an attacker must incur to implement that node. The evaluation variable can be interpreted as cost or price, and its unit can be defined, for example, as time, money, manpower, other resources, or a combination thereof.

[0081] The nodes of the attack model are typically assigned to defined sub-units of the test unit (e.g., specific components or specific software that must be manipulated to overcome the node).

[0082] In conjunction with this disclosure, the sum of all evaluation variables for a node of a test vector is referred to as the "evaluation of the test vector". Therefore, the evaluation can be interpreted as the cost required to carry out an attack along the test vector. Since each attack model includes many test vectors, the worst-case or pessimistic value of the evaluation of all test vectors for all tested attack models is of interest for evaluating security. The pessimistic value defines the test vector that can be implemented using the minimum cost. In conjunction with this disclosure, the value defining the minimum cost for a successful attack is referred to as "pessimistic".

[0083] In conjunction with this disclosure, the pessimistic value of all evaluations of the test vectors of the attack model is referred to as the security value. The security value defines the minimum cost required to achieve the attack target. The security of the attack model can be confirmed when the security value meets the defined security criteria.

[0084] Therefore, in conjunction with this disclosure, the conditions that a security value must meet in order to confirm security are referred to as "security criteria". For example, a security value that must not be lower than its threshold (e.g., expenditure as defined in terms of money, time, manpower, etc.) can be used as a condition.

[0085] In conjunction with this disclosure, it is indicated that a statement by a technology unit under test regarding an attack target and a defined security value as secure (i.e., conforming to the defined security criteria) is referred to as a "security confirmation".

[0086] Furthermore, advantageously, the method may also include the following steps:

[0087] - To carry out at least one cyberattack on the technical unit, based on the identified vulnerabilities.

[0088] - Evaluate the effectiveness of using cyberattacks, and

[0089] - Eliminate model variants whose effects are still inconclusive.

[0090] This further reduces the number of model variants during testing and deepens knowledge about the actual configuration.

[0091] For example, in the case of a cyberattack, exploits are selected and implemented based on test vectors. In conjunction with this disclosure, tracing a sequence of commands or operations along the path of the attack model (i.e., along the test vectors) to the target is called an "exploitation." Here, the exploit uses known weaknesses. In addition to exploitation, cyberattacks may also include fuzzing. In conjunction with this disclosure, automatically (massively) performing random operations (e.g., importing large amounts of random data via a data transmission device) is called "fuzzing," the purpose of which is to encounter and exploit previously unknown weaknesses.

[0092] For example, the effect of a cyberattack can be either a successful attack, a failed attack, or the acquisition of information in other ways to draw inferences about configurations. If the attack is successful, it can essentially infer the entire chain of hardware and software components involved and greatly deepen the knowledge about the actual configuration of the technical units.

[0093] In this case, "eliminating" model variants means that the corresponding model variants are no longer considered for further security checks because these model variants are known to be inconsistent with the actual configuration of the technical unit. For example, this can be identified directly by specifying that a component actually has a different configuration, or indirectly by the fact that a model variant has a component or configuration that becomes unreasonable due to the identified configuration of another component.

[0094] Furthermore, advantageously, the method may also include the following steps:

[0095] - Identify at least one piece of software and / or firmware installed on a component of the technology unit.

[0096] - Use a test computer system to update software and / or firmware.

[0097] For example, this can be used to automatically resolve security flaws that can be addressed by upgrading (or updating) the corresponding software and / or firmware to a newer version. Security checks can then continue using updates based on the specified model variant (i.e., considering newer model variants).

[0098] In conjunction with this disclosure, all non-technical physical functional components of a computer are referred to as "software". In a narrower sense, data structures (including programs, documents, and possibly related data) are referred to as software.

[0099] In conjunction with this disclosure, the physical components (i.e., electronic and mechanical components) of the technical unit are referred to as "hardware".

[0100] In conjunction with this disclosure, software that is permanently assigned to specific hardware (especially specific components of a technical unit) and substantially determines the functionality of that hardware is referred to as "firmware," in which the hardware cannot be used without it. Firmware can typically only be exchanged using special means or functions.

[0101] Furthermore, in a more advantageous implementation, the method may also include the following steps:

[0102] - Identify the software and / or firmware installed on the components of the technology unit.

[0103] - Create simulated model variants that include specified versions of the software and / or firmware.

[0104] - Determine the safety value based on the simulated model variation.

[0105] In conjunction with this invention, a model variant that is distinguished from the actual configuration of the technical units in a known manner is referred to as a "simulated model variant". In particular, a simulated model variant can be distinguished from an actual existing model variant with respect to the software and / or firmware version.

[0106] In a similar manner, hardware (e.g., components of a technology unit) in a simulated model variant can be "swapped" for other hardware, and the impact on security can be examined in the simulation.

[0107] By using simulated model variations, predictions and safety recommendations can be created, which can be implemented immediately if necessary.

[0108] Advantageously, the technical unit can be a vehicle, particularly an automated or autonomous vehicle of one of SAE levels 0 to 5 according to standard SAE J3016. This information relates to the version of standard SAE J3016 in effect at the priority date of this application.

[0109] In another aspect, this disclosure relates to a computer program product that can be directly loaded into the internal memory of a digital computer and includes a software code portion that, when the product is run on a computer, utilizes the software code portion to implement the steps of the methods disclosed herein.

[0110] Furthermore, this disclosure also relates to test computer systems on which such computer program products are run.

[0111] The following will refer to Figures 1 to 7 To explain the invention in more detail, Figures 1 to 7 The advantageous design features of the invention are illustrated, illustrative, and non-limiting. The accompanying drawings show:

[0112] Figure 1 This is a schematic diagram of the technical unit and the test computer system.

[0113] Figure 2 This is an exemplary block diagram of an initial instance of a model for configuring technical units.

[0114] Figure 3 This is a block diagram of the initial instance of the model, with the data flow also shown.

[0115] Figure 4 It is a block diagram of a specified instance of the model, which supplements additional information about the configuration features of the technical units.

[0116] Figure 5 It is a block diagram of the first reasonable model variant of the technical unit.

[0117] Figure 6 It is a block diagram of multiple alternative model variants created based on the first reasonable model variant.

[0118] Figure 7 It is based on Figure 6 The diagram shows references to known weaknesses in the model variations.

[0119] Figure 1 The technical unit 1 and the test computer system 2 are shown in a schematic diagram, which can be interconnected via the test interface 6.

[0120] Test computer system 2 can be a conventional computer system on which a computer program product is implemented, the computer program product including software code portions that, when run on test computer system 2, utilize these software code portions to implement the steps described herein and performed by test computer system 2. For example, test computer system 2 may include at least one display (such as a computer screen) and input devices (such as a mouse, keyboard, touchpad) and / or application-specific input and output devices, as well as corresponding peripheral devices. Test computer system 2 has a test interface 6, which allows data communication with data transmission device 3 of technical unit 1.

[0121] Test interface 6 may include a cable with a plug that can be inserted into a socket on technical unit 1 to establish a physical connection with data transmission device 3. The socket may be, for example, a vehicle diagnostic interface or other interface (such as a USB port). If necessary, test interface 6 may also be a wireless interface, which establishes a connection with wireless data transmission device 3 using a corresponding connection protocol.

[0122] The data transmission device of technical unit 1 can be connected to multiple components 4, the configuration of which may currently be largely unknown. This configuration can be defined, in particular, by characteristics relating to components 4, data transmission devices 3, and their arrangement and interrelationships. For clarity, in Figure 1 Only a single data transmission device 3 is shown (e.g., in a bus system such as CAN bus), but it should be assumed that technical unit 1 may have multiple different data transmission devices 3 that are interconnected when necessary, and different components may be connected to this data transmission device 3. If necessary, test computer system 2 may have multiple test interfaces 6, each assigned to a different data transmission device 3 of the technical unit. Component 4 may, if necessary, have sub-components 4' that are not directly connected to the data transmission device 3 but are directly connected to component 4.

[0123] For example, the following combination Figures 2 to 5 The diagram illustrates an application of a method by which the configuration of technical unit 1 (initially often largely unknown) can be modeled using a test computer system 2, resulting in a final model 5 (referred to as the "first reasonable model variant") that can be used for safety checks. Here, safety checks should be performed in an economically reasonable manner. Specifically, in the case of vehicle safety checks, checks should be performed within a few working hours. Deep scans may take longer, such as several days, if necessary, but only require occasional or no human interaction. The degree of economic reasonableness depends on the application: relatively large costs can be expected for safety checks of new technology units and technology units under development. For example, routine safety checks of vehicles already permitted for road use should be completed significantly faster if possible. In favorable circumstances, safety checks can be completed in an hour or less, or even within minutes.

[0124] The following examples of this type of modeling are based on motor vehicles (such as electric vehicles, vehicles with internal combustion engines, vehicles with hybrid powertrains, vehicles with fuel cells, etc.). Initially, the tester (or the user of the test computer system) only knows basic data about the vehicle, such as whether it has an electric motor or an internal combustion engine, what type of vehicle it is, etc. This information can be input by the user into the test computer system 2, and, if necessary, the test computer system 2 can also automatically determine this information once a connection is established via the test interface 6. The basic data may also include a mixture of directly input information (e.g., "has a driver assistance system") and indirectly determined information (e.g., many attributes can be automatically retrieved from a database by specifying the vehicle identification number (VIN)). Based on this basic information, the test computer system 2 can select an initial instance 100 of model 5, as in Figure 2 and3 The initial instance 100 of model 5 can be selected, for example, from a library of possible templates for the corresponding technical unit 1, such as from a library of possible templates for connected vehicles.

[0125] Model 5 describes the structure or configuration of the technical units in a hierarchical manner, with the scenario shown being based on a tree structure. In the tree structure, various features are summarized in model nodes (1000, 1001, etc.), and for example, model nodes may include individual components or sub-components.

[0126] Model 5 is constructed in a multi-level layer, where the hierarchy and / or other relationships between the various model nodes are indicated by connecting edges 10, which represent, for example, a structure of functional dependencies (e.g., between a system and a subsystem). However, the structure of the model and its relationships can also be constructed arbitrarily in other ways (e.g., based on physical connections with input nodes that are directly connected to the test interface 6 as the root of the tree). The top-level layer forms an identification layer 201, which identifies the modeled technical unit 1 (e.g., identified as vehicle type and chassis number) in the highest model node 1000. Model variants are identified in model node 1001 below. Each model 5 may have multiple variants, as shown by model node 1001' indicated by dashed lines. The following is in particular in conjunction with Figure 6 and Figure 7 The structure and characteristics of the model variant are described.

[0127] The next level layer can be referred to as component layer 202. In this component layer 202, the various components 4 of technical unit 1 are represented, where, for example, model node 1002a represents the first component 4, and other model nodes 1002b, 1002c, etc., represent other components 4 of the technical unit. Examples of such components include engine control, vehicle dynamics adjustment, driver assistance systems, and instrument panel control.

[0128] The following is a sub-component layer 203, whose model nodes 1003a, 1003b, etc. involve the sub-components that are assigned to each model node of the component layer 202.

[0129] The lowest level layer can be referred to as the interaction layer 204. The model nodes 1004a, 1004b, etc., listed in this interaction layer 204 can each relate to actuators, sensors, user interfaces, etc. The model nodes 1004 in the interaction layer 204 are each assigned to higher-level model nodes, where these model nodes can be assigned to model nodes in the sub-component layer 203 or model nodes in the component layer 202 (the second option is not specified in the text). Figure 2 (as shown in the image).

[0130] The names of the layers are for illustrative purposes only and are not intended to be restrictive. In particular, all model nodes can be considered as “components” of technical unit 1, and the model may have more or fewer layers.

[0131] For example, connecting edge 10 can represent hierarchical arrangement or hierarchical correlation, other relationships, and / or data communication paths. Typically, this is achieved by using... Figure 1 The model nodes and connecting edges 10 of model 5 shown in the figure can define multiple features, such as the following information belonging to these features:

[0132] - Subsystem and system boundaries,

[0133] - Interfaces, sensors, actuators,

[0134] - Functionality (such as implemented functions, protocols, standards, etc.),

[0135] - A description of the technical implementation, for example:

[0136] Information about the software, its included libraries, runtime environment, and more accurate information about each version, as well as descriptions of the creation tools (compiler, linker, etc.) and debugger information.

[0137] • Hardware (chip manufacturer, version, etc.), descriptions of the debugger interface (JTAG), etc.

[0138] Data paths between components

[0139] The initial instance 100 of Model 5 may have incomplete information about certain features and model nodes, which are referred to as unknowns or placeholders.

[0140] The initial instance 100 of Model 5 may have additional display layers independent of the hierarchical structure, for example, to illustrate the data flows and communication relationships that can occur between the various model nodes. Such data flows 11, for example, in... Figure 3 The middle part is indicated by a dotted line.

[0141] In a practical application scenario, data flow 11 could, for example, involve the transmission of the current engine speed from the engine controller (ECU) to the transmission controller (TCU). The engine controller could, for example, be represented by model node 1002a. This model node 1002a contains measurements obtained from a speed sensor represented by node 1004a via model node 1003a of a subsystem (which, for example, represents sensors and interface controllers).

[0142] The engine controller (model node 1002a) transmits the measured values ​​(or data derived from the measured values) to node 1003b, which then forwards the data to model node 1003a.

[0143] In this example, node 1003b could be, for example, a measurement node (and, for example, contain analog-to-digital conversion) or perform measurement preprocessing (e.g., scaling). It is possible that the (physical) sensor represented by node 1004a and the unit represented by node 1003a (e.g., measurement preprocessing) are constructed in a common housing, but can still be logically considered separately, and therefore can be modeled in this manner. The data is then transmitted to model node 1004c, which, for example, represents a CAN interface. Model node 1004c then forwards the data via the CAN bus to the transmission controller represented by model node 1002c. Many other possible data flows and communication connections can be shown in Model 5 in a similar manner.

[0144] Combination Figure 2 and 3 The characteristics disclosed in the description can also be applied, in a meaningful sense, to all model variants developed from the initial instance 100 of Model 5 as described below. Here, during the specification of iterations, unknowns and placeholders are replaced with specific features, as referenced below. Figure 4 and 5 As described.

[0145] Figure 4 A block diagram of a specified instance 101 of model 5 is shown, wherein specified instance 101 supplements additional information about the sub-components of model node 1003a (which are located in...). Figure 4 (Illustrated schematically as information block 1103a). For example, the information block may include information about the connection protocol used, type name, development stage, software used and software version, type name, and other information about the CPU or microcontroller.

[0146] For example, one possibility for initially obtaining additional information is user retrieval. For instance, a user can determine whether a component is constructed in technical unit 1 through visual inspection, provided this can be identified visually. Other information can be obtained by the test computer system 2 via test interface 6, either partially or fully automatically, through a specified process. The specified process requiring user intervention is referred to as "partially automatic," while the fully automatic specified process, conversely, requires no user intervention.

[0147] To implement partially or fully automated specified processes, test computer system 2 can, for example, perform a scan in which methods known from reverse engineering are applied. The following are examples of such scans:

[0148] - Use a protocol sniffer to determine the implemented connection protocol and its version.

[0149] - Measurement of additional attributes (such as latency) and determination of the implementation details of the connection protocol (software, hardware),

[0150] - Identify components and / or protocols through specially designed data communication (challenge actions).

[0151] - Software is identified by searching memory (RAM, Flash, etc.) and inferring the signatures of known software components using pattern matching.

[0152] - Inspect the program flow structure in the compiled software (“control flow integrity check”), which can be done, for example, using known error analysis tools (such as Valgrind).

[0153] If necessary, additional information can be obtained from the above scans using the user's expertise. This is particularly advantageous for technical units that are still in the early stages of development or have very little experience.

[0154] Whenever a representative behavior is identified based on the results of the scanning process, this representative behavior allows for the inference of at least one feature of the actual configuration of technical unit 1, and this information is used to specify model 5. Therefore, by applying an automated scanning process, the level of information about the configuration is progressively expanded and mapped to the specified instance 101 of the progressively developed model 5.

[0155] The scanning process can analyze and evaluate responses triggered by challenge actions, or it can evaluate the behavior of technical unit 1 triggered by the technical unit 1 itself and not occurring as a response to a challenge action. For example, data traffic on a data bus (e.g., a vehicle's CAN bus) can be passively "listened to" by test computer system 2. The data communication events occurring on the bus can then be analyzed and evaluated to infer the characteristics of the technical unit. Such "listening" to data communication events is possible without challenge actions; however, the knowledge gained is limited. Therefore, to obtain further information, it is possible to attempt to trigger data communication in a targeted manner using challenge actions. A challenge action could be, for example, test computer system 2 generating its own data traffic on data transmission device 3 and analyzing and evaluating the responses thereon. However, more complex challenge actions can also be performed (e.g., by implementing user actions pre-given by test computer system 2).

[0156] The specification process can be implemented by the test computer system 2 until a complete configuration is found. However, this is often impossible within a pre-defined timeframe, so the specification process ends once the deterministic condition is met. The result is a refined, specific model that may still contain gaps, but has a significantly higher level of detail than the initial instance 100 of the model. For example, a deterministic condition might be, for instance, that the proportion of unidentified features is below a certain percentage. If necessary, individual features can be weighted based on their relevance, where the deterministic condition can be met when the total weight of unidentified features is below a predetermined value. Alternatively or additionally, the deterministic condition may include other criteria, such as a certain test time or, for example, evaluating the success of the last executed specification step. Here, the specification process continues as long as the specification step successfully generates new information. When the cost of the specification process corresponds only to small progress, the specification process can be terminated, if necessary, in conjunction with other deterministic conditions.

[0157] The model developed using the specified process (i.e., the most complete version of the specified instance 101 of model 5) combined with this disclosure is referred to as "first rational model variant 102".

[0158] Figure 5 A schematic block diagram of such a first reasonable model variant 102 of technical unit 1 is shown. Certain information can be determined for model nodes 1002a, 1002b, 1003a and 1004c, as shown by information blocks 1102a, 1102b, 1103a and 1104c.

[0159] The proportion of specified processes that can be fully automated by the test computer system 2 increases with the number of tests performed on similar or identical technical units 1, because in this case, the database expands the possible configurations, enabling increasingly automated process flows. Therefore, it is a learning system. Once the initial learning phase is overcome and sufficient information is stored in the database, increasingly complex tasks can be implemented automatically in a shorter time.

[0160] Once the first reasonable model variant 102 was identified, further refinement was carried out speculatively. This is in Figure 6 As exemplarily shown in the figure. Figure 6 Multiple alternative model variants 103, 103', and 103', shown as overlays, are created based on the first reasonable model variant 102. When creating alternative model variant 103, all missing features related to the security check are first identified. Then, for each of these features, multiple speculative assumptions are made, each representing a possible implementation. Subsequently, an alternative model variant is created for each possible combination of features under these assumptions.

[0161] For example, in the case of the first reasonable model variant 102, it may be unknown which specific implementation is used as the TCP / IP stack in a particular controller (e.g., the controller represented by model block 1003c). For this reason, N assumptions are now made about the possible implementations. If this is the only unknown in the first reasonable model variant 102, then this results in exactly N alternative model variants. However, it is usually necessary to create multiple possible implementations for the unknown features, where multiple possible implementations (M, O, ...) are created for each of these features. Therefore, the total number of alternative model variants is derived by the product of the number of each alternative model variant (N x M x O ...). Thus, the total number of alternative model variants 103 typically reaches an order of magnitude that can only be checked and tested by a powerful test computer system 2. However, unlike the starting point of the initial instance 100 of the model, this task can be solved within a predetermined time because the first reasonable model variant 102 does indeed satisfy deterministic conditions.

[0162] After creating the replacement model variant, an actual security check of technical unit 1 can be performed.

[0163] To this end, known weaknesses are assigned to each alternative model variant 103. Here, the identified features and the assumptions made are compared with a set of known weaknesses. Such a set is available for free or for a fee on the Internet (e.g., {hyperlink "http: / / cve.mitre.org / "} or {hyperlink "https: / / www.automotiveisac.com / "} and / or internal sets from manufacturers, associations, etc.). After this assignment, multiple alternative model variants 103, each assigned with known weaknesses, are obtained. Figure 7 It shows Figure 6 The diagram shown illustrates a replacement model variant, which enumerates multiple references 104 to known weaknesses, and these references 104 are assigned to specific model nodes. Here, if necessary, multiple weaknesses can be assigned to a single model node, or a single weakness can be assigned to multiple model nodes.

[0164] In addition, attack targets can be defined, or selected from a list of pending attack targets. The execution of security checks is described below in conjunction with attack targets. However, if necessary, security checks may also include multiple attack targets, with each target being processed in a similar manner.

[0165] Regarding the attack targets, an attack model is created for each alternative model variant, taking into account known weaknesses for each model node. Each node in the attack model typically corresponds to a node in the corresponding model variant. Weaknesses (and possible countermeasures) identify the nodes to be compromised and thus the costs required to overcome them as obstacles on the path to the attack target (see below). The hierarchical structure of the attack models allows for tracing back to attack models already developed for a known model node, and the use of these model nodes in the corresponding attack models.

[0166] If necessary, "speculated weaknesses" (such as for nodes with no known weaknesses but which are suspected by experts to be discoverable within a reasonable timeframe) can also be considered. A speculative weakness can then be assigned to that node. Speculative weaknesses are also used for implementation testing when the weakness database is still incomplete and insufficiently populated. Speculative weaknesses can be tested, for example, using specialized techniques for finding weaknesses without prior knowledge (such as fuzz testing).

[0167] Each node in the attack model is weighted by an evaluation variable regarding cost, which assigns a cost (e.g., in terms of money, manpower, time, other resources) to each node for overcoming. For a defined attack target, an evaluation can be performed for each path of the attack model (i.e., for each test vector) by leveraging known weaknesses at the corresponding nodes and the corresponding evaluation variables.

[0168] However, for security checks, it is unnecessary to calculate the evaluation of every individual test vector for each replacement model variant, as only the pessimistic value of all test vectors is of interest. Therefore, if the evaluation of a test vector is significantly higher than the pessimistic value determined so far, the evaluation of that test vector can be suspended or omitted. For example, the evaluation of test vectors for nodes with evaluations that are better than the pessimistic value determined for the entire test vector set so far can be completely cancelled. However, such replacement test vectors may be relevant when the specified model changes and thus implies a re-evaluation of the attack model or its path.

[0169] If the evaluation of the test vector is found to be below the security criteria defined for security verification, the security check can be suspended, or measures to improve the security of technical unit 1 can be recommended or implemented by the test computer system 2 (e.g., software or firmware updates for one or more components). The security check can then be repeated using a redefined model variant, where features determined from the outset can be used this time.

[0170] Otherwise, the evaluation of test vectors is performed until pessimistic values ​​for all test vectors of all attack models for all alternative model variants are determined. If this pessimistic value (also referred to as the security value) is higher than the previously defined security criteria, a security confirmation (“security verification”) for the technical unit can be output. Additionally, recommendations can be made on how security can be further improved (e.g., by identifying protective measures such as software updates). If necessary, the impact of such software updates on achievable security values ​​can be pre-tested in simulated security checks. If necessary, new security checks can be implemented after one or more implemented protective measures, where information determined so far can be utilized.

[0171] The security check process can be performed iteratively, where security measures are implemented once a test vector is found whose evaluation falls below the security criteria, and the method then continues based on new knowledge.

[0172] In implementing this method, numerous test vectors for attack models based on substitution model variants are conceived, including nodes based on unverified components or features, as these features are selected based on speculative assumptions. Once a test vector guided by a node with speculative assumptions is found in multiple substitution model variants, where the node exposes a vulnerability, the vulnerability can be exploited at the actual technical unit 1 by performing a corresponding network attack by the test computer system 2. Verified nodes and test vectors can also be examined in this manner (e.g., using appropriate tools such as penetration testers). Subsequently, this "actual" attack can be used to verify the examination results. In some cases, it may even be found that the attack is easier than expected, and thus the "cost" (i.e., evaluation) is lower in reality. (For example, an easily guessable default password can be assigned. In this case, brute-force trial and error is not required).

[0173] For example, it may be known that a specific component (the node involved in the test vector) is vulnerable to DDoS attacks. Test computer system 2 can then execute such a DDoS attack based on a vulnerability exploit using the test vector. If the network attack succeeds in this manner, all model variants whose corresponding test vectors do not possess the vulnerability can be eliminated. If only a single model variant remains, other practical characteristics of technical unit 1 can be inferred. Thus, the diversity of alternative model variants can be significantly limited, and if necessary, the configuration of the technical unit can even be completely mapped into the model (i.e., only one alternative model variant that confirms complete consistency with technical unit 1 exists). The use of the exploit can have additional relevance to the actual impact of checking for weaknesses; therefore, the weakness may not be exploitable through minor changes in software configuration or through additional protective measures, although the software will theoretically be affected by the weakness.

[0174] Typically, a successfully executed cyberattack can fully identify the entire component chain affected by the node in the test vector.

[0175] Once no further test vectors are found that fail to meet the safety criteria, the system can be considered "sufficiently safe," and a safety confirmation will be output.

[0176] In each security check, the knowledge gained is evaluated and stored in a corresponding database for future security checks. For example, if a test vector (i.e., a vulnerability) that enables a network attack is discovered, corresponding test cases, test vectors, and potential exploits can be automatically generated from it, which can be used in future security checks of similar technical units.

[0177] In conjunction with this disclosure, the automated process of testing steps is referred to as a "test case," which is based on patterns identified during previous security checks performed on similar technology units. Such test cases can significantly simplify the methods disclosed herein. For example, based on earlier security checks, it may be known that a particular type or model of a technology unit is frequently affected by specific test vectors. With the help of test cases, corresponding exploits can already be implemented during the modeling process, and their success or failure allows inference of the actual configuration of the technology unit. Here, in conjunction with this disclosure, the exploitation of a test case can be viewed as a "challenge action," where the result represents a characteristic behavior of the technology unit.

[0178] The above processing method allows for highly automated test execution and test evaluation, which can identify functional and non-functional errors or general irregularities in technical unit 1.

[0179] During (or as a result of) security checks, security and / or improvement measures may be proposed as necessary, and experiments may be conducted where appropriate. These proposals stem from hypothetical or simulated changes in the configuration that alter the attack model or at least one of its test vectors, such as software updates to components represented by nodes. The verification of proposed improvements can be performed, for example, in the following three forms:

[0180] - Simulation of the attack model (pure computation within the model)

[0181] - Simulation in a simulation environment (i.e., technical units are at least partially mapped to virtual simulation systems that use versions of software running on them for simulation).

[0182] - Testing on an actual test unit (e.g., on a physical vehicle on a test bench), where, if necessary, the various components of the technical unit can be replaced by virtual equivalents in the form of (joint)simulation.

[0183] The verification is then carried out according to the security check method disclosed in this paper, in which partially or completely simulated technical units replace real technical units.

[0184] The method described in this paper allows for the automatic discovery of test cases for security checks, prioritization of these cases, identification of relevant test vectors, generation of exploits, definition of automated execution of security checks, and support for automated evaluation of test results. This enables the maximization of possible test success with limited (i.e., pre-given) test resources (e.g., maximum test time). This means that as many relevant (high-priority) weaknesses as possible can be identified throughout the system (i.e., technical units) with the highest possible probability.

[0185] Furthermore, this method also allows for the identification of relevant test vectors and the selection or generation of necessary test cases when, given in advance (e.g., during “black-box testing”), there is no or incomplete information about the technical units at the outset (e.g., lack of details about the system architecture, the correlation between components and sub-components, the characteristics of components, known weaknesses, etc.).

[0186] Figure label:

[0187] Technical Unit 1

[0188] Test computer system 2

[0189] Data transmission device 3

[0190] Component 4

[0191] Model 5

[0192] Test Interface 6

[0193] Connecting edge 10

[0194] Initial instance 100

[0195] Specified instance 101

[0196] First rational model variant 102

[0197] Replacement model variant 103

[0198] Reference 104

[0199] Identification layer 201

[0200] Component layer 202

[0201] Sub-component layer 203

[0202] Interaction layer 204

[0203] Model node 100x

[0204] Information block 110x

Claims

1. A method for security checking of a technical unit (1), wherein the technical unit (1) has at least one data transmission device (3) and a plurality of components (4) capable of data communication via the data transmission device (3), wherein at least one first reasonable model variant is determined from an initial instance of a configuration model of the technical unit (1) by a specified process, wherein each configuration model and each model variant corresponds to a system mapping of the configuration of the technical unit (1), wherein the first reasonable model variant corresponds to a deterministic condition, wherein the deterministic condition indicates that the first reasonable model variant is sufficiently determined such that a security check can be performed within a predetermined time, wherein the method is implemented on a test computer system (2), and wherein the method comprises the following steps: - Assign known weaknesses to the components of the model variant. - Define attack targets by selecting from a list of pending attack targets. - For the model variant, determine at least one attack model related to the attack target. -Weight the nodes of the attack model based on at least one evaluation variable. - Determine the evaluation of at least one test vector of the attack model regarding the evaluation variables. - The safety value is determined as the pessimistic value for all assessments, and - Output a security confirmation when the security value meets the security criteria.

2. The method of claim 1, wherein the at least one first reasonable model variant is determined according to a method for determining the configuration of the technical unit (1) by means of the test computer system (2), wherein the method comprises the following steps: - Establish a connection between the test interface (6) of the test computer system (2) and the data transmission device (3) of the technical unit (1). - Determine an initial instance of the configuration model (5) of the technical unit (1), wherein the initial instance of the model (5) is a general model of the technical unit or a more specific model. - Starting from the initial instance, develop a specified instance of the model (5) through a series of specified procedures, each specified procedure having at least the following steps: Characteristic behavior of the technical unit can be determined by monitoring data communication via the data transmission device (3) or by another measurement. • Analyze the characterization behavior and infer at least one feature of the actual configuration of the technical unit (1). • The model (5) is specified using at least one determined feature. At least one of the specified processes is automatically implemented by the test computer system (2), and - When at least one deterministic condition is met, a designated instance of the model (5) is identified as the first reasonable model variant.

3. The method as described in claim 2, characterized in that, Developing a specified instance of model (5) from the initial instance through a series of specified processes additionally includes the following steps: • Perform challenging actions.

4. The method as described in claim 2, characterized in that, The steps for determining the characterization of a technology unit include having the test computer system (2) monitor data transmitted via the data transmission device (3).

5. The method as described in claim 2, characterized in that, The features of the actual configuration of the technical unit are selected from at least one feature of the component (4) and / or at least one relationship between the components (4).

6. The method as described in claim 2, characterized in that, At least one alternative model variant is created based on the first reasonable model variant.

7. The method as described in claim 1, characterized in that, The method further comprises the following steps: - At least one network attack based on the identified vulnerability is carried out on the technical unit (1). - Evaluate the effectiveness achieved using the aforementioned cyberattack, and - Eliminate model variants whose effects are still inconclusive.

8. The method as described in claim 1, characterized in that, The method further comprises the following steps: - Identify at least one software and / or firmware installed on component (4) of the technology unit (1), - Use the test computer system (2) to specify the software and / or firmware.

9. The method as described in claim 1, characterized in that, The method further comprises the following steps: - Determine the software installed on component (4) of the technology unit (1), - Create simulated model variants that include a specified version of the software. - Determine the safety value based on the simulated model variant.

10. The method as described in claim 1, characterized in that, The method is performed at a technical unit (1), which is a vehicle.

11. The method as described in claim 10, characterized in that, The vehicle is an autonomous vehicle of one of SAE levels 0 to 5 according to standard SAE J3016.

12. A method for determining at least one first reasonable model variant of the configuration of a technical unit (1) by means of a test computer system (2), wherein the technical unit (1) has at least one data transmission device (3) and a plurality of components (4) capable of data communication via the data transmission device (3), and wherein the method comprises the following steps: - Establish a connection between the test interface (6) of the test computer system (2) and the data transmission device (3) of the technical unit (1). - Determine an initial instance of the configuration model (5) of the technical unit (1), wherein the initial instance of the model (5) is a general model of the technical unit or a more specific model. - Starting from the initial instance, develop a specified instance of the model (5) through a series of specified procedures, each specified procedure having at least the following steps: Characteristic behavior of the technical unit can be determined by monitoring data communication via the data transmission device (3) or by another measurement. • Analyze the characterization behavior and infer at least one feature of the actual configuration of the technical unit (1). • The model (5) is specified using at least one determined feature. At least one of the specified processes is automatically implemented by the test computer system (2), and - When at least one deterministic condition is met, a designated instance of the model (5) is identified as a first reasonable model variant, wherein the deterministic condition indicates that the first reasonable model variant is sufficiently determined such that a security check can be performed within a predetermined time.

13. The method as described in claim 12, characterized in that, Developing a specified instance of model (5) from the initial instance through a series of specified processes additionally includes the following steps: • Perform challenging actions.

14. The method as described in claim 12, characterized in that, The steps for determining the characterization of a technology unit include having the test computer system (2) monitor data transmitted via the data transmission device (3).

15. The method as described in claim 12, characterized in that, The features of the actual configuration of the technical unit are selected from at least one feature of the component (4) and / or at least one relationship between the components (4).

16. The method as described in claim 12, characterized in that, At least one alternative model variant is created based on the first reasonable model variant.

17. The method as described in claim 12, characterized in that, The method is performed at a technical unit (1), which is a vehicle.

18. The method as described in claim 17, characterized in that, The vehicle is an autonomous vehicle of one of SAE levels 0 to 5 according to standard SAE J3016.

19. A computer program product that can be directly loaded into the internal memory of a digital computer and includes a software code portion that, when the product is run on a computer, utilizes the software code portion to implement the steps of the method according to any one of claims 1 to 18.

20. A test computer system (2) on which the computer program product according to claim 19 is run.

Images