Procedure for verifying the information security and / or operational safety of a technical system

Abstract

According to various embodiments, a method for verifying the information security and / or operational safety of a technical system is described, comprising receiving architectural information about the technical system, wherein the architectural information includes information about a hierarchy of the functional parts of the technical system, extracting keywords that identify functional parts of the technical system and, for each keyword, hierarchy information that specifies a position of the functional part identified by the keyword in a hierarchy of the functional parts of the technical system, generating, for each keyword, an embedding of the keyword and associated hierarchy information, feeding the generated embeddings into a machine learning model that is trained toGenerating Threat Analysis and Risk Assessment (TARA) information for the technical system based on the embeddings, and verifying the information security and / or operational safety of the technical system using the TARA information generated by the machine learning model.

Description

[0001] The present disclosure relates to devices and methods for verifying the information security and / or operational safety of technical systems.

[0002] Technical systems deployed in environments with high information and operational security requirements, such as electronic control units (ECUs) in vehicles, must be verified for information security and / or safety, or, in other words, a Threat and Risk Assessment (TARA) must be performed. A technical system can then be reconfigured (e.g., with information security and operational security measures such as error correction, firewalls, or redundancy) if the verification shows that information security and / or safety are insufficient for the specific application.Since such an assessment (or verification) requires a high degree of manual work and expert knowledge, efficient and reliable automated approaches are desirable.

[0003] According to various embodiments, a method for verifying the information security and / or operational safety of a technical system is provided, comprising receiving architectural information about the technical system, wherein the architectural information includes information about a hierarchy of the functional parts of the technical system, extracting keywords that identify functional parts of the technical system and, for each keyword, hierarchy information that specifies a position of the functional part identified by the keyword in a hierarchy of the functional parts of the technical system, generating, for each keyword, an embedding of the keyword and the associated hierarchy information, feeding the generated embeddings into a machine learning model that is trained therefor,to generate threat and risk assessment (TARA) information for the technical system based on the embeddings, and to verify the information and / or operational security of the technical system using the threat and risk assessment information generated by the machine learning model.

[0004] The above method provides an efficient and reliable automated approach for verifying the information and / or operational security of a technical system, i.e., for conducting a Threat and Risk Assessment (TARA). In particular, the use of a machine learning model trained on historical data allows for the integration of expert knowledge, and the automatic extraction of keywords that identify functional parts enables the automation of a large part of the manual work. Furthermore, the inclusion of hierarchical information, similar to natural language processing, which considers the position of words, allows for the consideration of relationships between components and their subcomponents and thus the correct identification of threats (e.g.,by using a machine learning model using an attention mechanism acting on the embeddings, e.g., a transformation model).

[0005] Various examples are given below.

[0006] Example 1 is a method for verifying the information security and / or operational safety of a technical system as described above.

[0007] Example 2 is the method of Example 1, wherein the threat and risk assessment information includes identifications of one or more information and / or operational security threats and, for each information and / or operational security threat, a specification of a criticality of the information and / or operational security threat.

[0008] The model can thus be trained to predict a threat's criticality level, which can then be taken into account when configuring the technical system (e.g., threats with a high criticality level can be prioritized when security mechanisms are included). Since expert knowledge can be incorporated via the machine learning model (via the training data, especially when using a base model (e.g., pre-trained on a large amount of training data and then fine-tuned) as the machine learning model, overall information and / or operational security can be efficiently increased.

[0009] Example 3 is the method according to example 1 or 2, wherein verifying the information and / or operational security of the technical system comprises entering the Threat Analysis and Risk Assessment (TARA) information generated by the machine learning model into TARA software by means of an API call (Application Programming Interface) of the TARA software.

