EP4639351A1 - Verfahren zum adaptieren von testfällen für eine sicherheitsüberprüfung - Google Patents

Verfahren zum adaptieren von testfällen für eine sicherheitsüberprüfung

Info

Publication number
EP4639351A1
EP4639351A1 EP23837126.4A EP23837126A EP4639351A1 EP 4639351 A1 EP4639351 A1 EP 4639351A1 EP 23837126 A EP23837126 A EP 23837126A EP 4639351 A1 EP4639351 A1 EP 4639351A1
Authority
EP
European Patent Office
Prior art keywords
test
functional
tested
modules
abstracted
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP23837126.4A
Other languages
English (en)
French (fr)
Inventor
Stefan MARKSTEINER
Markus Wolf
Peter Priller
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
AVL List GmbH
Original Assignee
AVL List GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by AVL List GmbH filed Critical AVL List GmbH
Publication of EP4639351A1 publication Critical patent/EP4639351A1/de
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
    • G06F11/10—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
    • G06F11/1004—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's to protect a block of data words, e.g. CRC or checksum
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12—Protecting executable software
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577—Assessing vulnerabilities and evaluating computer system security
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G06F11/3668—Testing of software
    • G06F11/3672—Test management
    • G06F11/3684—Test management for test design, e.g. generating new test cases
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G06F11/3668—Testing of software
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1052—Security improvement

