Method for generating test scenarios for a security check

Abstract

The invention relates to a computer-implemented method for generating test scenarios for a security check of a functional system of a mobility application, in particular from the automotive and / or aeronautics sector. A system model of the functional system is created and an attack graph is determined on the basis of a security and threat analysis. The attack graph has nodes representing attack targets connected by edges representing attack actions, wherein the nodes are assigned corresponding abstract test modules relating to which placeholder variables are provided for system-specific information. Test modules are arranged in the particular attack path according to a sequence of the edges and are joined to form a test scenario, from which a test case can then be derived for checking the security of a functional system.

Description

[0001] Procedure for generating test scenarios for a security audit

[0002] Technical area

[0003] The present invention relates to a computer-implemented method for generating test scenarios for a security check of a functional system of a mobility application, in particular from the automotive and / or aeronautics sector, using a test system, wherein a system model of the functional system is created. Based on the system model, at least one attack graph is determined in a security and threat analysis. Starting from an initial node that defines an attack target, the attack graph has at least one, usually several, attack paths with nodes that each represent a result of a respective attack action and / or a sub-goal of the respective attack action, and edges that connect the nodes of the attack path and represent the respective attack action for reaching the attack target.Furthermore, the present invention relates to an associated test system and an associated computer program product.

[0004] State of the art

[0005] Many modern technical devices, particularly vehicles, have a certain degree of complexity and comprise a multitude of embedded and interconnected components, each equipped with its own processors or microcontrollers. However, the present disclosure is not limited to vehicles in the true sense of the word, but can also be used in conjunction with other technical units and systems that comprise a multitude of interconnected components and are used primarily in the automotive and / or aeronautics sectors in mobility applications—i.e., for example, in vehicles or in their surroundings. In the context of the present disclosure, these are generally summarized under the term “functional system.” This means that such a functional system can, for example, be a vehicle itself (e.g., motor vehicle, truck, aircraft, etc.).) or a complex system that is used in a vehicle or in conjunction with a vehicle to implement mobility applications.

[0006] Examples of such functional systems include, in addition to the vehicles themselves, combinations of different external units / systems with vehicles or internal vehicle units and systems, combinations of internal vehicle systems and units, and combinations of multiple vehicles or units / systems of multiple vehicles. For example, certain tasks can be performed by an autonomous computer unit (e.g., tablet, smartphone, etc.) that communicates via an interface with a unit or system in an (autonomous) vehicle (e.g., infotainment system, GPS, navigation system, etc.).

[0007] In mobility applications such as autonomous driving (AD) or so-called vehicle-to-X communication, vehicles or in-vehicle systems can exchange data or information with infrastructure units (e.g. traffic lights, barrier systems, etc.), for example via radio. Furthermore, in mobility applications such as advanced driver assistance systems or so-called Advanced Driving Assistance Systems (ADAS for short), units and systems within a vehicle (e.g. sensors, etc.) can communicate with other units and systems (e.g. braking system, engine, etc.) via interfaces. On the other hand, several vehicles can also communicate with each other, for example via radio, in order to carry out tasks together - for example, by being coupled together in the sense of a virtual drawbar, or to implement mobility applications such as vehicle-to-vehicle communication for the exchange of information and data between vehicles.Furthermore, a vehicle, such as a special vehicle in the construction sector, in agriculture, an emergency vehicle, etc., can be connected to one or more on-board devices. Such combined units or systems are considered, within the meaning of the present disclosure, to be a functional system that is used in a mobility application (e.g., vehicle, autonomous driving, ADAS, vehicle-to-infrastructure or vehicle-to-vehicle applications, etc.) or is used for the implementation thereof.

[0008] Typically, the components of such a functional system have their own memory units and communication interfaces, thus each forming its own computer system. Such components are also referred to as "embedded systems (ES)" and perform their tasks – largely invisibly – within the functional system. In the case of a complex overall system (e.g., vehicle, aircraft, etc.), a large number of otherwise autonomous embedded systems are usually networked. Components of such functional systems can also be so-called "cyber-physical systems (CPS). A cyber-physical system is typically understood to be a network of software units with mechanical and electronic parts, which are connected via a data infrastructure (e.g., Internet, bus system, etc.).), whereby a cyber-physical system can be formed, for example, by networking embedded systems via a wired and / or wireless communication network and can be used, for example, in mobility applications (e.g. networked security systems, networked driver assistance systems, etc.).