[0010] Alternatively, a file (e.g., XML or JSON) containing the Threat Analysis and Risk Assessment (TARA) information (according to the TARA software's input data structure) is generated, which is then input into or read from the TARA software. An API call can have the advantage of continuing to be used in the same way even if the TARA software is updated in such a way that the format of its input data structure changes.

[0011] Example 4 is the method of any one of Examples 1 to 3, comprising training the machine learning level through supervised learning using training data items that include training input examples and target Threat Analysis and Risk Assessment (TARA) information.

[0012] Example 5 is an (automated) method for configuring (or controlling) a technical system (with regard to information and / or operational security, i.e. in view of a threat and risk assessment), comprising verifying the information and / or operational security of the technical system according to any one of Examples 1 to 4 and configuring the technical system taking into account a result of the verification.

[0013] For example, information and / or operational security measures may be included if the verification shows insufficient results for certain functional parts or components of the technical system.

[0014] Example 6 is the method of Example 5, comprising configuring the technical system with information and / or operational security measures to mitigate information and / or operational security weaknesses indicated by the Threat Analysis and Risk Assessment (TARA) information.

[0015] Example 7 is a data processing system configured to perform a method according to any one of Examples 1 to 6.

[0016] Example 8 is a computer program comprising instructions that, when executed by a computer, cause the computer to perform a method according to any one of Examples 1 to 6.

[0017] Example 9 is a computer-readable medium comprising instructions that, when executed by a computer, cause the computer to perform a method according to any one of Examples 1 to 6.

[0018] In the drawings, similar reference characters generally refer to the same parts throughout the several views. The drawings are not necessarily to scale; rather, emphasis is generally placed upon illustrating the principles of the invention. In the following description, various aspects are described with reference to the following drawings, in which: Fig. Figure 1 shows a vehicle as an example of a technical system for which a Threat and Risk Assessment (TARA) is to be carried out. Fig. Figure 2 illustrates the processing flow when processing architectural information provided by a software (and / or hardware) modeling tool (i.e., architectural (modeling) software). Fig. Figure 3 shows a flowchart illustrating an (automated) method for verifying the information security and / or operational safety of a technical system.

[0019] The following detailed description refers to the accompanying drawings, which, for illustrative purposes, show specific details and aspects of this disclosure in which the invention may be practiced. Other aspects may be utilized, and structural, logical, and electrical changes may be made without departing from the scope of the invention. The various aspects of this disclosure are not necessarily mutually exclusive, as some aspects of this disclosure may be combined with one or more other aspects of this disclosure to form new aspects.

[0020] Various examples are described in more detail below.

[0021] Fig. 1 shows a vehicle 101.

[0022] The vehicle 101, for example a car or a truck, is provided with several components, such as one or more vehicle control devices (also referred to as an electronic control unit, e.g., a control unit, e.g., an electronic control unit (ECU)) 102, a multimedia system 103, a radar system 104, a braking system 105, etc.

[0023] Typically, a Threat Analysis and Risk Assessment (TARA) must be conducted for these components. For example, certain components must be certified before a vehicle containing them can be operated.

[0024] Components are typically implemented by software executing on a hardware device. The software is transferred, for example, from a computer system 107 to the vehicle 101, e.g., via a network 106 (or using a data storage medium such as a memory card). This can also occur during operation (or at least when the vehicle 101 is located at the user's location), for example, when the control software 107 is updated to new versions over time.

[0025] According to various embodiments, a threat and risk assessment (TARA) is performed using a computer system such as computer system 107. For this purpose, computer system 107 receives information about the respective component, in particular one or more files describing its (software and / or hardware) architecture. Depending on the TARA, computer system 107 can then permit use of the components or change their configuration (deactivate functions (in particular interfaces or communication protocols), integrate additional security measures by updating the component software (e.g., integrate a firewall), etc.).

[0026] It should be noted that this is not typically the case, as in Fig. 1, but rather for an entire vehicle fleet, including the respective components. Furthermore, this can also be done before the components are installed in the vehicle 101.

[0027] Thus, according to various embodiments, to configure a technical system (such as vehicle 101) with regard to threats to information and / or operational security (i.e., in particular for TARA implementation), computer system 107 extracts architecture information (for the technical system as a whole or for components thereof) using (architecture) files such as XML (Extensible Markup Language) files as the source for the information. Furthermore, the system may use a library of known attacks (e.g., attack trees) for TARA implementation.

[0028] A vehicle can thus be made more information-secure and operationally safer for its occupants, as automated extraction of architectural features reduces the possibility of manual human error during TARA execution. Furthermore, by standardizing the threat and risk assessment (TARA) to a certain extent, common (human) TARA errors can be eliminated. Furthermore, time to market for new automotive products can be accelerated, as automation for TARA reduces design verification time. The approaches described here can be applied to any product in the automotive sector, including ECUs, braking systems, etc., but also to other technical systems such as manufacturing machines, any type of robot, etc.

[0029] The architectural information can be provided by a software (and / or hardware) modeling tool (such as Enterprise Architect). This information is processed as described below to provide inputs for a given TARA software.

[0030] Fig. 2 illustrates the processing flow when processing architectural information provided by a software (and / or hardware) modeling tool 201 (i.e., architectural (modeling) software).

[0031] In the example of Fig. 1, the architectural information is exported from the modeling tool in the form (i.e., by creation) of an XML (Extensible Markup Language) or a UML (Unified Modeling Language) file 202. This exported file 202 containing architectural information is then read by an (intelligent) parser 203, which is implemented, for example, by a parsing script written, for example, in Python (which, however, may be one of several functional blocks, which, as described below, may in particular include a machine learning model; this may therefore also be considered a function or component for parsing and mapping (from architectural information to TARA information)). The parser 203 extracts the relevant information from the exported file 202 containing architectural information and uses this information to create a TARA data structure (e.g.,a form) 204 directly with TARA information that can be read by the TARA software 205. The parser 202 is not only able to extract the architectural information (e.g., of a specific component) but also recognizes the context of the architectural information.

[0032] Thus, according to one embodiment, these are the automated steps for extracting and filling in the TARA information: • Export file 202 from the architectural software 201 in a machine-readable format • Export information from file 202 • Intelligently select relevant TARA information from the extracted information • Fill in (or pre-fill) TARA fields of the TARA data structure 204 for the TARA software 205

[0033] The generation of TARA information based on the exported file 102 (or files, which are also referred to as architecture file(s) below), e.g. the software flow of the parser 201, is described in more detail below. 1. Find diagrams: The parser 201 first searches for diagrams in file 202. Note that this means searching for (markup language) code (e.g., XML or UML expressions) in file 202, since the file contains the diagrams not as images depicting diagrams, but rather as markup language structures depicting diagrams from the original architectural information 201. This is done, for example, by the "Find Images" function, with an XML file as input and a list of diagrams as output, and has the following sequence: 1.1 Enter XMI file (e.g. XML file or UML file) 1.2 Find package with string “Technical View” in XMI file name 1.3 Execute the "Find Leaves" function with the package (as a tree element) as input and a leaf list containing XMI IDs (of leaves), and output a list of leaf identifiers (IDs) of the tree element. The "Find Leaves" function - searches recursively for (child) packages in the input package - if a child package is found, calls itself recursively for the child package - stops if no child package is found - adds an XMI ID of the leaf package to the leaf list 1.4 Iterate through diagrams in the XMI file (e.g., UML diagrams); if a diagram package is in the browse list, add the diagram name to the list of diagrams 1.5 Output diagram list to extract elements

[0034] Thus, parser 203 first searches for the term "technical view." Technical view refers to the various views available in the architecture hierarchy. From there, parser 203 recursively searches for packages and their corresponding subpackages. This allows parser 203 to iterate through all diagrams and store the identifier (ID) of each diagram as well as its position. Knowing the position preserves the hierarchy of the system. This allows data flow analysis to be performed in a later functional block of the parser.

[0035] For example, within the "System Functions" category and the ETS (Electronic Traction Unit) subcategory, parser 203 finds ECU diagrams for the time synchronization of the ECU CAN slave and the ECU Ethernet slave, e.g., both for ETS as master and ETS as slave (arranged, for example, in different main categories such as "Vehicle" and "Vehicle Domain"). The parser finds these four diagrams in an expanded view of the architecture information and extracts them.

[0036] 2. Map diagrams and extract keywords: In this function block, the parser extracts 202 keywords from each of the extracted diagrams and maps them to their corresponding hierarchy level. There are two types of keywords: "asset" and "descriptive." An asset keyword refers to commonly known interface components such as USB, CAN bus, SPI (Serial Peripheral Interface), etc., which are referenced by a known library. The actual "asset" can refer to the configuration (e.g., a configuration file) of a component, whereby this configuration can be accessed via the interface. Thus, the presence of the interface provides a possible gateway for accessing the asset. The exact definition of an asset can differ between different business domains.Descriptive keywords include terms such as "ECU," "messages," "master," and "slave." These keywords help establish the system context, making it clear, for example, that a specific diagram is subordinate to a larger system such as a radar (or an ETS ECU in the example above). For keyword extraction and diagram mapping, the parser 203 first iterates through each diagram (the location is provided by the diagram search function described in 1 above) and searches for ID tags of various elements (e.g., connectors, ports, blocks, objects, and others) associated with it. The next step is to locate each element and extract the keywords associated with that element. These keywords are then separated into asset keywords or descriptor keywords using a predefined library and stored in a dictionary.Finally, the hierarchy is included to ensure the correct parent-child relationship between all keywords.

[0037] For example, keyword extraction is performed by a function called “Map Images”, which includes the following (sub)functions: • Find chart elements function ◯ Input: Name of the required diagram in string format ◯ Output: List of IDs of elements in the required diagram ◯ Iterate through all extracted diagrams to find one whose name matches ◯ Iterate through elements of the found diagram and store the element ID in an element list • Extract keywords function ◯ Input: Name of the required diagram in string format ◯ Output: Dictionary of each element ID and the keyword it corresponds to ◯ Search, for each element in the element list, by IDs of packages, classes, elements and attributes ◯ If an ID matches, update the dictionary with the ID as key and the corresponding keyword as value • Identify Assets feature ◯ Input: Dictionary of extracted keywords ◯ Output: updated dictionary in which dictionary is marked as descriptor or asset ◯ Compare each extracted keyword of the input dictionary with a predefined asset list ▪ If there is a match, the keyword is marked as an asset ▪ otherwise the keyword is marked as a descriptor • Assign hierarchy function ◯ Input: Dictionary of extracted keywords ◯ Output: updated dictionary, separated by descriptors and assets found in the diagram ◯ Iterate through keywords in the dictionary ◯ Within the relevant XMI tag, if another dictionary keyword is found, the correct hierarchy between the two descriptors or assets is assigned.

[0038] 3. Assign keywords to threats: Two approaches for (intelligent) threat mapping are described below. • NLP (Natural Language Processing) approach: First, the keywords containing assets or descriptors are input into a stop-word filter for preprocessing. This filter removes irrelevant words such as prepositions and adjectives, which are referenced from a known library. After filtering, the keywords are tokenized to assign values ​​for processing by an NLP model (which can be considered part of the parser 203). The hierarchy information associated with each keyword is then stored as positioning values. Thus, unlike traditional NLP, which encodes the position of words (or tokens) within a sentence, the hierarchy information provides the "position" information to be encoded (since there are only keywords, but no sentences to extract positions from).Next, each token and its associated position information are combined into an embedding, vectorizing both token and position information and finding similarities between pairs of keywords (taking position into account). In a training phase of the model, previous TARA files (i.e., predetermined TARA target information (i.e., ground truth) for training input examples) are used for training. The TARA files provide keywords, which are then matched with the embeddings to find the relationships between TARA fields (the TARA data structure 204) and embeddings. For example, the model is trained to predict threats and / or opportunities to mitigate the threats. It can also consider the criticality of the respective component (or function).For example, a USB port in a radar system poses a greater (information) security risk than a third-party infotainment system that is not connected to the vehicle's controls. Thus, the model can be trained to predict one of different threat levels (i.e., criticality levels) for a given component and corresponding mitigation measures (e.g., in the form of an entry for a field in the TARA data structure). For inference (using the trained model), the keywords are fed into the preprocessing step, and the embeddings are input into the trained model. The output is then information for the entries for the corresponding (pre-)populated TARA fields in the TARA data structure 204 of the TARA software 205. • Perform one-shot inference using a fine-tuned base model (which can be considered part of the parser 203): This approach assumes that a base model is available. Similar to the NLP approach, the keywords (with their positional information) are first fed into the stop-word filter. This ensures that no unusable words are fed into the base model, reducing computational overhead. The filtered keywords are then fed into a prompt generator, which is used to query the base model. The output of the model is the predicted information for the fields of the TARA data structure.

[0039] 4. Translation into the TARA software input format: Once the architecture information has been mapped to the TARA information (i.e., threat intelligence), the next step is to translate the information into a format readable by the TARA software 205 (i.e., a form suitable for the TARA data structure 204). The TARA data structure 204 can be in the form of JSON (JavaScript Object Notation) or XML files, which are machine-readable. A disadvantage of using this format is that the data structure may change if an update to the TARA software occurs that impacts format versions; this may cause the translation (from architecture information to TARA information, i.e., input information to the TARA software) to fail.Therefore, API calls 206 can alternatively be used to input the TARA information into the TARA software 205, if supported by the TARA software 205. This approach ensures that the translation is up-to-date. (These two approaches are referred to as the two parallel paths in . Fig. 2 shown.)

[0040] The technical system (e.g., vehicle components) is then configured according to the results provided by the TARA software; for example, information and / or operational security mechanisms (such as encryption, redundancy, etc.) are integrated or certain functions are restricted (e.g., access rights of insecure components to other components are restricted, control functionalities are blocked, etc.).

[0041] Thus, according to some embodiments: • Architectural information is automatically parsed from a machine-readable format such as XML and UML (via parser). • Hierarchy information in the architecture information is retained during extraction. • Keywords are mapped using NLP to improve correctness. • Expert knowledge can be integrated by using a (pre-trained) base model. • The approach is not limited to any industry or domain and can be applied to both software and hardware, provided an architecture is defined.

[0042] Thus, the parser (e.g., a parsing script) 203 (which also includes a mapper, i.e., a mapping functionality as described above) captures the architectural information in the XML / UML file 202 and extracts the information (regarding threats and criticality) that is input to the TARA software 205 by populating fields of a data structure or file 204 that the TARA software 205 uses or receives as input and that contains the Threat Analysis and Risk Assessment (TARA) information. Alternatively, the threat and risk assessment information is input to the TARA software 205 through one or more API calls.

[0043] In summary, according to various embodiments, a method as in Fig. 3 is provided as an illustration.

[0044] Fig. 3 shows a flowchart 300 illustrating an (automated) method for verifying the information security (security) and / or the operational safety (safety) of a technical system.

[0045] In 301, architectural information about the technical system (i.e., including a description of functional parts of the technical system (such as interface functions such as Ethernet slave, CAN slave, or larger functional parts such as an ECU of a vehicle), etc.) is received, which includes diagrams (with text, e.g., in XML representation)), wherein the architectural information includes information about a hierarchy of the functional parts of the technical system (e.g., in the form of a file such as an XML or UML file) (i.e., which functional parts implement parts (subfunctions) of other functional parts; such as, for example, that an ECU has a CAN slave or that Ethernet time synchronization is a subfunction of the ECU time synchronization).

[0046] In 302, keywords that identify functional parts of the technical system and, for each keyword, hierarchy information that specifies a position of the functional part identified by the keyword in a hierarchy of the functional parts of the technical system are extracted.

[0047] In 303, for each keyword, an embedding of the keyword and the associated hierarchy information is generated (i.e., encoding the keyword and the associated hierarchy information (e.g., concatenated together) for an input of an encoder, e.g., a machine learning-based encoder model, such as the encoder of a transformer network (such as a large language model), using the hierarchy information for an embedding instead of position information).

[0048] In 304, the generated embeddings are fed into a machine learning model that is trained to use the embeddings to generate threat and risk assessment information for the technical system.

[0049] In 305, the information and / or operational security of the technical system is verified (i.e., tested) using the threat and risk assessment information generated by the machine learning model.

[0050] The approach of Fig. 3 can be used to configure various types of technical systems (in terms of information and / or operational security), such as a computer-controlled machine, a robot, a vehicle, a household appliance, a power tool, a manufacturing machine, a personal assistant or an access control system, and individual components thereof (e.g., in the case of a vehicle, an ECU, a radar device, a multimedia device or system, etc.).

[0051] The procedure of Fig.3 may be performed by one or more data processing devices (e.g., computers or microcontrollers) having one or more data processing units. The term "data processing unit" may be understood as any type of entity that enables the processing of data or signals. For example, the data or signals may be handled according to at least one (i.e., one or more than one) specific function performed by the data processing unit.A data processing unit may include or be formed from an analog circuit, a digital circuit, a logic circuit, a microprocessor, a microcontroller, a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), a field-programmable gate array (FPGA), or a combination thereof. Any other means for implementing the respective functions described in more detail herein may also be understood to include a data processing unit or logic circuit. One or more of the method steps described in detail herein may be performed (e.g., implemented) by a data processing unit through one or more specific functions performed by the data processing unit.