Definitions

  • the present invention relates to a computer-implemented method for adapting test cases for a safety check of a functional system to be tested in a mobility application, in particular from the automotive and/or aeronautics sector, using a test system. For this purpose, test cases are made available to the test system which have been used for safety unit checks of functional systems which are used in or for mobility applications.
  • the present invention also relates to an associated test system and an associated computer program product.
  • Examples of such functional systems include, in addition to the vehicles themselves, combinations of different external units/systems with vehicles or vehicle-internal units and systems, combinations of vehicle-internal systems and units, and combinations of several vehicles or units/systems of several vehicles.
  • an autonomous computer unit e.g. tablet, smartphone, etc.
  • a unit or system in an (autonomous) vehicle e.g. infotainment system, GPS, navigation system, etc.
  • vehicles or in-vehicle systems can exchange data or information with infrastructure units (e.g. traffic lights, barrier systems, etc.) via radio, for example.
  • infrastructure units e.g. traffic lights, barrier systems, etc.
  • units and systems within a vehicle can communicate with other units and systems (e.g. braking system, engine, etc.) via interfaces.
  • units and systems e.g. braking system, engine, etc.
  • several vehicles can also communicate with each other via radio, for example, in order to carry out tasks together - such as being coupled together in the sense of a virtual drawbar, or to implement mobility applications such as vehicle-to-vehicle communication for exchanging information and data between vehicles.
  • 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 its implementation.
  • a mobility application e.g. vehicle, autonomous driving, ADAS, vehicle-to-infrastructure or vehicle-to-vehicle applications, etc.
  • the components of such a functional system usually have their own storage units and communication interfaces and therefore each form their own computer system. Such components are also referred to as “embedded systems - ES” and perform their tasks - largely invisibly - within the functional system.
  • embedded systems - ES embedded systems
  • Components of such functional systems can also be so-called “cyber-physical systems - CPS”.
  • a cyber-physical system is usually understood to be a network of software units with mechanical and electronic parts that communicate via a data infrastructure (e.g.
  • 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.).
  • mobility applications e.g. networked security systems, networked driver assistance systems, etc.
  • Communication interfaces include the various wireless connection protocols, such as mobile communications protocols (e.g. 5G, LTE, etc.), Bluetooth, WirelessLAN, RFID, Vehicle-to-X interfaces, etc., which are sometimes used simultaneously.
  • mobile communications protocols e.g. 5G, LTE, etc.
  • Bluetooth e.g.
  • WirelessLAN e.g.
  • RFID e.g.
  • Vehicle-to-X interfaces e.g.
  • DoS denial-of-service
  • the security check is intended to enable manufacturers ("Original Equipment Manufacturer” - OEM), government agencies (e.g. registration authorities), and other stakeholders (e.g. consumer associations, commercial fleet operators, etc.) to assess the specific risk of a functional system of a mobility application, such as a vehicle, etc., in relation to cyber attacks. This can be used in the further development or improvement of the vehicles or the functional system, for acceptance or certification and similar tasks.
  • the security check is intended to uncover existing but initially mostly unknown vulnerabilities and potential points of attack for cyber attacks in the functional systems (e.g. vehicle, etc.).
  • a security check of a functional system defines various attacks (e.g. in the form of test vectors) on the functional system to be tested and then applied as system-specific test cases to the functional system to be tested as part of the security check.
  • safety checks are required both during the development of a new vehicle at the OEM, during market launch/type approval/homologation, and later continuously throughout the entire lifespan of the vehicle or the respective functional system.
  • the need for repeated safety checks at system test level and thus an ongoing review of cyber security arises due to changeable configurations, ongoing updates of (parts of) software components, changed environmental conditions (e.g. vehicle-to-infrastructure - V2I, vehicle-to-vehicle - V2V: changes in interaction partners), newly discovered test vectors (also from in-house safety research), etc.
  • the safety check can be carried out not only by the manufacturer, but also by (fleet) operators, approval authorities and/or specialized third-party companies.
  • test cases for security checks that are suitable for making statements about the security or cyber security of functional systems with the same functionality, e.g. from different manufacturers. Even updates to components of a functional system or an update of a functional system can lead to new test cases being created for the security check or at least existing ones being revised. Test cases must be adapted.
  • test cases for security checks must therefore be system-specific and individually created, or at least adapted, for each functional system to be tested. Vulnerabilities and possible points of attack may be similar, but existing test cases cannot be transferred directly from a functional system that has already been tested to a functional system that is still to be tested due to the individual design of the functional system to be tested. This means that the test cases for the security check must be individually and often manually adapted to the functional system to be tested.
  • security checks of functional systems such as vehicles, parts or subsystems of vehicles that are used in mobility applications, involve a great deal of time and resources.
  • the document US 2005/0160322 A1 discloses a method and a system by which a specific automation test script for detecting errors in an application is converted into an abstract test case representation.
  • the abstract test case representation is then stored in a database for reuse.
  • One or more application states, external interaction sequences and input data are stored for the abstract test case representation and the abstract test representation can be supplemented with information from an application metadata repository so that it can be used to test the application in other test environments or on another test platform.
  • test cases can be abstracted for testing an application, but the abstract test case representation can only be used to test the same application in another test environment or on another test platform.
  • the invention is therefore based on the object of specifying a method by means of which test cases which have already been used in security checks for testing functional systems and/or can be used for such security checks can be adapted and reused for security checks of further functional systems which are still to be tested in a simple, resource-saving and automated manner.
  • the problem is solved by a computer-implemented method for adapting test cases for a security check of a functional system, which is used in a mobility application, by means of a test system.
  • the test cases that have already been used in security checks on functional systems used in mobility applications and/or are applicable for such security checks are made available to the test system. The following steps are carried out:
  • test modules whereby system-specific information, data and parameters of the functional systems to which the respective test cases were applied, contained in the test modules, are replaced by abstract placeholder variables in a respective test module;
  • test cases that are already known or that are already used and/or usable for security checks of functional systems in mobility applications can be generalized in a simple and resource-saving manner and made usable for security checks of new functional systems to be tested, with the adaptation to the new functional system to be tested being carried out automatically.
  • the method according to the invention automatically "recycles" test cases that have already been used for security checks of new functional systems to be tested. This means that new test scenarios and specific test cases do not have to be developed for each new functional system to be tested, but rather test cases that have already been used and/or are applicable to other functional systems in security checks can be used and these can then be automatically adapted for the security check of the new functional system to be tested. This saves resources and time during the security check.
  • test modules are searched for required parameters that must be made available by the functional system to be tested or at least one of the preceding test modules to carry out the respective test module.
  • required parameters can be stored in a parameter list in the test system, whereby the respective parameter list is linked to the test module abstracted from the respective test module.
  • relations between individual parameters can also be stored in the parameter lists so that they can then be used when creating test scenarios.
  • the parameter lists can also be used to quickly identify and eliminate test scenarios that are not useful, do not function and/or do not lead to the desired result when, for example, required parameters are not available due to a sequence and/or combination of test modules, etc.
  • the parameter lists can also be used to include appropriate further steps in the test scenario in order to determine these parameters - especially when applying the test case derived from the respective test scenario.
  • the creation and execution of these steps, such as determining the parameter or parameter value from the functional system to be tested, etc., can be automated, for example.
  • the parameter lists linked to the respective abstracted test modules of the respective test scenario are used to find the placeholder variables of the required parameters in the respective test scenario.
  • the Placeholder variables and, if applicable, relations between them can be quickly and easily recognized and used.
  • the abstracted test modules and/or abstract test scenarios and/or parts of abstract test scenarios are stored in the test system, in particular in a database. This allows them to be reused for subsequent security checks of functional systems to be tested. On the one hand, test cases can then be adapted more quickly to new functional systems to be tested, and on the other hand, this creates a test module and scenario database, thus further accelerating the method according to the invention. It can also be advantageous if, before storing the respective abstracted test module, a check is made to see whether the respective abstracted test module is already stored in the test system, in particular in the database. This makes it very easy to prevent abstracted test modules from being stored multiple times.
  • test system Ideally, information is stored in the test system for each abstract test scenario, indicating which functional system the respective test scenario can be applied to. This allows suitable test scenarios to be found quickly and with little effort for security checks of functional systems to be tested.
  • An expedient embodiment of the method provides that the system-specific information, data and parameters of the functional system to be tested for occupying the placeholder variables in the abstracted test modules of the respective test scenarios are provided by the test system, in particular by the database in which empirical values from previous security checks of an identical or similar functional system are stored, and/or by a system manufacturer and/or are determined by means of machine learning from empirical values from previous security checks.
  • values which are determined from an analysis of the functional system to be tested can also be used as system-specific information, data and parameters of the functional system to be tested for occupying the placeholder variables in the abstracted test modules of the respective test scenarios.
  • the above-mentioned object is also achieved by a test system and a computer product.
  • the test system has at least one computer unit which is set up to carry out the method according to the invention.
  • the test system can expediently also comprise a storage unit, such as a database, or be connected to a storage unit, such as a database.
  • This storage unit is ideally set up to store the abstracted test modules, the abstract test scenarios and/or parts of abstract test scenarios as well as experience values from previous Security checks of the same or similar functional system can also be connected to a machine learning system or have one with which the system-specific information, data and parameters of the functional system to be tested can be determined from experience, etc. to fill the placeholder variables in the abstracted test modules of the respective test scenarios.
  • 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.
  • Fig.1 a flow of the computer-implemented method for adapting test cases of a security test of a functional system to be tested
  • Fig.2a an abstraction step of the method according to the invention based on a concrete embodiment
  • Fig.2b shows a synthesis step of the method according to the invention based on the concrete embodiment
  • Fig.2c shows a concretization step of the method according to the invention based on the concrete embodiment.
  • Figure 1 shows an example of a computer-implemented method with which test cases TC1, which have already been used in safety checks of functional systems, through which, for example, mobility applications (e.g. motor vehicles, etc.) are implemented and/or which are used in mobility applications (e.g. autonomous driving, vehicle-to-vehicle communication, vehicle-to-X communication, etc.), can be automatically adapted for a safety check of a functional system to be tested (e.g. vehicle, vehicle system, etc.).
  • the functional system to be tested can be a newly developed functional system, a further development and/or improvement of an existing functional system or a functional system in which, for example, individual components (e.g. hardware units, software units, etc.) have been replaced or updated.
  • 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 carries out the security check of a system to be tested according to a computer program product, which can be loaded into an internal memory of the test system and carried out by means of the at least one computer unit or a processor, for example.
  • the computer program product comprises commands which, when executed by the test system, cause the computer program product to carry out the steps of the method according to the invention.
  • the test system carries out corresponding test cases TC1, TC21, ..., TC23, for example to uncover weak points in the functional system to be tested.
  • the test system can, for example, provide interfaces and an environment (e.g. a test bench or test bed for mobility applications, etc.) and, together with the functional systems to be tested, form a test environment in which the method according to the invention is then carried out.
  • an environment e.g. a test bench or test bed for mobility applications, etc.
  • test cases TC1 that have already been used in security checks on other functional systems are available. This means that the test system knows test cases TC1 that have already been used in security checks on functional systems used in mobility applications and/or that can be used for such security checks.
  • test case TC1, TC21, ..., TC23 is a test scenario TS1, TS2, TS3 adapted to the respective functional system to be tested and can, for example, be carried out on the test system and the functional system to be tested as part of the security check.
  • a test scenario TS1, TS2, TS3 is seen as an abstract description of a test case TC1, TC21, ..., TC23, which defines what is to be tested and with which means, and in which individual test scenario phases can be described.
  • Test scenarios TS1, TS2, TS3 for functional systems can, for example, be obtained from security analyses and/or from security requirements.
  • test system In order to adapt a concrete test case TC1, which has already been applied to a functional system using the test system, for another functional system that is currently to be tested, the test system carries out the steps described below and shown as examples in Figure 1.
  • test cases TC1 already used for testing functional systems are analyzed by the test system and divided or broken down into individual test modules T11, T12, T13, T14.
  • a test module T11, T12, T13, T14 can, for example, be a test script which, when executed, represents a targeted attack on the functional system. If necessary, the test module T11, T12, T13, T14 can also consist of just one or more commands.
  • test modules T11, T12, T13, T14 determined from the test cases TC1 are then abstracted.
  • the system-specific information, data and parameters of the functional system to which the respective test case TC1 was applied contained in the test modules T11, T12, T13, T14 are replaced by abstract placeholder variables.
  • abstracted test modules a1, a2, a3, a4 are thus created from the concrete test modules T11, T12, T13, T14, which are system-specifically adapted for a respective test case TC1.
  • An abstracted test module a1, a2, a3, a4 thus represents a system-agnostic test module, which describes a single phase of a test scenario TS1, TS2, TS3 and is agnostic with respect to a specific functional system.
  • the abstracted test modules a1, a2, a3, a4 can be stored in the test system, e.g. in an associated database.
  • the database can be located in an internal storage unit of the test system or in a storage unit that is connected to the test system, for example. Before storing the respective abstracted test module a1, a2, a3, a4, it can be checked whether this test module a1, a2, a3, a4 is already stored in the test system or in the associated database.
  • an appropriate description language - such as a so-called Domain Specific Language, or DSL for short - is used for the abstracted test modules a1, a2, a3, a4.
  • a domain specific language is a formal language that is designed and implemented for interactions between, for example, people and digitally working units (e.g. computers) for a specific problem area - the so-called domain.
  • the test modules T11, T12, T13, T14 can be searched for required parameters before abstraction.
  • Required parameters are, for example, parameters that are absolutely necessary for a meaningful execution of the respective test module T11, T12, T13, T14. These parameters can, for example, be provided by the functional system to be tested or by one of the preceding test modules T11, T12, T13, T14 in the respective test case TC1. However, they can also be obtained from an external source, such as a database, machine-readable specification, etc. or entered as manual input.
  • Such parameters would be, for example, network addresses of a test target, an identification and/or a concrete mapping address, etc., which must be present when sending a specific command via a component or to a component of the functional system to be tested for the execution of the test module T11, T12, T13, T14, or configuration data.
  • These parameters define, for example, properties (in one step) of the respective test module T11, T12, T13, T14 - such as to which network address or to which port number a certain message should be sent or how long this message should be.
  • Required parameters can occur in every test module T11, T12, T13, T14 and can be specific to the respective test module T11, T12, T13, T14. There can also be required parameters which are necessarily the same for all test modules T11, T12, T13, T14, e.g. of a test case TC1 or also other test cases TC21, TC22, TC23 for the respective functional system, such as port number. Such parameters can, for example, be defined once for all test modules T11, T12, T13, T14 of a test case TC1 as "global" parameters.
  • the determined, required parameters of the respective test module T11, T12, T13, T14 can then be summarized in a parameter list, for example.
  • a parameter list for example.
  • relationships between individual, required parameters can also be saved in the parameter list, e.g. individual parameters must have the same values or result from a combination of other parameters.
  • the parameter lists can then be linked to the abstracted test module a1, a2, a3, a4 generated from the respective test module T11, T12, T13, T14. To do this, for example, the respective parameter list can be saved in the test system or in the associated database with the respective abstracted test module a1, a2, a3, a4.
  • abstract test scenarios TS1, TS2, TS3 are created for the security check of the functional system to be tested by combining the abstracted test modules a1, a2, a3, a4.
  • Abstracted test modules a1, a2, a3, a4, a5, which were generated from various - for example, already applied and/or applicable - test cases TC1, can be combined to form new test scenarios TS1, TS2, TS3 for the security check of the functional system to be tested.
  • the created test scenarios TS1, TS2, TS3 or at least part of the created test scenarios TS1, TS2, TS3, TS4 can also be saved in the test system or in the associated database, for example for reuse for similar or the same test requirements. This can also be done for the test scenarios TS1, TS2, TS3 how the corresponding description language (e.g. Domain Specific Language) is used for the abstracted test modules a1, a2, a3, a4, a5.
  • the corresponding description language e.g. Domain Specific Language
  • each newly created test scenario TS1, TS2, TS3 can be searched for the required parameters which are to be determined or provided by the functional system to be tested and/or at least one of the preceding test modules T21, T22, T23, T24, T25 when carrying out a test case TC21, TC22, TC23 derived from the test scenario TS1, TS2, TS3 in a test module T21, T22, T23, T24, T25.
  • a test case TC21, TC22, TC23 derived from the test scenario TS1, TS2, TS3 in a test module T21, T22, T23, T24, T25 ineffective, non-functional and/or non-sensible test scenarios TS1, TS2, TS3 (e.g.
  • the parameter lists that were created in the abstraction step 102 can be used, for example.
  • the parameter lists that are linked to the abstracted test modules a1, a2, a3, a4, a5 used in the test scenario TS1, TS2, TS3 are used for this purpose.
  • concrete test cases TC21, TC22, TC23 for the security check of the functional system to be tested are then derived from the abstract test scenarios TS1, TS2, TS3.
  • the respective abstract placeholder variables in the abstracted test modules a1, a2, a3, a4, a5 of the test scenarios TS1, TS2, TS3 are filled with 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 made available 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.
  • empirical values can also be stored, for example, in the test system or in the associated database.
  • the system-specific information, data and parameters can come at least partially from a machine learning system instead of from the database, which generates the information, data and parameters on the basis of empirical values.
  • system-specific information, data and parameters of the system to be tested, with which the abstract placeholder variables in the abstracted test modules a1, a2, a3, a4, a5 of the test scenarios TS1, TS2, TS3 can be assigned can also be determined from an analysis of the functional system currently being tested (e.g. scans on the system, port scan, etc.) or from available manufacturer data.
  • the concrete test cases TC21, TC22, TC23 derived from the abstract test scenarios TS1, TS2, TS3 are applied to the functional system to be tested in an application step 105.
  • the application step 105 for example, during the ongoing security check, it can be documented which concrete test cases TC21, TC22, TC23 are particularly well suited to uncovering vulnerabilities, which test cases TC21, TC22, TC23 deliver the best result, which test cases TC21, TC22, TC23 do not deliver particularly good results, which test cases TC21, TC22, TC23 do not work or only work incorrectly on the functional system to be tested, etc.
  • information collected during the implementation of the security check on the respective test cases TC21, TC22, TC23 can then be transmitted to the test system in a feedback step 106.
  • a feedback can be created for each test case TC21, TC22, TC23, which contains, for example, information on the implementation of the respective test case TC21, TC22, TC23.
  • the feedback can then be transmitted to the test system and linked there, for example, with the test scenarios TS1, TS2, TS3 from which the test cases TC21, TC22, TC23 were derived.
  • test cases TC21, TC22, TC23 that work particularly well or test cases TC21, TC22, TC23 that do not work or only work incorrectly.
  • information can be stored about which functional system the respective test scenario TS1, TS2, TS3 has already been used on. This means that during a new security check of the same or a similar functional system in the test system, test scenarios TS1, TS2, TS3 that have already been tested and found to be successful or functioning well can be identified in the synthesis step 103 and used again in the concretization step 104 to generate test cases TC21, TC22, TC23.
  • test scenarios TS1, TS2, TS3 that do not work or are unsuitable for certain functional systems or are pointless (e.g. due to the test module sequence, cannot be executed on a functional system due to required parameters, etc.) can be eliminated very easily from the test system or the associated database.
  • the test system can thus be continuously improved and learn from security checks that have already been carried out - in particular concretization steps 104.
  • a safety test for a specific vehicle is to be carried out for which, for example, after a new development of one or more Components or after an update of one or more components, a security check must be carried out.
  • the aim is to identify, for example, weak points or points of attack for cyber attacks on this vehicle.
  • Figure 2a shows an example of the abstraction step 102.
  • This assumes, for example, an example concrete test case TC1 which has already been applied to a similar functional system (e.g. vehicle from another manufacturer, etc.) or to the same functional system (e.g. vehicle before a component exchange or update).
  • the test case TC1 represents, for example, a concrete attack vector on a functional system which has already been subjected to a security check. With this concrete attack vector, an attempt was made, for example, to reach the engine control of the functional system or vehicle via an attack on an external interface (e.g. Bluetooth, radio, etc.) of the functional system.
  • an external interface e.g. Bluetooth, radio, etc.
  • the example test case TC1 can, for example, be divided into four test modules T11, T12, T13, T14 in the modularization step 101.
  • Each test module T11, T12, T13, T14 corresponds to a specific attack on a component or on a subsystem of the functional system or vehicle being tested.
  • the first test module T11 can, for example, represent an attack on an external interface of the vehicle, with which, for example, existing external interfaces (e.g. wireless communication interface, sensors, etc.) are located.
  • a second test module T12 attempts to access the vehicle's infotainment system, for example, after a successful attack using the first test module T11.
  • a third test module T13 attempts to attack or use the vehicle's internal network, for example. If the third test module T13 is successful, an attempt is made, for example, in a fourth test module T14 to take over the engine control of the vehicle.
  • the concrete test modules T11, T12, T13, T14, into which the concrete test case TC1 was divided, are now abstracted.
  • the test modules T11, T12, T13, T14 are thus converted into abstracted test modules a1, a2, a3, a4, which describe the respective attacks in an abstract manner.
  • an abstracted test module a1 derived from the first test module T11 can contain the description to search for a wireless interface of (any) functional system and to establish a connection with it.
  • a second abstracted test module a2 derived from the second test module T12 can, for example, contain the description of establishing a connection to a component or subsystem of the functional System which can be reached via the interface found.
  • a third abstracted test module a3 derived from the third test module T13 for example, the use of an internal network of the functional system is described abstractly.
  • a fourth abstracted test module a4 can, for example, describe the assumption of control of the functional system in abstract terms.
  • the abstracted test modules a1, a2, a3, a4 can then be stored in the test system or in the associated database, for example, provided that these abstracted test modules a1, a2, a3, a4 are not already stored in the test system or in the associated database.
  • test modules T11, T12, T13, T14 can be searched for required parameters before abstraction and test module-specific parameter lists can be created accordingly.
  • the respective test module-specific parameter list can be linked to the respective abstracted test module a1, a2, a3, a4 and stored with it in the test system or in the associated database.
  • Figure 2b shows the synthesis step 103 of the method based on the embodiment, such as a safety check of a vehicle currently being tested.
  • the abstracted test modules a1, a2, a3, a4, a5 are combined to form abstract test scenarios TS1, TS2, TS3, with each test scenario TS1, TS2, TS3 representing an abstract description of a possible attack vector.
  • the abstracted test modules a1, a2, a3, a4 derived from the concrete test case TC1 in the abstraction step 102 as well as further abstracted test modules a5 which were abstracted from test cases TC1 of other, already carried out safety checks can be used.
  • abstracted test modules a5 can also be used, which are already stored in the test system or in the associated database.
  • the abstracted test modules a1, a2, a3, a4 generated in the abstraction step 102 shown in Figure 2a are combined to form a first test scenario TS1.
  • second test scenario TS2 for example, the second, third and fourth abstracted test modules a2, a3, a4 from the concrete test case TC1 are combined with a fifth abstracted test module a5 (e.g. an abstract description that a connection to a system-internal component (e.g. gateway) is to be established and/or used), with the fifth abstracted test module a5 being inserted, for example, between the third and fourth abstracted test modules a3, a4.
  • a fifth abstracted test module a5 e.g. an abstract description that a connection to a system-internal component (e.g. gateway) is to be established and/or used
  • third test scenario TS3 the second, third and fourth abstracted test modules a2, a3, a4 are also combined with the fifth abstracted test module a5, whereby in the third test scenario the fifth abstracted test module a5 is arranged, for example, between the second and the third abstracted test module a2, a3.
  • abstract test scenarios TS1, TS2, TS3 can be created from the test system using any combination of the abstracted test modules a1, a2, a3, a4, a5.
  • a5 such as a combination in which, for example, the fourth abstracted test module a4 (e.g. taking over control of the functional system) is arranged before the first test module a1 (e.g.
  • the created, abstract test scenarios can be searched for required parameters, for example, or the parameter lists stored in the respective abstracted test modules a1, a2, a3, a4, a5 can be evaluated.
  • suggestions for combinations of abstracted test modules a1, a2, a3, a4, a5 available in the test system or in the associated database can be used to create test scenarios TS1, TS2, TS3.
  • the created abstract test scenarios TS1, TS2, TS3 or at least part of them can be stored in the synthesis step 103 in the test system or in the associated database - for example as suggestions for creating test scenarios TS1, TS2, TS3 in later synthesis steps 103.
  • Figure 2c shows the concretization step 104 of the method based on the concrete embodiment - e.g. the safety check of a vehicle currently being tested.
  • concrete test cases TC21, TC22, TC23 for the functional system currently being tested - e.g. a vehicle with at least one newly developed or updated component - are derived from the abstract test scenarios TS1, TS2, TS3 created in the synthesis step 103.
  • the abstract placeholder variables in the abstracted test modules a1, a2, a3, a4, a5 of the respective test scenarios TS1, TS2, TS3 are filled with system-specific information, data and parameters of the functional system or vehicle currently being tested.
  • the first test scenario TS1 thus becomes a concrete, first test case TC21 for the safety check of the vehicle currently being tested.
  • the second test scenario TS2 or the third test scenario TS3 become a specific, second test case TC22 or a specific, third test case TC23.
  • the system-specific information, data and parameters can come from the client of the safety check or from the manufacturer's data for the vehicle. For example, experience from previous safety checks of the vehicle or similar vehicles can be used or data from analyses, etc. of the vehicle currently being tested can be used.
  • the test cases TC21, TC22, TC23 derived in the concretization step 104 are then used in the application step 105 for the safety check of the functional system or vehicle currently being tested.
  • test cases TC21, TC22, TC23 can then be transmitted to the test system in the feedback step 106 in the form of feedback on the test cases TC21, TC22, TC23. There they can be linked and stored with the corresponding test scenarios TS1, TS2, TS3 in order to be able to use the feedback again in subsequent safety checks of functional systems.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Computing Systems (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Die Erfindung betrifft ein computerimplementiertes Verfahren zum Adaptieren von Testfällen (TC1) für eine Sicherheitsüberprüfung eines zu testenden funktionalen Systems einer Mobilitätsanwendung, insbesondere aus dem Automotive- und/oder Aeronautik-Bereich, mittels eines Testsystems sowie das Testsystem und ein zugehöriges Computerprogrammprodukt. Dem Testsystem werden dabei Testfälle (TC1) zur Verfügung gestellt, welche bereits für Sicherheitsüberprüfungen von funktionalen Systemen, welche in oder für Mobilitätsanwendungen zum Einsatz kommen, angewendet wurden und/oder für derartige Sicherheitsüberprüfungen anwendbar sind. Dabei werden folgende Schritte ausgeführt: Unterteilen der Testfälle (TC1) in Testmodule (T11,..., T14) (101); - Abstrahieren der Testmodule (T11,..., T14), wobei in den Testmodulen (T 11,..., T14) enthaltene, systemspezifische Informationen, Daten und Parameter der funktionalen Systeme, auf welche die jeweiligen Testfälle (TC1) angewendet wurden, in einem jeweiligen Testmodul (T11,..., T14) durch abstrakte Platzhaltervariablen ersetzt werden (102); Erstellen von abstrakten Testszenarien (TS1, TS2, TS3) für die Sicherheitsprüfung des zu testenden funktionalen Systems, wobei für ein Testszenario (TS1, TS2, TS3) die abstrahierte Testmodule (a1,..., a5) kombiniert werden (103); - Ableiten von Testfällen (TC21, TC22, TC23) für das zu testende funktionale System aus den abstrakten Testszenarien (TS1, TS2, TS3), wobei die jeweiligen abstrakten Platzhaltervariablen in den abstrahierten Testmodulen (a1,..., a5) eines jeweiligen Testszenarios (TS1, TS2, TS3) mit entsprechenden systemspezifischen Informationen, Daten und Parametern des zu testenden funktionalen Systems belegt werden (104); und - Anwenden der aus den Testszenarien (TS1, TS2, TS3) abgeleiteten Testfälle (TC21, TC22, TC23) auf das zu testende funktionale System (105).

Description

Verfahren zum Adaptieren von Testfällen für eine Sicherheitsüberprüfung
Technisches Gebiet
Die gegenständliche Erfindung betrifft ein computerimplementiertes Verfahren zum Adaptieren von Testfällen für eine Sicherheitsüberprüfung eines zu testenden funktionalen Systems einer Mobilitätsanwendung, insbesondere aus dem Automotive- und/oder Aeronautik-Bereich, mittels eines Testsystems. Dem Testsystem werden dazu Testfälle zur Verfügung gestellt, welche für Sichereinheitsüberprüfungen von funktionalen Systemen, welche in oder für Mobilitätsanwendungen zum Einsatz kommen, angewendet wurden. Weiterhin bezieht sich die gegenständliche Erfindung auf ein zugehöriges Testsystem und ein zugehöriges Computerprogrammprodukt.
Stand der Technik
Viele moderne technische Geräte, insbesondere Fahrzeuge, weisen ab einem gewissen Komplexitätsgrad eine Vielzahl an eingebetteten und untereinander vernetzten Komponenten auf, die jeweils mit eigenen Prozessoren oder Microcontrollern versehen sind. Die gegenständliche Offenbarung ist jedoch nicht nur auf Fahrzeuge im eigentlichen Sinn beschränkt, sondern kann auch in Verbindung mit anderen technischen Einheiten und Systemen, welche eine Vielzahl untereinander vernetzter Komponenten aufweisen und vor allem im Automotive- und/oder Aeronautik-Bereich in Mobilitätsanwendungen - d.h. z.B. in Fahrzeugen oder in deren Umfeld - zum Einsatz kommen, verwendet werden. Im Zusammenhang mit der gegenständlichen Offenbarung werden diese allgemein unter dem Begriff „funktionales System“ zusammengefasst. Das bedeutet, ein derartiges funktionales System kann beispielsweise ein Fahrzeug selbst (z.B. Kraftfahrzeug, Lkw, Luftfahrzeuge, etc.) oder ein komplexes System sein, welches in einem Fahrzeug oder in Verbindung mit einem Fahrzeug zur Realisierung von Mobilitätsanwendungen zum Einsatz kommt.
Zu Beispielen derartiger funktionaler Systeme zählen neben den Fahrzeugen selbst unter anderem Kombinationen aus unterschiedlichen externen Einheiten/Systemen mit Fahrzeugen oder fahrzeuginternen Einheiten und Systemen, Kombinationen aus fahrzeuginternen Systemen und Einheiten sowie Kombinationen aus mehreren Fahrzeugen bzw. Einheiten/Systemen mehrerer Fahrzeuge. So können beispielsweise bestimmte Aufgaben von einer autonomen Computereinheit (z.B. Tablet, Smartphone, etc.) ausgeführt werden, welche über eine Schnittstelle mit einer Einheit oder einem System in einem (autonomen) Fahrzeug (z.B. Infotainmentsystem, GPS, Navigationssystem, etc.,) kommuniziert. Bei Mobilitätsanwendungen, wie z.B. dem autonomen Fahren (AD) oder der so genannten Vehicle-to-X-Kommunikation können Fahrzeuge oder fahrzeuginterne Systeme mit Infrastruktureinheiten (z.B. Ampeln, Schrankenanlagen, etc.) beispielsweise über Funk Daten oder Informationen austauschen. Weiterhin können bei Mobilitätsanwendungen, wie z.B. Fahrassistenzsystemen oder so genannte Advanced Driving Assistance Systems (kurz: ADAS) beispielsweise innerhalb eines Fahrzeugs Einheiten und Systeme (z.B. Sensoren, etc.) mit anderen Einheiten und Systemen (z.B. Bremssystem, Motor, etc.) über Schnittstellen kommunizieren. Andererseits können auch mehrere Fahrzeuge untereinander beispielsweise über Funk kommunizieren, um gemeinsam Aufgaben auszuführen - wie etwa im Sinne einer virtuellen Deichsel aneinandergekoppelt zu werden, oder um Mobilitätsanwendungen, wie z.B. Vehicle-to-Vehicle-Kommunikation zum Austausch von Informationen und Daten zwischen den Fahrzeugen, zu realisieren. Weiterhin kann beispielsweise ein Fahrzeug, wie z.B. ein Spezialfahrzeug im Baubereich, in der Landwirtschaft, ein Einsatzfahrzeug, etc. mit einem oder mehreren On-Board-Geräten verbunden sein. Derart kombinierte Einheiten oder Systeme werden im Sinne der gegenständlichen Offenbarung als funktionales System angesehen, welches in einer Mobilitätsanwendung (z.B. Fahrzeug, autonomes Fahren, ADAS, Vehicle-to-lnfrastructure- oder Vehicle-to-Vehicle-Anwendungen, etc.) zum Einsatz kommt bzw. für deren Realisierung verwendet wird.
Üblicherweise verfügen die Komponenten eines solchen funktionalen Systems über eigene Speichereinheiten und Kommunikationsschnittstellen und bilden daher jeweils ein eigenes Computersystem. Solche Komponenten werden auch als „Embedded Systems - ES“ bezeichnet und verrichten - weitgehend unsichtbar - ihre Aufgaben innerhalb des funktionalen Systems. Im Fall eines komplexen Gesamtsystems (z.B. Fahrzeug, Flugzeug, etc.) wird meist eine Vielzahl von ansonsten autonomen eingebetteten Systemen vernetzt. Komponenten solcher funktionalen Systeme können auch so genannte „Cyber-Physical Systems - CPS“ sein. Unter einem Cyber-Physical System wird üblicherweise ein Verbund von softwaretechnischen Einheiten mit mechanischen und elektronischen Teilen verstanden, welche über eine Dateninfrastruktur (z.B. Internet, Bussystem, etc.) kommunizieren, wobei ein Cyber-Physical System beispielsweise durch Vernetzung von eingebetteten Systemen über ein drahtgebundenes und/oder drahtloses Kommunikationsnetz gebildet und z.B. in Mobilitätsanwendungen (z.B. vernetzten Sicherheitssystemen, vernetzten Fahrassistenzsystemen, etc.) eingesetzt werden kann.
Die Komplexität solcher funktionalen Systeme, vor allem im Automotive-Bereich und/oder Aeronautik-Bereich, wird damit schnell unüberschaubar hoch. Beispielsweise weist ein Fahrzeug üblicherweise dutzende Steuergeräte auf, auf denen zusammen Software mit mehreren 10 Millionen Zeilen Programmcode ausgeführt wird. Als Beispiel für Kommunikationsschnittstellen können alleine die verschiedenen drahtlosen Verbindungsprotokolle, wie z.B. Mobilfunkprotokolle (z.B. 5G, LTE, etc.), Bluetooth, WirelessLAN, RFID, Ve- hicle-to-X-Schnittstellen, etc., angeführt werden, die teilweise gleichzeitig im Einsatz sind. Aufgrund der Komplexität und der vielfältigen Kommunikationsschnittstellen entsteht bei solchen funktionalen Systemen eine große Angriffsfläche („Attack Surface“) für Cyber-Angriffe, wie z.B. so genanntes Denial-of-Service (kurz: DoS)-Attacken/Flooding. Weiterhin besteht auch die Gefahr, dass Angriffe nicht nur über die eigentlichen Kommunikationsschnittstellen, sondern beispielsweise auch über Sensoren (z.B. LIDAR, Radarsystem, etc.) erfolgen, wobei derartige Angriffe z.B. mittels so genannter Fake-Signale erfolgen können. Im Prinzip wird jedes Ereignis, welches von außen oder innen auf das funktionale System, mit dem Ziel das funktionale System in unzulässiger Weise zu beeinflussen und/oder Daten des funktionalen Systems in unzulässiger Weise an Dritte weiterzuleiten, als Cyber-Angriff betrachtet werden.
Aufgrund der physikalischen Fähigkeiten von Fahrzeugen (Masse und Geschwindigkeit, damit hohe kinetische Energie, direkte Interaktion mit potentiell vielen Menschen), der großen Anzahl (Fahrzeugflotten) und der Entwicklung hin zu autonomen Fahrzeugen, können solche Angriffe ein enormes Gefährdungspotential entwickeln. Dies trifft nicht nur auf die große Anzahl an Fahrzeuge, wie etwa Kraftfahrzeuge oder Lkws zu, sondern betrifft auch schienengebundene Fahrzeuge, Wasser- und vor allem Luftfahrzeuge. Daher ist es wichtig, in Mobilitätsanwendungen eingesetzte funktionale Systeme - vor allem im Automotive- und Aeronautik-Bereich - gegen Cyber-Angriffe und damit missbräuchliche Beeinflussung abzusichern, damit derartige Angriffe auf das jeweilige System möglichst keine Wirkung haben bzw. möglichst wirkungslos bleiben.
Um funktionale Systeme gegen Cyber-Angriffe abzusichern und resilient zu machen, gilt es, Schwachstellen bereits möglichst früh im Entwicklungsprozess zu erkennen und möglichst zu verhindern. In der Konzeptphase kann dies durch entsprechende Architekturmaßnahmen geschehen, wie sie zum Beispiel in der Veröffentlichung „Secure Vehicular Communication- Systems: Design and Architecture“ von Papadimitratos, P., Buttyan, L, Holczer, T., Schoch, E., Freudiger, J., Raya, M., Ma, Z., Kargl, F., Kung, A., & Hubaux, J.-P., 2008, IEEE Communications Magazine, 46(11), 100-109, beschrieben sind. Während der Umsetzung des Konzepts kann dies z.B. durch entsprechende Entwicklungsprozesse, wie etwa Best Practice, Source Code Review, etc. geschehen.
Nach einem vollständigen Zusammenbau und einer Integration der Komponenten zum funktionalen System ergibt sich in jedem Fall der Bedarf für eine Sicherheitsüberprüfung des funktionalen Systems, um möglichst alle relevanten Schwachstellen finden zu können - vor allem jene, die sich erst durch die Kombination der Komponenten - wie z.B. eingebettete und/oder Cyber-Physical Systeme - ergeben. Die Sicherheitsüberprüfung soll es Herstellern („Original Equipment Manufacturer“ - OEM), staatlichen Stellen (z.B. Zulassungsbehörden), und anderen Interessensvertretern (z.B. Verbraucherverbände, kommerzielle Flottenbetreiber, etc.) ermöglichen, das konkrete Risiko eines funktionalen Systems einer Mobilitätsanwendung, wie z.B. eines Fahrzeugs, etc. in Bezug auf Cyber-Angriffe bewerten zu können. Dies kann bei der Weiterentwicklung bzw. Verbesserung der Fahrzeuge bzw. des funktionalen Systems, für die Abnahme oder auch Zertifizierung und ähnliche Aufgaben zur Anwendung kommen. Die Sicherheitsüberprüfung soll insbesondere in den funktionalen Systemen (z.B. Fahrzeug, etc.) vorhandene, aber zunächst meist unbekannte Schwachstellen und potentielle Angriffspunkte für Cyber-Attacken aufdecken. Um Schwachstellen und potentielle Angriffspunkte (d.h. zunächst unerkannte Wege, auf welchen ein Cyber-Angriff auf das zu testende System durchgeführt werden können) aufzudecken, werden bei einer Sicherheitsüberprüfung eines funktionalen Systems verschiedene Angriffe (z.B. in Form von Testvektoren) auf das zu testende funktionale System definiert und im Rahmen der Sicherheitsüberprüfung dann als systemspezifische Testfälle auf das zu testende funktionale System angewendet.
Beispielsweise werden Sicherheitsüberprüfungen sowohl während der Entwicklung eines neuen Fahrzeugs beim OEM, bei der Markteinführung/Typisierung/Homologisierung, als auch später kontinuierlich während der gesamten Lebenszeit des Fahrzeugs bzw. des jeweiligen funktionalen Systems benötigt. Die Notwendigkeit wiederholter Sicherheitsüberprüfungen auf Systemtest-Ebene und damit eine laufende Überprüfung der Cybersicherheit ergibt sich aufgrund änderbarer Konfigurationen, laufender Updates von (Teilen der) Softwarekomponenten, geänderter Umgebungsbedingungen (beispielsweise Vehicle-to-lnfrastructure - V2I, Vehicle-to-Vehicle - V2V: Änderungen bei Interaktionspartnern), neu bekannt gewordener Testvektoren (auch aus eigener Sicherheitsforschung), etc. Die Sicherheitsüberprüfung kann dabei neben dem Hersteller, beispielsweise auch durch (Flotten)Betreiber, Zulassungsbehörden und/oder spezialisierte Drittfirmen durchgeführt werden.
Allerdings ist es aufgrund sehr restriktiver Schutz- und Geheimhaltungspolitik von Herstellern, vor allem im Automotive-Bereich, aber auch im Aeronautik-Bereich, und/oder aufgrund einer individualisierten und/oder herstellerspezifischen Ausgestaltung der funktionalen Systeme für Mobilitätsanwendungen die Regel, dass für funktionale Systeme keine durchgehend standardisierten Hardware- und Softwaresysteme eingesetzt werden. Es ist daher schwierig, für Sicherheitsüberprüfungen allgemein anwendbare Testfälle zu erstellen, die geeignet sind, Aussagen über die Sicherheit bzw. Cyber-Security von funktionalen Systemen mit gleicher Funktionalität z.B. unterschiedlicher Hersteller zu treffen. Selbst Updates von Komponenten eines funktionalen Systems oder ein Update eines funktionalen Systems können dazu führen, dass neue Testfälle für die Sicherheitsüberprüfung erstellt oder zumindest bestehende Testfälle angepasst werden müssen. D.h. die auf Sicherheit bzw. Cyber-Security zu überprüfenden funktionalen Systeme sind - selbst bei gleicher Funktionalität - vielfach heterogen und großteils herstellerspezifisch, sodass die Testfälle für Sicherheitsüberprüfung daher für jedes zu testende funktionale System systemspezifisch und individuell neu erstellt, zumindest adaptiert werden müssen. Gegebenenfalls können Schwachstellen sowie mögliche Angriffspunkte zwar gleichartig sein, allerdings können bereits bestehende Testfälle aufgrund der individuellen Ausgestaltung des jeweils zu testenden funktionalen Systems nicht direkt von einem bereits getesteten funktionalen System auf ein noch zu testendes funktionales System übertragen werden. D.h., die Testfälle für die Sicherheitsüberprüfung müssen an das jeweils zu testenden funktionalen System individuell und häufig auch manuell angepasst werden. Damit sind Sicherheitsüberprüfungen von funktionalen Systemen, wie z.B. Fahrzeugen, Teil- oder Subsystemen von Fahrzeugen, welche in Mobilitätsanwendungen verwendet werden, mit einem großen Zeit- und Ressourcenaufwand verbunden.
Aus der Schrift US 2005/0160322 A1 ist beispielsweise ein Verfahren sowie ein System bekannt, durch welches eine spezifisches Automatisierungstestskript zum Erkennen von Fehlern in einer Anwendung in eine abstrakte Testfalldarstellung umgewandelt wird. Die abstrakte Testfalldarstellung wird dann in einer Datenbank zur Wiederverwendung abgespeichert. Dabei werden für die abstrakte Testfalldarstellung ein oder mehrere Anwendungszustände, externe Interaktionssequenzen und Eingangsdaten gespeichert und die abstrakte Testdarstellung kann mit Informationen aus einem Anwendungs-Metadaten-Depot ergänzt werden, um diese zum Testen der Anwendung auch in anderen Testumgebungen oder auf einer anderen Testplattformen verwenden werden kann. Damit können zwar Testfälle zum Testen einer Anwendung abstrahiert, allerdings können die abstrakten Testfalldarstellung nur zum Testen derselben Anwendung in einer anderen Testumgebung bzw. auf einer anderen Testplattform genutzt werden.
Darstellung der Erfindung
Der Erfindung liegt daher die Aufgabe zugrunde, ein Verfahren anzugeben, durch welches Testfälle, welche bei Sicherheitsüberprüfungen zum Testen von funktionalen Systemen bereits verwendet wurden und/oder für derartige Sicherheitsüberprüfungen verwendbar sind, für Sicherheitsüberprüfungen weiterer, noch zu testenden funktionaler Systeme auf einfache, ressourcensparende und automatisierte Weise angepasst und wiederverwendet werden können.
Diese und weitere Aufgaben werden durch ein Verfahren gemäß dem unabhängigen Anspruch gelöst. Vorteilhafte Ausführungsformen der vorliegenden Erfindung sind in den abhängigen Ansprüchen beschrieben. Erfindungsgemäß erfolgt die Lösung der Aufgabe durch ein computerimplementiertes Verfahren zum Adaptieren von Testfällen für eine Sicherheitsüberprüfung eines funktionalen Systems, welche in einer Mobilitätsanwendung zur Anwendung kommt, mittels eines Testsystems. Dem Testsystem werden dabei die Testfälle, welcher bereits bei Sicherheitsüberprüfungen auf in Mobilitätsanwendungen eingesetzten funktionalen Systemen angewendet wurden und/oder für derartige Sicherheitsüberprüfungen anwendbar sind, zur Verfügung gestellt. Dabei werden folgende Schritte ausgeführt:
Unterteilen der Testfälle in Testmodule;
- Abstrahieren der Testmodule, wobei in den Testmodulen enthaltene, systemspezifische Informationen, Daten und Parameter der funktionalen Systeme, auf welche die jeweiligen Testfälle angewendet wurden, in einem jeweiligen Testmodul durch abstrakte Platzhaltervariablen ersetzt werden;
Erstellen von abstrakten Testszenarien für die Sicherheitsprüfung des zu testenden funktionalen Systems, wobei für ein Testszenario die abstrahierte Testmodule kombiniert werden;
- Ableiten von Testfällen für das zu testende funktionale System aus den abstrakten Testszenarien, wobei die jeweiligen abstrakten Platzhaltervariablen in den abstrahierten Testmodulen eines jeweiligen Testszenarios mit entsprechenden systemspezifischen Informationen, Daten und Parametern des zu testenden funktionalen Systems belegt werden; und
- Anwenden der aus den Testszenarien abgeleiteten Testfälle auf das zu testende funktionale System.
Der Hauptaspekt der vorgeschlagenen Lösung besteht darin, dass auf einfache und ressourcensparende Weise bereits bekannte oder bereits für Sicherheitsüberprüfungen von funktionalen Systemen in Mobilitätsanwendungen verwendete und/oder verwendbare Testfälle generalisiert und für Sicherheitsüberprüfungen von neu zu testenden funktionalen Systemen nutzbar gemacht werden können, wobei die Anpassung an das jeweils neu zu testende funktionale System automatisiert durchgeführt wird. Durch das erfindungsgemäße Verfahren werden bereits verwendete Testfälle automatisiert für Sicherheitsüberprüfungen neu zu testender funktionaler Systeme „recycelt“. Das bedeutet, es muss nicht für jedes neu zu testende funktionale System neue Testszenarien und konkrete Testfälle entwickelt werden, sondern es kann auf bereits bei Sicherheitsprüfungen auf anderen funktionalen Systemen angewendete und/oder dafür anwendbare Testfälle zurückgegriffen werden und diese dann automatisiert für die Sicherheitsprüfung des neu zu testenden funktionalen Systems automatisiert angepasst werden. Dadurch werden bei der Sicherheitsüberprüfung Ressourcen und Zeit gespart. Weiterhin ist es vorteilhaft, wenn nach Anwenden der aus den Testszenarien abgeleiteten Testfälle auf das zu testende funktionale System für jeden Testfall eine Rückmeldung erstellt wird. Die Rückmeldung wird dann an das Testsystem übermittelt und im Testsystem mit dem jeweiligen Testszenario verknüpft, aus welchem der jeweilige Testfall abgeleitet wurde. Dadurch können sehr leicht beispielsweise besonders gut funktionierende Testszenarien oder mangelhaft funktionierende Testszenarien identifiziert werden. Durch die Rückmeldung kann auch für jedes Testszenario hinterlegt werden, für welches funktionale System dieses bereits angewendet wurde und wie hilfreich es beispielsweise war, sicherheitsrelevante Schwachpunkte aufzudecken. Damit können bei nachfolgenden Sicherheitsüberprüfungen desselben oder eines ähnlichen funktionalen Systems rasch funktionierende Testszenarien gefunden bzw. mangelhaft funktionierende Testszenarien vermieden werden.
Es ist auch günstig, wenn beim Abstrahieren die Testmodule nach erforderlichen Parametern durchsucht werden, welche für eine Durchführung des jeweiligen Testmoduls vom zu testenden funktionalen System oder zumindest einem der vorhergehenden Testmodule zur Verfügung zu stellen sind. Diese erforderlichen Parameter können in einer Parameterliste im Testsystem hinterlegt werden, wobei die jeweilige Parameterliste mit dem aus dem jeweiligen Testmodul abstrahierten Testmodul verknüpft wird. Weiterhin können in den Parameterlisten auch Relationen zwischen einzelnen Parametern abgespeichert werden, um diese dann beim Erstellen von Testszenarien nutzen zu können. Anhand der Parameterlisten können außerdem beim Erstellen von Testszenarien rasch beispielsweise nicht sinnvolle, nicht funktionsfähige und/oder nicht zielführende Testszenarien identifiziert und eliminiert werden, wenn z.B. aufgrund einer Reihenfolge und/oder Kombination von Testmodulen, etc. erforderliche Parameter z.B. nicht verfügbar sind. Weiterhin können die Parameterlisten dazu genutzt werden, entsprechende, weitere Schritte in das Testszenario zu inkludieren, um diese Parameter - insbesondere bei der Anwendung des aus dem jeweiligen Testszenario abgeleiteten Testfall - zu ermitteln. Die Erstellung und Durchführung dieser Schritte, wie z.B. Ermitteln des Parameters oder Parameterwerts aus dem zu testenden funktionalen System, etc., kann beispielsweise automatisiert erfolgen.
Zweckmäßigerweise wird ein erstelltes, abstraktes Testszenario nach Platzhaltervariablen von erforderlichen Parametern durchsucht, welche für eine Durchführung des aus dem Testszenario abgeleiteten Testfalls vom zu testenden funktionalen System und/oder von zumindest einem der vorhergehenden Testmodule dem jeweiligen Testmodul bereitzustellen sind.
Idealerweise werden zum Auffinden der Platzhaltervariablen der erforderlichen Parameter im jeweiligen Testszenario die mit den jeweiligen abstrahierten Testmodulen des jeweiligen Testszenarios verknüpften Parameterlisten herangezogen. Auf diese Weise können die Platzhaltervariablen und gegebenenfalls auch Relationen zwischen diesen rasch und auf einfache Weise erkannt und genutzt werden.
Weiterhin ist es von Vorteil, wenn die abstrahierten Testmodule und/oder abstrakte Testszenarien und/oder Teile von abstrakten Testszenarien im Testsystem, insbesondere in einer Datenbank, hinterlegt werden. Damit können diese für nachfolgende Sicherheitsüberprüfungen von zu testenden funktionalen Systemen wiederverwendet werden. Einerseits können dann Testfälle rascher an neu zu testende funktionale Systeme angepasst werden, andererseits wird dadurch eine Testmodule- und -szenarien-Datenbank aufgebaut und damit das erfindungsgemäße Verfahren weiter beschleunigt. Dabei kann es auch günstig sein, wenn vor einem Hinterlegen des jeweiligen abstrahierten Testmoduls geprüft wird, ob das jeweilige abstrahierte Testmodul bereits im Testsystem, insbesondere in der Datenbank, hinterlegt ist. Damit wird sehr leicht verhindert, dass abstrahierte Testmodule mehrfach abgespeichert werden.
Idealerweise wird im Testsystem zu jedem abstrakten Testszenario eine Information hinterlegt, bei welchem funktionalen System das jeweilige Testszenario angewendet werden kann. Damit können für Sicherheitsüberprüfungen zu testender funktionaler Systeme rasch und mit geringem Aufwand passende Testszenarien gefunden werden.
Eine zweckmäßige Ausgestaltung des Verfahrens sieht vor, dass die systemspezifischen Informationen, Daten und Parameter des zu testenden funktionalen Systems zum Belegen der Platzhaltervariablen in den abstrahierten Testmodulen der jeweiligen Testszenarien vom Testsystem, insbesondere von der Datenbank, in welchem Erfahrungswerten aus vorhergehenden Sicherheitsüberprüfungen eines selben oder ähnlichen funktionalen Systems hinterlegt sind, und/oder von einem Systemhersteller zur Verfügung gestellt werden und/oder mittels maschinellem Lernens aus Erfahrungswerten vorhergehender Sicherheitsüberprüfungen ermittelt werden. Als systemspezifische Informationen, Daten und Parameter des zu testenden funktionalen Systems zum Belegen der Platzhaltervariablen in den abstrahierten Testmodulen der jeweiligen Testszenarien können allerdings auch Werte verwendet werden, welche aus einer Analyse des jeweils zu testenden funktionalen Systems ermittelt werden.
Die oben angeführte Aufgabe wird weiterhin auch durch ein Testsystem sowie ein Computerprodukt gelöst. Das Testsystem weist zumindest eine Computereinheit auf, welche zur Ausführung des erfindungsgemäßen Verfahrens eingerichtet ist. Zweckmäßigerweise kann das Testsystem auch eine Speichereinheit, wie z.B. eine Datenbank, umfassen oder mit einer Speichereinheit, wie z.B. einer Datenbank, verbunden sein. In diese Speichereinheit ist idealerweise dazu eingerichtet, die abstrahierten Testmodule, die abstrakten Testszenarien und/oder Teile von abstrakten Testszenarien sowie Erfahrungswerte aus vorhergehenden Sicherheitsüberprüfungen eines selben oder ähnlichen funktionalen Systems abzuspeichern. Das Testsystem kann auch mit einem System für maschinelles Lernen verbunden sein oder ein solche aufweisen, mit welchen die systemspezifischen Informationen, Daten und Parameter des zu testenden funktionalen Systems zum Belegen der Platzhaltervariablen in den abstrahierten Testmodulen der jeweiligen Testszenarien aus Erfahrungswerten, etc. ermittelt werden können.
Das Computerprogrammprodukt ist in vorteilhafter Weise in das Testsystem - beispielsweise in die zumindest eine Computereinheit ladbar, und umfasst Befehl, welche bei einer Ausführung des Computerprogrammprodukts im Testsystem das Computerprogrammprodukt dazu veranlassen, das erfindungsgemäße Verfahren auszuführen.
Kurzbeschreibung der Figuren
Die gegenständliche Erfindung wird nachfolgend unter Bezugnahme auf die Figuren 1 bis 2c näher erläutert, die beispielhaft, schematisch und nicht einschränkend vorteilhafte Ausgestaltungen der Erfindung zeigen. Dabei zeigt
Fig.1 einen Ablauf des computerimplementierten Verfahrens zum Adaptieren von Testfällen einer Sicherheitsprüfung eines zu testenden funktionalen Systems
Fig.2a einen Abstrahierungsschritt des erfindungsgemäßen Verfahrens anhand eines konkreten Ausführungsbeispiels
Fig.2b einen Syntheseschritt des erfindungsgemäßen Verfahrens anhand des konkreten Ausführungsbeispiels; und
Fig.2c einen Konkretisierungsschritt des erfindungsgemäßen Verfahrens anhand des konkreten Ausführungsbeispiels.
Ausführung der Erfindung
Figur 1 zeigt einen beispielhaften Ablauf eines computerimplementierten Verfahrens, mit welchem Testfälle TC1 , die bereits bei Sicherheitsüberprüfungen von funktionalen Systemen, durch welche beispielsweise Mobilitätsanwendungen (z.B. Kraftfahrzeuge, etc.) realisiert werden und/oder welche in Mobilitätsanwendungen (z.B. Autonomes Fahren, Vehicle-to-Ve- hicle-Kommunikation, Vehicle-to-X-Kommunikation, etc.) zum Einsatz kommen, angewendet wurden, für eine Sicherheitsprüfung eines zu testenden funktionalen Systems (z.B. Fahrzeug, Fahrzeugsystem, etc.) automatisiert adaptiert werden können. Als zu testendes funktionales System kann dabei ein neu entwickeltes funktionales System, eine Weiterentwicklung und/oder Verbesserung eines bestehenden funktionalen Systems oder auch ein funktionales System, bei welchen z.B. einzelne Komponenten (z.B. Hardwareeinheiten, Softwareeinheiten, etc.) getauscht oder upgedatet wurden, betrachtet werden.
Das Verfahren kann auf einem zugehörigen Testsystem ausgeführt werden, wobei das Testsystem zumindest eine Computereinheit aufweist. Das Testsystem stellt ein aktives System dar, das die Sicherheitsüberprüfung eines zu testenden Systems gemäß einem Computerprogrammprodukt durchführt, welches z.B. in einen internen Speicher des Testsystem geladen und z.B. mittels der zumindest einen Computereinheit bzw. eines Prozessors durchführt werden kann. Dazu umfasst das Computerprogrammprodukt Befehle, welche bei einer Ausführung durch das Testsystem das Computerprogrammprodukt zur Durchführung der Schritte des erfindungsgemäßen Verfahrens veranlassen.
Vom Testsystem werden entsprechende Testfälle TC1 , TC21 , ... , TC23 durchführt, um beispielsweise Schwachstellen des zu testenden funktionalen Systems aufzudecken. Dazu kann das Testsystem beispielsweise Schnittstellen und Umgebung (z.B. Prüfstand bzw. Testbed für Mobilitätsanwendungen, etc.) zur Verfügung stellen und gemeinsam mit den zu testenden funktionalen Systemen eine Testumgebung bilden, in welcher dann das erfindungsgemäße Verfahren durchgeführt wird. In der Testumgebung bzw. für das Testsystem sind Testfälle TC1 , welcher bereits bei Sicherheitsüberprüfungen anderer funktionaler Systeme angewendet wurden, verfügbar. D.h. das Testsystem kennt Testfälle TC1 , welche bereits durchgeführten Sicherheitsüberprüfungen von in Mobilitätsanwendungen verwendeten funktionalen System angewendet wurden und/oder für derartige Sicherheitsüberprüfungen verwendbar sind. Ein Testfall TC1 , TC21 , ... , TC23 ist dabei ein auf das jeweils zu testende, funktionale System angepasstes Testszenario TS1 , TS2, TS3 und kann beispielweise auf dem Testsystem und dem zu testenden funktionalen System im Rahmen der Sicherheitsüberprüfung ausgeführt werden. Als Testszenario TS1 , TS2, TS3 wird im Kontext dieser Offenbarung eine abstrakte Beschreibung eines Testfalls TC1 , TC21 , ... , TC23 gesehen, welche definiert, was mit welchen Mitteln getestet werden soll, und in welchen einzelne Testszenario-Phasen beschrieben sein können. Testszenarien TS1 , TS2, TS3 für funktionale Systeme können beispielsweise von Sicherheitsanalysen und/oder aus Sicherheitsanforderungen gewonnen werden.
Um einen konkreten Testfall TC1 , welcher bereits mittels des Testsystems bei einem funktionalen System angewendet wurden, für ein weiteres funktionales System, welches aktuell getestet werden soll, zu adaptieren, werden vom Testsystem die in der Folge beschriebenen und in Figur 1 beispielhaft dargestellten Schritte durchgeführt. Dazu werden in einem Modularisierungsschritt 101 bereits zum Testen von funktionalen Systemen verwendete Testfälle TC1 vom Testsystem analysiert und in einzelne Testmodule T11 , T12, T13, T14 unterteilt bzw. zerlegt. Ein Testmodul T11 , T12, T13, T14 kann beispielsweise ein Testskript sein, welches bei Ausführung einen gezielten Angriff auf das funktionale System darstellt. Gegebenenfalls kann das Testmodul T11 , T12, T13, T14 auch nur aus einem oder mehreren Befehlen bestehen.
In einem folgenden Abstrahierungsschritt 102 werden dann die aus den Testfällen TC1 ermittelten T estmodule T11 , T12, T13, T14 abstrahiert. Dabei werden in den T estmodulen T11 , T12, T13, T14 jeweils enthaltene, systemspezifische Informationen, Daten und Parameter des funktionalen Systems, auf welches der jeweilige Testfall TC1 angewendet wurde, durch abstrakte Platzhaltervariablen ersetzt. Damit werden im Abstrahierungsschritt 102 aus den konkreten Testmodulen T11 , T12, T13, T14, welche für einen jeweiligen Testfall TC1 systemspezifisch angepasst sind, abstrahierte Testmodule a1 , a2, a3, a4. Ein abstrahiertes Testmodul a1 , a2, a3, a4 stellt damit einen system-agnostischen Testbaustein dar, welcher eine einzelne Phase eines Testszenarios TS1 , TS2, TS3 beschreibt und agnostisch in Bezug auf ein spezielles funktionales System ist.
Die abstrahierten Testmodule a1 , a2, a3, a4 können beispielsweise im Testsystem, z.B. in einer zugehörigen Datenbank, hinterlegt werden. Die Datenbank kann dazu z.B. in einer internen Speichereinheit des Testsystems oder in einer Speichereinheit, welche mit dem Testsystem verbunden ist, angeordnet sein. Dabei kann vor einem Hinterlegen des jeweiligen abstrahierten Testmodule a1 , a2, a3, a4 geprüft werden, ob dieses Testmodul a1 , a2, a3, a4 bereits im Testsystem bzw. in der zugehörigen Datenbank gespeichert ist. Um die abstrahierten Testmodule a1 , a2, a3, a4 in einer adäquaten Form im Testsystem bzw. in der Datenbank speichern zu können, wird für die abstrahierten Testmodule a1 , a2, a3, a4 eine entsprechende Beschreibungssprache - wie z.B. eine so genannte Domain Specific Language oder kurz: DSL - verwendet. Eine Domain Specific Language ist eine formale Sprache, welche für Interaktionen zwischen z.B. Menschen und digital arbeitenden Einheiten (z.B. Computer) für ein bestimmtes Problemfeld - der so genannten Domäne bzw. Domain - entworfen und implementiert wird.
Weiterhin können im Abstrahierungsschritt 102 die Testmodule T11 , T12, T13, T14 noch vor dem Abstrahieren nach erforderlichen Parametern durchsucht werden. Erforderliche Parameter sind beispielsweise Parameter, welcher für eine sinnvolle Ausführung des jeweiligen Testmodules T11. T12, T13, T14 unbedingt erforderlich sind. Diese Parameter können beispielsweise vom zu testenden funktionalen System oder von einem der im jeweiligen Testfall TC1 vorhergehenden Testmodule T11. T12, T13, T14 zur Verfügung gestellt werden. Sie können aber auch aus einer externen Quelle, wie z.B. einer Datenbank, maschinenlesbaren Spezifikation, etc. stammt oder als manueller Input eingegeben werden. Solche Parameter wären z.B. Netzwerkadressen eines Testziels, eine Identifikation und/oder eine konkrete Mapping-Adresse, etc., welche beim Aussenden eines bestimmten Befehls über eine Komponente oder an eine Komponente des zu testenden funktionalen Systems für die Ausführung des Testmodul T11 , T12, T13, T14 vorhanden sein müssen, oder Konfigurationsdaten. Diese Parameter definieren beispielsweise Eigenschaften (in einem Schritt) des jeweiligen Testmoduls T11. T12, T13, T14 - wie z.B. zu welcher Netzwerkadresse oder zu welcher Portnummer eine bestimmte Nachricht gesendet werden soll oder wie lange diese Nachricht sein soll.
Erforderliche Parameter können in jedem Testmodul T11 , T12, T13, T14 vorkommen und für das jeweilige Testmodul T11 , T12, T13, T14 spezifisch sein. Weiterhin kann es aber auch erforderliche Parameter geben, welche zwangsläufig für alle Testmodule T11 , T12, T13, T14 z.B. eines Testfalls TC1 bzw. auch weitere Testfälle TC21 , TC22, TC23 für das jeweilige funktionale System gleich sind, wie z.B. Portnummer. Derartige Parameter können beispielsweise einmal für alle Testmodule T11. T12, T13, T14 eines Testfalls TC1 als „globale“ Parameter definiert werden.
Die ermittelten, erforderlichen Parameter des jeweiligen Testmoduls T11 , T12, T13, T14 können dann beispielsweise in einer Parameterliste zusammengefasst werden. Zusätzlich zu den ermittelten, erforderlichen Parametern des jeweiligen Testmoduls T11 , T12, T13, T14 können in der Parameterliste auch Relationen zwischen einzelnen, erforderlichen Parametern abgespeichert werden, wie z.B. das einzelne Parameter gleich Werte aufweisen müssen oder sich auch einer Kombination anderer Parameter ergeben. Die Parameterlisten können dann mit dem aus dem jeweiligen Testmodul T11. T12, T13, T14 generierten, abstrahierten Testmodul a1 , a2, a3, a4 verknüpft werden. Dazu kann z.B. die jeweilige Parameterliste im Testsystem bzw. in der zugehörigen Datenbank mit dem jeweiligen abstrahierten Testmodul a1 , a2, a3, a4 abgespeichert werden.
In der Folge werden dann in einem Syntheseschritt 103 durch Kombination der abstrahierten Testmodule a1 , a2, a3, a4 abstrakte Testszenarien TS1 , TS2, TS3 für die Sicherheitsüberprüfung des jeweils zu testenden funktionalen Systems erstellt. Dabei können abstrahierte Testmodule a1 , a2, a3, a4, a5, welche aus verschiedenen - beispielsweise bereits angewendeten und/oder anwendbaren - Testfällen TC1 generiert wurden, zu neuen Testszenarien TS1 , TS2, TS3 für die Sicherheitsüberprüfung des zu testenden funktionalen Systems kombiniert werden. Auch die erstellten Testszenarien TS1 , TS2, TS3 oder zumindest Teil der erstellten Testszenarien TS1 , TS2, TS3, TS4 können im Testsystem bzw. in der zugehörigen Datenbank beispielsweise für eine Wiederverwendung bei ähnlichen oder denselben Testanforderungen abgespeichert werden. Dazu kann auch für die Testszenarien TS1 , TS2, TS3 wie für die abstrahierten Testmodule a1 , a2, a3, a4, a5 die entsprechende Beschreibungssprache (z.B. Domain Specific Language) verwendet werden.
Weiterhin kann im Syntheseschritt 103 jedes neu erstellte Testszenario TS1 , TS2, TS3 nach den erforderlichen Parametern durchsucht werden, welche bei der Durchführung eines aus dem Testszenario TS1 , TS2, TS3 abgeleiteten Testfall TC21 , TC22, TC23 einem Testmodul T21 , T22, T23, T24, T25 vom zu testenden funktionalen System und/oder zumindest einem der vorhergehenden Testmodule T21 , T22, T23, T24, T25 zu ermitteln bzw. bereitzustellen sind. Auf diese Weise können beispielsweise bereits im Syntheseschritt 103 nicht zielführende, nicht funktionsfähige und/oder nicht sinnvolle Testszenarien TS1 , TS2, TS3 (z.B. aufgrund der Reihenfolge der abstrahierten Testmodule a1 , a2, a3, a4, a5) erkannt und eliminiert werden. Um diese erforderlichen Parameter im jeweiligen Testszenario TS1 , TS2, TS3 rascher erkennen und auffinden zu können, können beispielsweise die Parameterlisten herangezogen werden, welche im Abstrahierungsschritt 102 erstellt wurden. Es werden dazu die Parameterlisten herangezogen, welche mit den jeweils im Testszenario TS1 , TS2, TS3 verwendeten, abstrahierten Testmodulen a1 , a2, a3, a4, a5 verknüpft sind.
In einem folgenden Konkretisierungsschritt 104 werden dann aus den abstrakten Testszenarien TS1 , TS2, TS3 konkrete Testfälle TC21 , TC22, TC23 für die Sicherheitsüberprüfung des zu testenden funktionalen Systems abgeleitet. Dazu werden die jeweiligen abstrakten Platzhaltervariablen in den abstrahierten Testmodulen a1 , a2, a3, a4, a5 der Testszenarien TS1 , TS2, TS3 mit Information, Daten und Parametern des zu testenden funktionalen Systems belegt. Die systemspezifischen Informationen, Daten und Parameter des aktuell zu testenden Systems können dazu beispielsweise von einem Systemhersteller oder von einem Auftraggeber der durchzuführenden Sicherheitsüberprüfung zur Verfügung gestellt werden. Alternativ oder zusätzlich, können dazu auch Erfahrungswerte aus vorangegangenen Sicherheitsüberprüfungen desselben oder eines ähnlichen funktionalen Systems herangezogen werden. Diese Erfahrungswerte können z.B. ebenfalls im Testsystem bzw. in der zugehörigen Datenbank hinterlegt sein. Alternativ oder zusätzlich, können die systemspezifischen Informationen, Daten und Parameter zumindest teilweise anstatt aus der Datenbank auch von einem Machine-Learning-System stammen, welche die Informationen, Daten und Parameter auf Basis von Erfahrungswerten generiert. Weiterhin können systemspezifische Informationen, Daten und Parameter des zu testenden Systems, mit welchen die abstrakten Platzhaltervariablen in den abstrahierten Testmodulen a1 , a2, a3, a4, a5 der Testszenarien TS1 , TS2, TS3 belegt werden können, auch aus einer Analyse des aktuell zu testenden funktionalen Systems (z.B. Scans am System, Portscan, etc.) oder aus verfügbaren Herstellerdaten ermittelt werden. Nach dem Konkretisierungsschritt 104 werden die aus den abstrakten Testszenarien TS1 , TS2, TS3 abgeleiteten, konkreten Testfälle TC21 , TC22, TC23 in einem Anwendungsschritt 105 auf das zu testende funktionale System angewendet. Im Anwendungsschritt 105 kann beispielsweise während der laufenden Sicherheitsüberprüfung dokumentiert werden, welche konkreten Testfälle TC21 , TC22, TC23 beispielweise besonders gut zum Aufdecken von Schwachstellen geeignet sind, welche Testfälle TC21 , TC22, TC23 beispielweise das beste Ergebnis liefern, welche Testfälle TC21 , TC22, TC23 beispielweise keine besonders guten Ergebnisse liefern, welche Testfälle TC21 , TC22, TC23 beispielweise auf dem zu testenden funktionalen System nicht oder nur fehlerhaft funktionieren, etc.
Nach dem Anwendungsschritt 105 können dann während der Durchführung der Sicherheitsüberprüfung gesammelten Informationen zu den jeweiligen Testfällen TC21 , TC22, TC23 in einem Rückmeldungsschritt 106 an das Testsystem übermittelt werden. Dazu kann beispielsweise zu jedem Testfall TC21 , TC22, TC23 eine Rückmeldung erstellt werden, in welcher beispielsweise Informationen zur Durchführung des jeweiligen Testfalls TC21 , TC22, TC23 enthalten sind. Die Rückmeldungen können dann an das Testsystem übermittelt und dort z.B. mit den Testszenarien TS1 , TS2, TS3 verknüpft werden, aus welchen die Testfälle TC21 , TC22, TC23 abgeleitet wurden. Durch die Rückmeldungen können dann besonders gut funktionierende Testfälle TC21 , TC22, TC23 oder nicht oder nur fehlerhaft funktionierende Testfälle TC21 , TC22, TC23 identifiziert werden. Weiterhin kann zu jedem abstrakten Testszenario TS1 , TS2, TS3 eine Information hinterlegt werden, bei welchem funktionalen System das jeweilige Testszenario TS1 , TS2, TS3 bereits angewendet wurde. Damit können bei einer neuerlichen Sicherheitsüberprüfung desselben oder eines ähnlichen funktionalen Systems im Testsystem bereits erprobte und als erfolgreich bzw. gut funktionierende Testszenarien TS1 , TS2, TS3 im Syntheseschritt 103 identifiziert und im Konkretisierungsschritt 104 wieder zum Generieren von Testfällen TC21 , TC22, TC23 herangezogen werden. Weiterhin können auf diese Weise sehr einfach nicht funktionierende oder für bestimmte funktionale System nicht geeignete oder sinnlose Testszenarien TS1 , TS2, TS3 (z.B. aufgrund der Testmodul-Reihenfolge, aufgrund von erforderlichen Parametern auf einem funktionalen System nicht ausführbar, etc.) aus dem Testsystem bzw. der zugehörigen Datenbank ausgeschieden werden. Das Testsystem kann dadurch laufend verbessert werden und aus bereits durchgeführten Sicherheitsüberprüfungen - insbesondere Konkretisierungsschritten 104 - lernen.
In den Figuren 2a bis 2c werden der Abstrahierungsschritt 102, der Syntheseschritt 103 und der Konkretisierungsschritt 104 des Verfahrens anhand eines Ausführungsbeispiels detaillierter beschrieben. Im Ausführungsbeispiel soll z.B. eine Sicherheitsprüfung für ein konkretes Fahrzeug, für welches z.B. nach einer Neuentwicklung einer oder mehrerer Komponenten oder nach einem Update einer oder mehrerer Komponenten eine Sicherheitsüberprüfung durchgeführt werden. Dabei soll z.B. Schwachstellen bzw. Angriffspunkte für Cyber-Attacken auf dieses Fahrzeug ausfindig gemacht werden.
In Figur 2a ist beispielhaft der Abstrahierungsschritt 102 dargestellt. Dabei wird beispielsweise von einem beispielhaften konkreten Testfall TC1 ausgegangen, welcher bereits z.B. auf ein ähnliches funktionales System (z.B. Fahrzeug eines anderen Herstellers, etc.) oder auf dasselbe funktionale System (z.B. Fahrzeug vor einem Komponententausch oder -update) angewendet wurde. Der Testfall TC1 stellt beispielsweise einen konkreten Angriffsvektor auf ein funktionales System dar, welches bereits einer Sicherheitsüberprüfung unterzogen wurde. Mit diesem konkreten Angriffsvektor wurde beispielweise über einen Angriff auf eine externe Schnittstelle (z.B. Bluetooth, Funk, etc.) des funktionalen Systems versucht, bis zur Motorsteuerung des funktionalen Systems bzw. Fahrzeugs zu gelangen.
Der beispielhafte Testfall TC1 kann z.B. im Modularisierungsschritt 101 in vier Testmodule T11 , T12, T13, T14 unterteilt werden. Dabei entspricht z. B. jedes T estmodul T11. T12, T13, T14 einem konkreten Angriff auf eine Komponente oder auf ein Subsystem des getesteten funktionalen Systems bzw. Fahrzeugs. Das erste Testmodul T11 kann beispielsweise einen Angriff auf eine externe Schnittstelle des Fahrzeugs darstellen, mit welchen z.B. existierende externe Schnittstellen (z.B. drahtlose Kommunikationsschnittstelle, Sensoren, etc.) ausfindig gemacht werden. Durch ein zweites Testmodul T12 wird versucht, nach einem erfolgreichen Angriff mittels des ersten Testmoduls T11 z.B. auf das Infotainment-System des Fahrzeugs zu gelangen. Bei erfolgreicher Durchführung des zweiten Testmoduls T12 versucht ein drittes Testmodul T13 beispielsweise das fahrzeuginterne Netzwerk des Fahrzeugs anzugreifen bzw. zu nutzen. Ist das dritte Testmodul T13 damit erfolgreich, so wird beispielsweise in einem vierten Testmodul T14 versucht, die Motorsteuerung des Fahrzeugs zu übernehmen.
Im Abstrahierungsschritt 102 werden nun die konkreten Testmodule T11 , T12, T13, T14, in welche der konkrete Testfall TC1 unterteilt wurde, abstrahiert. D.h., es werden im Testsystem aus den Testmodulen T11 , T12, T13, T14 alle enthaltenen, systemspezifischen Informationen, Daten und Parameter des mit dem Testfall TC1 getesteten Fahrzeugs entfernt und durch abstrakte Platzhaltervariablen ersetzt. Aus den Testmodulen T11 , T12, T13, T14 werden damit abstrahierte Testmodule a1 , a2, a3, a4, welche die jeweiligen Angriffe abstrakt beschreiben. So kann beispielsweise ein aus dem ersten Testmodul T11 abgeleitetes abstrahiertes Testmodul a1 die Beschreibung enthalten, nach einer drahtlosen Schnittstelle eines (beliebigen) funktionalen Systems zu suchen und mit dieser eine Verbindung herzustellen. Ein aus dem zweiten Testmodul T12 abgeleitetes, zweites abstrahiertes Testmodul a2 kann z.B. die Beschreibung enthalten, nach erfolgreicher Verbindung mit der drahtlosen Schnittstelle eine Verbindung mit einer Komponente oder einem Subsystem des funktionalen Systems herzustellen, welches bzw. welche über die gefundene Schnittstelle erreichbar ist. In einem von dritten Testmodul T13 abgeleiteten, dritten abstrahierten Testmodul a3 wird z.B. eine Nutzung eines internen Netzwerks des funktionalen Systems abstrakt beschrieben. Von einem vierten abstrahierten Testmodul a4 kann z.B. eine Übernahme einer Steuerung des funktionalen Systems abstrakt beschrieben werden. Die abstrahierten Testmodule a1 , a2, a3, a4 können dann z.B. im Testsystem bzw. in der zugehörigen Datenbank hinterlegt werden, sofern diese abstrahierten Testmodule a1 , a2, a3, a4 nicht bereits im Testsystem bzw. in der zugehörigen Datenbank gespeichert sind.
Weiterhin können die Testmodule T11 , T12, T13, T14 noch vor dem Abstrahieren auf erforderliche Parameter durchsucht werden und entsprechend testmodulspezifische Parameterlisten erstellt werden. Die jeweilige testmodulspezifische Parameterliste kann mit dem jeweiligen abstrahierten Testmodul a1 , a2, a3, a4 verknüpft und mit diesem im Testsystem bzw. in der zugehörigen Datenbank abgelegt werden.
In Figur 2b ist der Syntheseschritt 103 des Verfahrens anhand des Ausführungsbeispiels wie z.B. einer Sicherheitsüberprüfung eines aktuell zu testenden Fahrzeugs dargestellt. Dabei werden die abstrahierten Testmodule a1 , a2, a3, a4, a5 zu abstrakten Testszenarien TS1 , TS2, TS3 kombiniert, wobei jedes Testszenario TS1 , TS2, TS3 eine abstrakte Beschreibung eines möglichen Angriffsvektors darstellt. Zum Erstellen der Testszenarien TS1 , TS2, TS3 können beispielsweise die im Abstrahierungsschritt 102 aus den konkreten Testfall TC1 abgeleiteten, abstrahierten Testmodule a1 , a2, a3, a4 sowie weitere, abstrahierte Testmodule a5, welche aus Testfällen TC1 weiterer, bereits durchgeführter Sicherheitsüberprüfungen abstrahiert wurden, verwendet werden. Weiterhin können dafür auch abstrahierte Testmodule a5 herangezogen werden, welche bereits im Testsystem bzw. in der zugehörigen Datenbank gespeichert sind.
Im in Figur 2b dargestellten Syntheseschritt 103 werden beispielsweise die im Abstrahierungsschritt 102, welcher in Figur 2a dargestellt ist, generierten, abstrahierten Testmodule a1 , a2, a3, a4 zu einem ersten Testszenario TS1 kombiniert. In einem weiteren, zweiten Testszenario TS2 werden z.B. das zweite, das dritte und das vierte abstrahierte Testmodul a2, a3, a4 aus dem konkreten Testfall TC1 mit einem fünften abstrahierten Testmodul a5 (z.B. einer abstrakten Beschreibung, dass eine Verbindung zu einer systeminternen Komponente (z.B. Gateway) aufgebaut und/oder diese verwendet werden soll) kombiniert, wobei das fünfte abstrahierte Testmodul a5 beispielsweise zwischen dem dritten und vierten abstrahierten Testmodule a3, a4 eingefügt wird. In einem weiteren, dritten Testszenario TS3 werden ebenfalls das zweite, das dritte und das vierte abstrahierte Testmodul a2, a3, a4 mit dem fünften abstrahierten Testmodul a5 kombiniert, wobei beim dritten Testszenario das fünfte abstrahierte Testmodul a5 beispielsweise zwischen dem zweiten und dem dritten abstrahierten Testmodul a2, a3 angeordnet wird.
Im Syntheseschritt 103 können damit durch eine beliebige Kombination der abstrahierten Testmodule a1 , a2, a3, a4, a5 vom Testsystem abstrakte Testszenarien TS1 , TS2, TS3 erstellt werden. Um beispielsweise nicht zielführende oder sinnlose Kombinationen von abstrahierten Testmodulen a1 , a2, a3, a4, a5 auszuschließen - wie z.B. einer Kombination, bei welcher z.B. das vierte abstrahierte Testmodule a4 (z.B. eine Übernahme der Steuerung des funktionalen Systems) vor dem ersten Testmodul a1 (z.B. Suche nach externen Schnittstellen des funktionalen Systems als Angriffspunkt) angeordnet wird, können die erstellten, abstrakten Testszenarien z.B. nach erforderlichen Parametern durchsucht werden bzw. die bei den jeweiligen abstrahierten Testmodulen a1 , a2, a3, a4, a5 gespeicherten Parameterlisten ausgewertet werden. Weiterhin können zum Erstellen von abstrakten Testszenarien TS1 , TS2, TS3 im Testsystem bzw. in der zugehörigen Datenbank verfügbare Vorschläge für Kombinationen von abstrahierten Testmodulen a1 , a2, a3, a4, a5 zum Erstellen von Testszenarien TS1 , TS2, TS3 genutzt werden. Weiterhin können die erstellten, abstrakten Testszenarien TS1 , TS2, TS3 oder zumindest Teil davon im Syntheseschritt 103 im Testsystem bzw. in der zugehörigen Datenbank - beispielsweise als Vorschläge zum Erstellen von Testszenarien TS1 , TS2, TS3 in späteren Syntheseschritten 103 - hinterlegt werden.
In Figur 2c ist der Konkretisierungsschritt 104 des Verfahrens anhand des konkreten Ausführungsbeispiels - z.B. der Sicherheitsüberprüfung eines aktuell zu testenden Fahrzeugs - dargestellt. Im Konkretisierungsschritt 104 werden aus den im Syntheseschritt 103 erstellten abstrakten Testszenarien TS1 , TS2, TS3 konkrete Testfälle TC21 , TC22, TC23 für das aktuell zu testende funktionale System - z.B. ein Fahrzeug mit zumindest einer neu entwickelten oder upgedateten Komponente - abgeleitet. Dabei werden die abstrakten Platzhaltervariablen in den abstrahierten Testmodulen a1 , a2, a3, a4, a5 der jeweiligen Testszenarien TS1 , TS2, TS3 mit systemspezifischen Informationen, Daten und Parametern des aktuell zu testenden funktionalen Systems bzw. Fahrzeugs belegt. Aus dem ersten Testszenario TS1 wird damit ein konkreter, erster Testfall TC21 für die Sicherheitsüberprüfung des aktuell zu testenden Fahrzeugs. Weiterhin werden damit das zweite Testszenario TS2 bzw. das dritte Testszenario TS3 zu einem konkreten, zweiten Testfall TC22 bzw. zu einem konkreten, dritten Testfall TC23. Die systemspezifischen Informationen, Daten und Parameter können vom Auftraggeber der Sicherheitsüberprüfung oder aus Herstellerdaten des Fahrzeugs stammen. Es können beispielsweise auch Erfahrungswerte aus früheren Sicherheitsüberprüfungen des Fahrzeugs oder ähnlicher Fahrzeuge genutzt werden oder Daten aus Analysen, etc. des aktuell zu testenden Fahrzeugs herangezogen werden. Die im Konkretisierungsschritt 104 abgeleiteten Testfälle TC21 , TC22, TC23 werden dann im Anwendungsschritt 105 für die Sicherheitsüberprüfung des aktuell zu testenden funktionalen Systems bzw. Fahrzeugs verwenden. Die Erkenntnisse und Erfahrungen aus der Anwendung der Testfälle TC21, TC22, TC23 können dann im Rückmeldungsschritt 106 in Form von Rückmeldungen zu den Testfällen TC21, TC22, TC23 an das Testsystem übermittelt werden. Dort können diese mit den entsprechenden Testszenarien TS1 , TS2, TS3 verknüpft und hinterlegt werden, um die Rückmeldungen wieder bei nachfolgenden Sicherheitsüberprüfungen von funktionalen Systemen nutzen zu können.

Claims

Patentansprüche
1 . Computerimplementiertes Verfahren zum Adaptieren von Testfällen (TC1) für eine Sicherheitsüberprüfung eines zu testenden funktionalen Systems (105) einer Mobilitätsanwendung mittels eines Testsystems, wobei dem Testsystem Testfälle (TC1) zur Verfügung gestellt werden, welche bei Sicherheitsüberprüfungen von in Mobilitätsanwendungen verwendeten funktionalen Systemen angewendet wurden und/oder für derartige Sicherheitsüberprüfungen anwendbar sind, und wobei folgende Schritte ausgeführt werden:
- Unterteilen der Testfälle (TC1) in Testmodule (T 11 , ... , T14) (101);
- Abstrahieren der Testmodule (T 11 , ... , T14), wobei in den Testmodulen (T 11 , ... , T14) enthaltene, systemspezifische Informationen, Daten und Parameter der funktionalen Systeme, auf welche die jeweiligen Testfälle (TC1) angewendet wurden, in einem jeweiligen Testmodul (T 11 , ... , T14) durch abstrakte Platzhaltervariablen ersetzt werden (102);
- Erstellen von abstrakten Testszenarien (TS1 , TS2, TS3) für die Sicherheitsprüfung des zu testenden funktionalen Systems, wobei für ein Testszenario (TS1 , TS2, TS3) die abstrahierte Testmodule (a1 , ... , a5) kombiniert werden (103);
- Ableiten von Testfällen (TC21 , TC22, TC23) für das zu testende funktionale System aus den abstrakten Testszenarien (TS1 , TS2, TS3), wobei die jeweiligen abstrakten Platzhaltervariablen in den abstrahierten Testmodulen (a1 , ... , a5) eines jeweiligen Testszenarios (TS1 , TS2, TS3) mit entsprechenden systemspezifischen Informationen, Daten und Parametern des zu testenden funktionalen Systems belegt werden (104); und
- Anwenden der aus den Testszenarien (TS1 , TS2, TS3) abgeleiteten Testfälle (TC21 , TC22, TC23) auf das zu testende funktionale System (105).
2. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass nach Anwenden der aus den Testszenarien (TS1 , TS2, TS3) abgeleiteten Testfälle (TC21 , TC22, TC23) auf das zu testende funktionale System für jeden Testfall (TC21 , TC22, TC23) eine Rückmeldung erstellt wird, dass die Rückmeldung an das Testsystem übermittelt wird und im Testsystem mit dem jeweiligen Testszenario (TS1 , TS2, TS3) verknüpft wird (106), aus welchem der jeweilige Testfall (TC21 , TC22, TC23) abgeleitet wurde.
3. Verfahren nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass beim Abstrahieren die Testmodule (T 11 , ... , T14) nach erforderlichen Parametern durchsucht werden (102), welche für eine Durchführung des jeweiligen Testmoduls (T 11 , ... , T14) vom zu testenden funktionalen System (105) oder zumindest einem der vorhergehenden Testmodule (T11 , ... , T14) zur Verfügung zu stellen sind, und dass die erforderlichen Parameter in einer Parameterliste im Testsystem hinterlegt werden, wobei die jeweilige Parameterliste mit dem aus dem jeweiligen Testmodul (T 11 , T14) abstrahierten Testmodul (a1 , a5) verknüpft wird.
4. Verfahren nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass ein erstelltes, abstraktes Testszenario (TS1 , TS2, TS3) nach Platzhaltervariablen von erforderlichen Parametern durchsucht wird (103), welche für eine Durchführung des aus dem Testszenario (TS1 , TS2, TS3) abgeleiteten Testfalls (TC21 , TC22, TC23) vom zu testenden funktionalen System und/oder von zumindest einem der vorhergehenden Testmodule (T21 , ... , T25) dem jeweiligen Testmodul (T21 , ... , T25) bereitzustellen sind.
5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass zum Auffinden der Platzhaltervariablen der erforderlichen Parameter im jeweiligen Testszenario (TS1 , TS2, TS3) die mit den jeweiligen abstrahierten Testmodulen (a1 , ... , a5) des jeweiligen Testszenarios (TS1 , TS2, TS3) verknüpften Parameterlisten herangezogen werden (103).
6. Verfahren nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die abstrahierten Testmodule (a1 , ... , a5) und/oder abstrakte Testszenarien (TS1 , TS2, TS3) und/oder Teile von abstrakten Testszenarien (TS1 , TS2, TS3) im Testsystem, insbesondere in einer Datenbank, hinterlegt werden (102, 103).
7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass vor einem Hinterlegen des jeweiligen abstrahierten Testmoduls (a1 , ... , a5) geprüft wird (102), ob das jeweilige abstrahierte Testmodul (a1 , ... , a5) bereits im Testsystem, insbesondere in der Datenbank, hinterlegt ist.
8. Verfahren nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass zu jedem abstrakten Testszenario (TS1 , TS2, TS3) im Testsystem eine Information hinterlegt wird (103), bei welchen funktionalen Systemen das jeweilige Testszenario (TS1 , TS2, TS3) angewendet worden ist.
9. Verfahren nach einem der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass die systemspezifischen Informationen, Daten und Parameter des zu testenden funktionalen Systems zum Belegen der Platzhaltervariablen in den abstrahierten Testmodulen (a1 , ... , a5) der jeweiligen Testszenarien (TS1 , TS2, TS3) vom Testsystem, insbesondere von der Datenbank, in welchem Erfahrungswerten aus vorhergehenden Sicherheitsüberprüfungen eines selben oder ähnlichen funktionalen Systems hinterlegt sind, und/oder von einem Systemhersteller zur Verfügung gestellt werden und/oder mittels maschinellem Lernens aus Erfahrungswerten vorhergehender Sicherheitsüberprüfungen ermittelt werden (104).
10. Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass als systemspezifischen Informationen, Daten und Parameter des zu testenden funktionalen Systems zum Belegen der Platzhaltervariablen in den abstrahierten Testmodulen (a1 , a5) der jeweiligen Testszenarien (TS1 , TS2, TS3) Werte verwendet werden (104), welche aus einer Analyse des zu testenden funktionalen Systems ermittelt werden.
11 . Testsystem mit zumindest einer Computereinheit, welche dazu eingerichtet ist, das Verfahren nach einem der Ansprüche 1 bis 10 auszuführen.
12. Testsystem nach Anspruch 11 , wobei das Testsystem weiterhin zumindest eine Speichereinheit umfasst und/oder mit einer Speichereinheit verbunden ist, welche zum Ab- speichern abstrahierter Testmodule (a1 , ... , a4, a5), abstrakter Testszenarien (TS1 , TS2, TS3) und/oder von Teilen von abstrakten Testszenarien (TS1 , TS2, TS3) sowie von Erfahrungswerten aus vorhergehenden Sicherheitsüberprüfungen eines selben oder ähnlichen funktionalen Systems eingerichtet ist.
13. Computerprogrammprodukt, wobei das Computerprogrammprodukt in das Testsystem nach einem der Ansprüche 11 bis 12 geladen werden kann, und wobei das Computerprogrammprodukt Befehle umfasst, welche bei einer Ausführung durch das Testsystem das Computerprogrammprodukt veranlassen, das Verfahren nach einem der Ansprüche 1 bis 10 auszuführen.
EP23837126.4A 2022-12-23 2023-12-22 Verfahren zum adaptieren von testfällen für eine sicherheitsüberprüfung Pending EP4639351A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
ATA51002/2022A AT526816B1 (de) 2022-12-23 2022-12-23 Verfahren zum Adaptieren von Testfällen für eine Sicherheitsüberprüfung
PCT/AT2023/060451 WO2024130290A1 (de) 2022-12-23 2023-12-22 Verfahren zum adaptieren von testfällen für eine sicherheitsüberprüfung

Publications (1)

Publication Number Publication Date
EP4639351A1 true EP4639351A1 (de) 2025-10-29

Family

ID=89508949

Family Applications (1)

Application Number Title Priority Date Filing Date
EP23837126.4A Pending EP4639351A1 (de) 2022-12-23 2023-12-22 Verfahren zum adaptieren von testfällen für eine sicherheitsüberprüfung

Country Status (5)

Country Link
EP (1) EP4639351A1 (de)
JP (1) JP2026501289A (de)
CN (1) CN120615189A (de)
AT (1) AT526816B1 (de)
WO (1) WO2024130290A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AT527555A1 (de) * 2023-08-22 2025-03-15 Avl List Gmbh Verfahren zum Generieren von Testszenarien für eine Sicherheitsüberprüfung

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7581212B2 (en) * 2004-01-13 2009-08-25 Symphony Services Corp. Method and system for conversion of automation test scripts into abstract test case representation with persistence
EP1622022A1 (de) * 2004-07-22 2006-02-01 Siemens Aktiengesellschaft Automatische Erzeugung von Testfällen
JP5513263B2 (ja) * 2010-06-03 2014-06-04 キヤノン株式会社 情報処理装置及びその制御方法、プログラム
AT522625B1 (de) * 2019-06-14 2022-05-15 Avl List Gmbh Verfahren zur Sicherheitsüberprüfung einer Technikeinheit

Also Published As

Publication number Publication date
AT526816A1 (de) 2024-07-15
AT526816B1 (de) 2026-04-15
JP2026501289A (ja) 2026-01-14
WO2024130290A1 (de) 2024-06-27
CN120615189A (zh) 2025-09-09

Similar Documents

Publication Publication Date Title
AT522625B1 (de) Verfahren zur Sicherheitsüberprüfung einer Technikeinheit
DE102016220670A1 (de) Verfahren und System zum Testen von Software für autonome Fahrzeuge
DE102017100380A1 (de) Diagnostiktest-durchführungssteuersystem und verfahren
EP3667568B1 (de) Konfiguration eines steuerungssystems für ein zumindest teilautonomes kraftfahrzeug
DE102020214922A1 (de) Verfahren zum Testen einer Anwendung für Fahrzeuge
EP4315069A1 (de) Verfahren zum bewerten einer software für ein steuergerät eines fahrzeugs
EP4639351A1 (de) Verfahren zum adaptieren von testfällen für eine sicherheitsüberprüfung
DE102021111724A1 (de) Verfahren und Computerprogramm zum Evaluieren eines Softwarestands eines Fahrerassistenzsystems
WO2023131603A1 (de) Verfahren zur optimierung der umfeldwahrnehmung für ein fahrunterstützungssystem mittels zusätzlicher referenzsensorik
DE102020005474A1 (de) Verfahren zur Datenverarbeitung von Daten in einem Fahrzeug mittels eines Kontext-Management-Systems, sowie Datenverarbeitungssystem
DE10228610A1 (de) Verfahren zum Überprüfen eines auf einer elektronischen Recheneinheit ablaufenden Steuerprogramms
DE102022123358A1 (de) Frequenzbasierte merkmalsbeschränkung für ein neuronales netz
DE102021125498A1 (de) Systemvalidierung mit verbesserter Handhabung von Protokollierungsdaten
WO2025039020A1 (de) Verfahren zum generieren von testszenarien für eine sicherheitsüberprüfung
DE102021202133A1 (de) Verfahren, Vorrichtung und Konfigurationsumgebung zum Erzeugen von Konfigurationsdaten für ein Steuergerät
DE102021200257A1 (de) Verfahren zur Validierung von Softwarefunktionen in einem Fahrerassistenzsystem für Kraftfahrzeuge
DE102023208799B3 (de) Verfahren zum Betreiben einer Kommunikationsschnittstelle für eine Fahrzeugentwicklungs-Prüfplatzanlage zum Datenaustausch in Bezug auf ein für ein zu entwickelndes Fahrzeug zu testendes Software-Produkt, Kommunikationsschnittstelle und Fahrzeugentwicklungs-Prüfplatzanlage
DE102012222908A1 (de) Verfahren und Vorrichtung zur Steuerung von Anwendungsfunktionen in einem Steuergerät insbesondere einer Brennkraftmaschine eines Kraftfahrzeuges
DE102024108126A1 (de) Verfahren zur Nutzung von unbekannten neuen Systemdiensten in einer Fahrzeuganwendung
DE102017109607A1 (de) Verfahren zur Aufzeichnung und Analyse von Datenkommunikation
DE102022113690A1 (de) Verfahren, System und Computerprogrammprodukt zum autonomen intuitiven Kalibrieren eines technischen Bauteils, insbesondere eines Fahrzeugantriebsstrangs für ein Kraftfahrzeug
DE102024119874A1 (de) Computerimplementiertes Verfahren zum Zuweisen einer Mehrzahl an Simulationsaufgaben zu einer Mehrzahl an Simulationsagenten und entsprechende Vorrichtung zur Datenverarbeitung
DE102022122657A1 (de) Validierungssystem für neuronale Netze
DE102022206923A1 (de) Verfahren und Steuergerät zum Bestimmen eines Sicherheitsintegritätsniveaus einer sicherheitsbezogenen Fahrzeugfunktion eines Kraftfahrzeugs
DE102022207613A1 (de) Computer-implementiertes Verfahren zur Verifikation zumindest einer Softwarekomponente einer automatisierten Fahrfunktion

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20250625

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)