[0009] The complexity of such functional systems, especially in the automotive and / or aeronautics sectors, quickly becomes unmanageably high and complex. For example, a vehicle typically has dozens of control units, each executing software with tens of millions of lines of program code. Examples of communication interfaces include the various wireless connection protocols, such as mobile communications protocols (e.g., 5G, LTE, etc.), Bluetooth, Wireless LAN, RFID, Vehicle-to-X interfaces, etc., which are sometimes used simultaneously. Due to the complexity and diverse communication interfaces, such functional systems create a large attack surface for cyberattacks, such as denial-of-service (DoS) attacks / flooding.Furthermore, there is a risk that attacks will occur not only via the actual communication interfaces, but also via sensors (e.g., LIDAR, radar systems, etc.), for example, whereby such attacks can be carried out using so-called fake signals. In principle, any event that occurs from outside or inside the functional system with the aim of influencing the functional system in an impermissible manner and / or of impermissibly forwarding data from the functional system to third parties is considered a cyberattack.

[0010] Due to the physical capabilities of vehicles (mass and speed, thus high kinetic energy, direct interaction with potentially large numbers of people), their large number (vehicle fleets), and the development toward autonomous vehicles, such attacks can pose an enormous threat potential. This applies not only to the large number of vehicles, such as cars or trucks, but also affects rail vehicles, watercraft, and, above all, aircraft. Therefore, it is important to protect functional systems used in mobility applications—especially in the automotive and aeronautics sectors—against cyberattacks and thus misuse, so that such attacks on the respective system have as little effect as possible or remain as ineffective as possible.

[0011] Due to increasing risks from cyber attacks on functional systems such as vehicles and because mobility applications (e.g. autonomous driving, ADAS, vehicle-to-infrastructure or vehicle-to-vehicle applications, etc.) or online updates of vehicles or functional systems offer new attack surfaces for cyber attacks, a cybersecurity standard such as ISO / SAE 21434 "Road vehicle - Cybersecurity" was developed, which proposes measures for development in the automotive sector.This is also related to the UNECE Regulation R 155 “Cyber ​​security and cyber security management system”, which requires that cybersecurity concerns be considered throughout the entire development process and life cycle of a functional system, such as a vehicle, that appropriate measures be taken and that these be verified through appropriate security checks and tests, so that, for example, functional systems that have been implemented and are in operation are as secure and protected as possible against cyber attacks.

[0012] In order to protect functional systems against cyber attacks and make them resilient, it is important to identify vulnerabilities as early as possible in the development process and, if possible, prevent them. In order to identify vulnerabilities and potential points of attack (i.e., ways in which a cyber attack on the functional system can be carried out) as early as possible, a system model can be created, for example, in the design or concept phase of the newly developed functional system or during the planning of a change, further development and / or improvement of an existing functional system (e.g., update or replacement of one or more components of the functional system). With the help of this system model, potential threats (e.g.,unencrypted, wireless connections, interfaces, etc. between external services and internal system components, etc.) can be identified. Since threats often interact with each other or reinforce each other, which can lead to attack chains or attack paths, it is important not to consider the identified threats in isolation in order not to overlook any relevant risks in the functional system. Therefore, based on the system model and the identified potential threats, one or more attack graphs can be created, for example manually or automatically using appropriate auxiliary and utility programs, in which the attack chains or attack paths are summarized accordingly. In graph theory, a graph is a structure that contains a set of objects (e.g., the result of an attack and / or the target of an attack) together with the connections between these objects (e.g.,Attack actions). The objects are called nodes and the connections between the nodes are called edges.