[0052] Accordingly, according to one embodiment, the method is computer-implemented.

Claims

[1] Method for verifying the information security and / or operational safety of a technical system (101), comprising: Receiving (301) architectural information (201, 202) about the technical system (101), wherein the architectural information (201, 202) includes information about a hierarchy of the functional parts of the technical system (101); Extracting (302) keywords that identify functional parts of the technical system (101) and, for each keyword, hierarchy information that specifies a position of the functional part identified by the keyword in a hierarchy of the functional parts of the technical system (101); Generating (303), for each keyword, an embedding of the keyword and the associated hierarchy information; Feeding (304) the generated embeddings into a machine learning model that is trained to generate Threat Analysis and Risk Assessment (TARA) (204) information for the technical system (101) based on the embeddings; and Verifying (305) the information and / or operational security of the technical system (101) using the Threat Analysis and Risk Assessment (TARA) information generated by the machine learning model (204). [2] The method of claim 1, wherein the threat and risk assessment information (204) includes identifications of one or more information and / or operational security threats and, for each information and / or operational security threat, a specification of a criticality of the information and / or operational security threat. [3] Method according to claim 1 or 2, wherein verifying the information and / or operational security of the technical system (101) comprises entering the information generated by the machine learning model for threat and risk assessment (Threat Analysis and Risk Assessment, TARA) (204) into a TARA software (205) by means of an application programming interface call of the TARA software (205). [4] The method of any one of claims 1 to 3, comprising training the machine learning level by supervised learning using training data items including training input examples and Threat Analysis and Risk Assessment (TARA) target information (204). [5] Method for configuring a technical system (101), comprising verifying the information and / or operational security of the technical system (101) according to one of claims 1 to 4 and configuring the technical system (101) taking into account a result of the verification. [6] The method of claim 5, comprising configuring the technical system (101) with information and / or operational security measures to mitigate information and / or operational security weaknesses indicated by the Threat Analysis and Risk Assessment (TARA) information (204). [7] A data processing system designed to carry out a method according to any one of claims 1 to 6. [8] A computer program comprising instructions which, when executed by a computer, cause the computer to perform a method according to any one of claims 1 to 6. [9] A computer-readable medium comprising instructions which, when executed by a computer, cause the computer to perform a method according to any one of claims 1 to 6.

Images