[0013] An attack graph can, for example, illustrate the connections between different threats and the various attack scenarios and offers a formal, methodical way to describe and evaluate the security of a functional system - ideally relatively early in development - based on different attacks or attack paths. An exit node defines the attack target - i.e. the overall goal of the attacker. At least one attack path, but usually several attack paths, lead from the exit node, which have nodes connected by edges. The nodes represent, for example, results of attack actions and / or sub-goals of attack actions (e.g. the attack has access to a component of the system, etc.) in order to reach the attack target or the exit node. The edges describe the attack actions that the attacker must take in order to achieve one of the sub-goals (i.e.The next node in the attack graph is used to reach the attack target (i.e., the exit node). By visualizing the connections and dependencies of threats to the functional system in the form of attack paths in the attack graph, critical attack paths can be identified, and correspondingly vulnerable areas and / or components of the functional system can be identified. This allows, for example, security measures to be planned—as early as the design or conception phase or when planning a system change—that focus on components, connections, interfaces, etc. of the system that make a significant contribution to the feasibility of an attack.

[0014] The attack graph can, for example, use a hierarchical or tree structure to represent possible attacks on the functional system. Such an attack graph is referred to as an attack tree, which represents the attack paths (as branches of the tree) starting from the root node. Attack trees are described for computer systems, for example, in Schneider, Bruce; Attack Trees. Dr. Dobb's Journal 24, 21-29, 1999. or Phillips, C. & Swiler, LP; A graph-based system for network-vulnerability analysis. in Proceedings of the 1998 workshop on New security paradigms 71-79, ACM 1998.

[0015] To model the attack graph, a so-called Petri net can be used, for example, with which process states can be graphically represented in the form of nodes (e.g., results of attack actions and / or targets of attack actions) and edges (e.g., attack actions). The edges in a Petri net are directed connections between the various nodes and represent, for example, process-related relationships between the nodes—i.e., which attack actions lead to which attack target. Petri nets are known, for example, from Petri, CA; Communication with Automata, PhD Thesis, Technical University of Darmstadt, 1962.

[0016] In order to uncover vulnerabilities and potential points of attack (i.e., initially undetected paths through which a cyber-attack on the functional system can be carried out), various attacks (e.g., in the form of test vectors) on the functional system are defined during a security review of a functional system and then applied as system-specific test cases to the functional system to be tested as part of the security review. However, in order to be able to check and validate the effectiveness of the security measures and security improvements taken in the functional system (e.g., based on the attack graph) (e.g., fulfillment of the corresponding security requirements, etc.), it is necessary that, after the implementation and realization of the functional system, test cases are applied to the system that reflect the attacks identified as critical in the attack graph.For example, test scenarios can be created for a security check of the functional system.

[0017] In the context of this disclosure, a test scenario is an abstract description of a test case, wherein the actions for executing the test case are described in a system-independent or system-agnostic manner in the test scenario. For example, by supplementing the test scenario with concrete, system-specific information, data, and / or parameters after implementation of the functional system, the test scenario becomes the concrete, system-specific test case. The test scenarios for a respective functional system can be obtained, for example, from security analyses and / or from security requirements, in particular from attack trees. Currently, however, the definition and creation of such test scenarios are largely manual, which is relatively time-consuming.

[0018] Description of the invention

[0019] The invention is therefore based on the object of specifying a computer-implemented method by which test scenarios for security checks can be determined from a security and risk analysis of a functional system in a simple, resource-saving and automated manner.

[0020] These and other objects are achieved by a method, a test system, and a computer product according to the independent claims. Advantageous embodiments of the present invention are described in the dependent claims.

[0021] According to the invention, the object is achieved by a computer-implemented method of the type specified at the outset for generating test scenarios for a security check of a functional system which is used in a mobility application, by means of a test system, wherein at least one attack graph which was determined on the basis of the system model in a security and threat analysis is made available to the test system and is divided into respective attack paths in the test system, wherein in the test system each edge of a respective attack path is then assigned a corresponding abstract test module in which placeholder variables for system-specific information, data and parameters are provided, and wherein the test modules assigned to the edges are ordered according to an order of the edges in the respective attack path and combined to form a test scenario.

[0022] The main aspect of the proposed solution is that it allows for the automated generation of test scenarios for a security check of the functional system from an attack graph determined in a security and threat analysis based on the system model of the functional system. This means that the test scenarios for the security check of the functional system do not have to be manually created and entered into the test system, which is a time-consuming and resource-intensive process. Instead, they can be derived from the attack graph in a time- and resource-saving manner. Furthermore, these test scenarios can be used as a basis for validating and verifying the effectiveness of security measures implemented based on the attack graph or in the security and threat analysis and / or the fulfillment of security requirements.

[0023] Furthermore, it is advantageous if a test case is derived from the test scenario for a security check of the functional system. The placeholder variables in the test scenario are populated with system-specific information, data, and parameters of the functional system, and the derived test case is applied by the test system to the functional system. This allows the test scenarios based on the attack graph to generate specific test cases for the functional system under test. These test cases can be used during the security check to evaluate security measures and / or the fulfillment of security requirements of the specific functional system. Furthermore, any remaining threat potential can be easily visualized.

[0024] It is advantageous if, after dividing the attack graph into attack paths, at least one attack path of the attack graph is selected based on at least one predefined criterion. Ideally, a risk probability, an attack execution probability, or a threat potential can be used as a predefined criterion for selecting the at least one attack path. This means that for each attack path of the attack graph, a check is carried out to determine whether at least one predefined criterion, e.g., a predefined risk probability of an attack path is met or achieved by, for example, a risky component, a predefined execution probability that a certain attack path will be used by a potential attacker, etc.This makes it very easy to select attack paths in the attack graph with a high or very high risk for the system, or attack paths that have a high probability of being executed or are used by an attacker with a high or very high probability, and to generate test scenarios only from these. Attack paths with a low risk or low probability of being executed are neglected, for example, which can further increase the efficiency of the process. It is also advantageous if machine learning is used to assign the test modules to the edges of the respective attack path. This can, for example, be used in the test system based on knowledge and experience - such asrepeated assignment processes of test modules to edges - assignment rule can be learned and improved in order to be able to implement more complex rules for the assignment on the one hand and to improve the performance of the procedure and the test system on the other.

[0025] A practical embodiment of the method provides for the determined test scenario to be stored in a storage unit. This storage unit can be a database, for example, which is integrated into the test system or connected to the test system. The test scenarios can then be used at a later time—for example, after creating a prototype of a newly developed functional system, after implementing the functional system, etc.—to derive test cases for the security review.

[0026] Furthermore, the storage unit can also ideally be used to store abstract test modules, for example, through manual or automated input. Test modules can then be easily retrieved from the storage unit by the test system for assignment to the edges of the respective attack path. The abstract test modules can be determined, for example, from previous security checks.

[0027] Ideally, the attack graph is identified and test scenarios are created during the design or conception phase of the functional system, or during the planning of a change to the functional system. This allows security risks and potential threats to be identified very early in the development process of a new functional system or very early in the planning of changes to an existing functional system, and corresponding test scenarios for security testing can be developed.

[0028] Furthermore, it is advantageous if the test case is derived from the test scenario and applied after the functional system has been realized or implemented, or after the functional system has been changed. This allows the system-specific information, data, and parameters applicable to the specific functional system to be used to fill the placeholders in the test scenario to derive the test case from the test scenario. The test case is then adapted to the specific functional system in question, which is to be tested in the security check by applying the test case. The above-mentioned object is also achieved by a test system and a computer product. The test system has at least one computer unit that is configured to carry out the method according to the invention. The test system can expediently also have a storage unit, such asa database, or be connected to a storage unit, such as a database. Ideally, the abstract test modules are stored in this storage unit. Furthermore, this storage unit is configured to save the created test scenarios. Advantageously, the test system can also be connected to a machine learning system or have one, which supports the assignment of the test modules to the edges of the respective attack paths of the attack graph.

[0029] The computer program product can advantageously be loaded into the test system - for example into the at least one computer unit - and comprises instructions which, when the computer program product is executed in the test system, cause the computer program product to carry out the method according to the invention.

[0030] Short description of the characters

[0031] The present invention will be explained in more detail below with reference to Figures 1 to 2, which show exemplary, schematic and non-limiting advantageous embodiments of the invention.

[0032] Fig.1 shows a flow of the computer-implemented method for generating test scenarios for a safety check of a functional system

[0033] Fig.2 Assignment step and creation step of the method according to the invention using an exemplary attack graph

[0034] Implementation of the invention

[0035] Figure 1 shows an example sequence of a computer-implemented method with which at least one, but usually several test scenarios TS can be determined efficiently and automatically from an attack graph ATT, for example during a design or conception phase of a new functional system to be developed or during planning a change, further development and / or improvement of an existing functional system (e.g. update or replacement of one or more components of the functional system). The functional system can be used, for example, to implement mobility applications such as motor vehicles, etc., and / or the functional system is used in a mobility application such as autonomous driving, vehicle-to-vehicle communication, vehicle-to-X communication, etc. The test scenarios TS determined using the method according to the invention then serve as the basis for test cases which, for example, can be used after implementation orImplementation or after the system change has been carried out, whereby in particular compliance with safety requirements defined in the design or concept phase of the functional system or when planning the change to the functional system and the effectiveness of safety measures defined in the design or concept phase of the functional system or when planning the change to the functional system should be taken into account and checked.

[0036] A test case in the context of this disclosure is a test scenario TS adapted to the respective functional system to be tested and can, for example, be applied by a test system to the functional system to be tested as part of the security check. In the context of this disclosure, a test scenario TS is seen as an abstract description of a test case which defines what is to be tested and with which means, and in which individual test scenario phases can be described. A test scenario TS is composed, for example, of one or more abstract test modules TM1, TM2, TM3. An abstract test module TM1, TM2, TM3 represents a system-agnostic test building block which describes an individual phase of a test scenario TS or a step (e.g. attack step) in a test scenario TS using, for example, one or more symbolic or system-agnostic commands and is agnostic with respect to a specific functional system.For example, the abstract test modules TM1, TM2, and TM3 contain abstract placeholder variables that replace system-specific information, data, and parameters of a functional system. For simplicity, an abstract test module TM1, TM2, and TM3 will be referred to simply as test module TM1, TM2, and TM3, whereby this always refers to abstract or system-agnostic test modules TM1, TM2, and TM3.

[0037] The method can be carried out on an associated test system, wherein the test system has at least one computer unit. The test system represents an active system that automatically determines test scenarios from an attack graph according to a computer program product, which can be loaded, for example, into an internal memory of the test system and executed, for example, by means of the at least one computer unit or a processor. For this purpose, the computer program product comprises instructions which, when executed by the test system, cause the computer program product to carry out the steps of the method according to the invention. Furthermore, the test system can also be used for the security testing of a functional system, wherein the test system is then also configured to derive a test case for a functional system to be tested from a test scenario and to apply this test case, for example, to the functional system to be tested.The computer program product can also be designed accordingly and contain corresponding instructions.

[0038] In order to determine at least one test scenario TS from an attack graph ATT, the attack graph ATT is made available to the test system in an initial step 101. The attack graph ATT can be created manually or automatically with the aid of a corresponding utility program as part of a security and threat analysis, for example, during the design or conception phase of a new functional system or when planning a change, further development, or improvement of an existing functional system. The test system can, for example, have a corresponding interface for inputting the attack graph ATT or for transmitting the attack graph via the corresponding utility program. An attack graph ATT - as will be explained in more detail with reference to Figure 2 - has an output node RN, which represents an attack target or an overall target of an attacker (e.g.Access and control to a central control unit of the functional system) is defined, as well as at least one, but usually several attack paths that lead to the output node RN. In the initial step 101, the attack graph ATT in the test system is analyzed, for example, and divided into its attack path. Each attack path has at least one, usually several nodes N11, N12, N13, N21, N22. The nodes N11, N12, N13, N21, N22 represent sub-goals of attack actions or results of attack actions, such as an attack action has led to access to a component of the functional system. The nodes N11, N12, N13, N21, N22 of the respective attack paths are connected to each other or to the output node RN via edges K11, K12, K13, K21, K22, whereby the edges K11, K12, K13, K21, K22 represent the respective attack actions by which the attack target and / or the respective sub-goals are reached.Each attack path thus represents a possible cyber attack or an attack vector on the functional system in order to achieve the attack target defined by the exit node RN (e.g. access and control of a central control unit of the functional system).

[0039] In the initial step 101, after dividing the attack graph ATT into its attack paths, individual attack paths can be selected, which are then used to run through the further method steps 102, 103. The selection is made, for example, in the test system based on at least one predetermined criterion. A certain risk probability, probability of an attack being carried out, threat potential, etc. of the respective attack path can be used as a criterion. In this way, attack paths that pose a low risk or which have a low probability of being carried out by an attacker can be eliminated, for example in order to make the method more efficient. However, all attack paths determined from the attack graph can also be used for the further course of the method.

[0040] In an assignment step 102, each edge K11, K12, K13, K21, K22 of a respective attack path is then assigned a corresponding test module TM1, TM2, TM3. This means that, for example, the edges K11, K12, K13, K21, K22 of all attack paths determined in the initial step 101 or only the edges K11, K12, K13, K21, K22 of the attack paths selected based on the at least one predetermined criterion are mapped to test modules TM1, TM2, TM3. The test modules TM1, TM2, TM3 can, for example, originate from previous security checks of functional systems and be introduced into the test system through manual or automatically generated inputs. The test modules TM1, TM2, TM3 can, for example, be stored in the test system in an associated database. For this purpose, the database can be arranged, for example, in an internal storage unit of the test system or in a storage unit which is connected to the test system.In order to be able to store the test modules TM1, TM2, TM3 in an adequate form in the test system or in the database, or to easily assign them to the edges K11, K12, K13, K21, K22 in the assignment step 102, a corresponding description language—such as a so-called Domain Specific Language, or DSL for short—is used for the test modules TM1, TM2, TM3. A Domain Specific Language is a formal language designed and implemented for interactions between, for example, humans and digitally working units (e.g., computers) for a specific problem area—the so-called domain.

[0041] The assignment or mapping of a test module TM1, TM2, TM3 to an edge K11, K12, K13, K21, K22 in the assignment step 102 is carried out, for example, according to a set of rules or predetermined rules such that the test module TM1, TM2, TM3 assigned to an edge K11, K12, K13, K21, K22 in each case reproduces the attack action represented by the edge K11, K12, K13, K21, K22 in the form of the system-agnostic commands it contains. A relatively simple rule for the assignment would be, for example, that a certain test module TM 1 , TM2, TM3 is assigned to an edge K11 , K12, K13, K21 , K22 which, in an attack path, for example, connects a node N11 , N12, N13, N21 , N22 of a first type (e.g. access to an interface, external interface, etc.; control over a control unit, etc.) with a node N11 , N12, N13, N21 , N22 of a second type (e.g. control over a control unit, AND operation with another event, etc.).More complex rule sets or even machine learning can be used to assign the test modules TM1, TM2, and TM3 to the respective edges K11, K12, K13, K21, and K22 in the respective attack paths. For this purpose, the test system can, for example, be connected to or incorporate a machine learning system. After the assignment step 102, in which the respective edges K11, K12, K13, K21, K22 of the respective attack paths of the attack graph ATT were assigned the corresponding test modules TM1, TM2, TM3, in a creation step 103, the test modules TM1, TM2, TM3 assigned to the edges K11, K12, K13, K21, K22 of a respective attack path are ordered according to an order of the edges K11, K12, K13, K21, K22 in the respective attack path. The test modules TM1, TM2, TM3 are then combined to form a test scenario TS. This means, the selected test modules TM1 , TM2 , TM3 assigned to the edges K11 , K12, K13, K21 , K22 of an attack path are combined to form a test scenario TS.

[0042] The test scenarios TS created for the attack paths of the attack graph ATT can then be stored in the test system—e.g., in the associated database—in creation step 103. As with the test modules TM1, TM2, and TM3, the corresponding description language (e.g., Domain Specific Language) can be used to save the test scenarios. The saved test scenarios TS can then be used, for example, after the realization or implementation of the functional system or after the implementation of a change, extension, or improvement to the functional system for a security check in the test system.

[0043] For this purpose, a concretization step 104 can be carried out, for example, after implementation of the functional system or after modification, extension or improvement of the functional system. In the concretization step 104, concrete test cases for the security check of the functional system are then derived from the abstract test scenarios TS. For this purpose, the respective abstract placeholder variables in the test modules TM1, TM2, TM3 of the test scenarios TS are assigned information, data and parameters of the functional system to be tested. The system-specific information, data and parameters of the system currently to be tested can be provided for this purpose, for example, by a system manufacturer or by a client of the security check to be carried out. Alternatively or additionally, empirical values ​​from previous security checks of the same or a similar functional system can also be used.These empirical values ​​can, for example, also be stored in the test system or in the associated database. Alternatively or additionally, the system-specific information, data, and parameters can originate, at least in part, from a machine learning system instead of the database, which generates the information, data, and parameters based on empirical values. Furthermore, system-specific information, data, and parameters of the system under test, which can be used to populate the abstract placeholder variables in the test modules TM1, TM2, and TM3 of the test scenarios TS, can also be determined from an analysis of the functional system currently being tested (e.g., system scans, port scans, etc.) or from available manufacturer data.

[0044] After the concretization step 104, the concrete test cases derived from the abstract test scenarios TS are applied to the functional system to be tested in an application step 105. In application step 105, for example, during the ongoing security review, it can be assessed and documented whether the specified security requirements are met by the functional system and whether the security measures provided in the functional system are suitable for preventing, reducing, or withstanding potential cyberattacks.

[0045] Figure 2 shows, by way of example and schematically, the assignment step 102 and creation step 103 of the method according to the invention using an exemplary attack graph ATT, which was determined during a security and threat analysis for a functional system or on the basis of a system model of the functional system. The attack graph ATT has, for example, a hierarchical structure or tree structure with an output node RN, which defines the attack target or the overall goal of an attacker (e.g., access to and control of a central control unit of the functional system). Furthermore, the exemplary attack graph ATT shows two exemplary attack paths, each representing a possible cyber attack or an attack vector on the functional system, via which the attack target defined by the output node RN (e.g., access to and control of a central control unit of the functional system) is to be achieved.For example, a security objective (e.g., protection of the central control unit) can be derived from the attack target defined in the output node RN, which is then linked to a security requirement and / or security level to be met – corresponding to a potential impact on the security of the functional system. Furthermore, security requirements for the system or system competencies can be assigned to the security objective (e.g., protection of the central control unit).

[0046] A first attack path has, for example, the nodes N11, N12, N13, wherein a first node N11 is connected to a third node N13 via a first edge K11 and a second node N12 is connected to a third node N13 via a second edge K12. The third node N13 is connected to the output node RN via a third edge K13. In this case, a first node N11 represents, for example, a first sub-goal or event of an attack (e.g. taking control of an engine control unit) and a second node N12 represents, for example, a second sub-goal or event of an attack (e.g. taking control of a brake actuator). The first and second nodes N11, N12 are connected to a third node N13 via edges K11, K12, which represent attack actions. The third node N13 represents, for example, a link between the sub-goal or event of the first node N11 and the sub-goal or event of the second node N12 - ie, the sub-goal or eventThe event of the third node N13 is, for example, that both the subgoal of the first node N11 (e.g., control of the engine control unit) and the subgoal of the second node N12 (e.g., control of the brake actuator) must be achieved for the next attack action (i.e., attack on the central control unit) to occur. The third node N13 thus represents, for example, an AND operation of the previous attacks. The third node N13 of the first attack path is then connected, for example, to the output node RN via another edge K13.

[0047] A second attack path has, for example, two nodes N21, N22, with a fourth node N21 being connected to a fifth node N22 via a fourth edge K21. The fifth node N22 is then in turn connected to the exit node RN via a sixth edge K22. The second attack path represents, for example, a further or alternative attack option to the first attack path in order to reach the exit node RN or the attack target. In this case, the respective sub-goals of the fourth node N21 and the fifth node N22 (e.g. achieving control over a camera control unit or achieving control over an algorithm for autonomous driving) must be achieved one after the other in order to reach the exit node RN or the attack target. The fifth or sixth edge K21, K22 again represents the attack action required for this.

[0048] By means of the method according to the invention, the attack graph ATT is divided into its two exemplary attack paths in the initial step 101 in the test system. Subsequently, a respective test scenario TS can be created, for example, for both the first and the second attack path. Alternatively, one of the two attack paths can be selected according to at least one predetermined criterion in order to create a test scenario TS from it. Thus, for example, the first attack path can be selected in the initial step 101 because the second attack path represents a significantly lower risk for the functional system or the defined security objective, for example, it is very unlikely that an attacker will choose the second attack path to reach the attack target or the exit node RN, etc.

[0049] Figure 2 shows an example of how the corresponding test scenario TS is determined from the first attack path using the assignment step 102 and the creation step 103. For this purpose, each edge K11, K12, K13 of the first attack path of the attack graph ATT is assigned a corresponding abstract test module TM1, TM2, TM3. The assignment of the test modules TM1, TM2, TM3 to the corresponding edges K11, K12, K13 can be carried out according to a predetermined set of rules. For example, a first test module TM1 can be selected and assigned to the first edge K11, since the first edge K11 connects the first node N11 of the type "control over a control unit" with the third node N13 of the type "AND operation with another sub-goal / event". A second test module TM2 is, for example,selected and assigned to the second edge K12, since this connects the second node N12 of the type "control over an actuator" with the third node N13 of the type "AND operation with a further sub-goal / event". A third test module TM3, for example, is selected and assigned to the third edge K13, since this connects the third node N13 of the type "AND operation with a further sub-goal / event" with the output node RN. Instead of these simple rules, more complex rules or sets of rules and / or machine learning could be used to assign the test modules TM1, TM2, TM3 to the edges K11, K12, K13 of an attack path from the test system in the assignment step 102.

[0050] After the test modules TM1, TM2, TM3 have been assigned to the edges K11, K12, K13 of the first attack path of the attack graph ATT, the test modules TM1, TM2, TM3 are arranged in creation step 103 according to the order of the edges K11, K12, K13. This means that the first test module TM1, which was assigned to the first edge K11, is arranged first, followed by the second test module TM2, which was assigned to the second edge K12, and only then the third test module TM3, which was assigned to the third edge K13. This also allows the AND operation of the two sub-goals of the first and second nodes N11, N12 to be taken into account. This means that it is ensured that the third test module TM3 has access to the results of the nodes N11, N12 and that the dependencies between components of the functional system are taken into account.Subsequently, in creation step 103, the test modules TM1, TM2, TM3 arranged according to the edges K11, K12, K13 of the first attack path can be combined to form the test scenario for the first attack path. The test scenario TS can then be stored in the test system or in the associated database in order to derive a test case from the test scenario TS for a security check of the system, e.g., after the realization or implementation of the functional system or after modification, extension, or improvement of the functional system. This test case can be applied by the test system to the functional system during the security check.

[0051] Analogous to the procedure described above, a corresponding test scenario could also be created from the second attack path of the attack graph ATT. To do this, corresponding test modules TM1, TM2, TM3 would have to be assigned to the edges K21, K22 of the second attack path. These test modules TM1, TM2, TM3 would then have to be arranged in the order of the edges K21, K22 - i.e., the test module TM1, TM2, TM3 assigned to the fourth edge K21 is arranged before the test module TM1, TM2, TM3 assigned to the fifth edge K22. The test modules TM1, TM2, TM3 arranged in the order of the edges K21, K22 can then be combined to form a test scenario TS, which can also be saved in the test system or an associated database in order to derive a test case from it and apply this to the security check of the functional system.

Claims

Patent claims 1. A computer-implemented method for generating test scenarios (TS) for a security check of a functional system of a mobility application using a test system, wherein a system model of the functional system is created and, based on the system model, at least one attack graph (ATT) is determined in a security and threat analysis, which, starting from an output node (RN) defining an attack target, has at least one, usually several attack paths with nodes (N11, N12, N13, N21, N22), each representing a result of a respective attack action and / or a sub-goal of the respective attack action, and edges (K11, K12, K13, K21, K22) connecting the nodes (N11, N12, N13, N21, N22) of a respective attack path and representing the respective attack action for reaching the attack target, characterized in thatthat the at least one attack graph (ATT) is made available to the test system and is divided into attack paths in the test system (101), that each edge (K11, K12, K13, K21, K22) of the respective attack path is assigned a corresponding abstract test module (TM1, TM2, TM3) (102), in which placeholder variables for system-specific information, data and parameters are provided, and that the test modules (TM1, TM2, TM3) assigned to the edges (K11, K12, K13, K21, K22) are ordered according to an order of the edges (K11, K12, K13, K21, K22) in the respective attack path and combined to form a test scenario (TS) (103)., 2. Method according to claim 1, characterized in that for a security check of the functional system a test case is derived from the test scenario (TS) (104), wherein the placeholder variables in the test scenario (TS) are assigned system-specific information, data and parameters of the functional system, and that the derived test case is applied by the test system to the functional system (105).

3. Method according to one of the preceding claims, characterized in that after dividing the attack graph (ATT) into the attack paths, at least one attack path of the attack graph (ATT) is selected on the basis of at least one predetermined criterion (101).

4. Method according to claim 3, characterized in that a risk probability, an attack execution probability or a threat potential is used as a criterion for selecting the at least one attack path (101).

5. Method according to one of the preceding claims, characterized in that machine learning is used (102) to assign the test modules (TM1, TM2, TM3) to the edges (K11, K12, K13, K21, K22) of the respective attack path.

6. Method according to one of the preceding claims, characterized in that the respectively determined test scenario (TS) is stored in a storage unit (103).

7. Method according to one of the preceding claims, characterized in that the test modules (TM1, TM2, TM3) are determined from previous security checks and are stored in the storage unit by manual or automated input.

8. Method according to one of the preceding claims, characterized in that determining the attack graph (ATT) and creating test scenarios (TS) takes place during a design or conception phase of the functional system or during planning of a change to the functional system.

9. Method according to one of the preceding claims, characterized in that the test case is derived from the test scenario (TS) and the test case is applied after a realization or implementation of the functional system or the change of the functional system (104, 105).

10. Test system with at least one computer unit which is configured to carry out the method according to one of claims 1 to 9.

11. Test system according to claim 10, wherein the test system further comprises at least one storage unit and / or is connected to a storage unit in which the test modules are stored and / or which is configured to store created test scenarios (TS).

12. A computer program product, wherein the computer program product can be loaded into the test system according to one of claims 10 to 11, and wherein the computer program product comprises instructions which, when executed by the test system, cause the computer program product to carry out the method according to one of claims 1 to 9.

Images