System and method for verifying components of an industrial control system

Abstract

A system for verifying components of an industrial control system (100), wherein the system (600) includes: a first module (601) configured to establish a trust relationship with a component (200) of the industrial control system (100) and request a component certificate (201) from the component (200), wherein the component certificate (201) contains relevant information about the component (200); and a second module (602) configured to check the component certificate (201) based on relevant data (901) stored in a trusted database (900) and through interaction with the component (200), and generate a notification based on the result of the check.

Description

Technical Field

[0001] The present invention relates to a method and system for verifying components of an industrial control system (particularly a production or process facility) for industrial control systems, preferably automated facilities.

[0002] Furthermore, the present invention relates to a list of devices and computer programs implemented by computers. Background Technology

[0003] Systems and methods for connecting components to industrial control systems or to networks of industrial facilities are known in the prior art. One example of such a system is the so-called safety anomaly detection tool, or simply anomaly detection tool. Today, safety anomaly detection tools are increasingly used not only for their primary purpose (anomaly detection) but also to automatically detect facility components in a list / inventory along with their critical data. For example, the leading industrial safety standard IEC 62443 Part 3-3 explicitly requires the existence of such an inventory to achieve safety levels 2 to 4 (see, for example, requirement 11.10SR 7.8 - Control system component inventory: The control system shall provide the capability to report the current list of installed components and their associated properties). The automatic detection of system components by safety anomaly detection tools offers advantages over manual detection because it initiates connection to the network immediately after the component is detected, requiring no intervention from facility personnel. This significantly reduces the time required and the likelihood of errors. This type of facility component detection particularly supports equipment replacement during operation, representing a very important scenario in industrial environments.

[0004] Furthermore, modern security anomaly detection tools can extract manufacturer-specific device data from detected network packets sent by components to the operator station (OS) or engineer station (ES), and verify it according to specific criteria. For example, they can check the association between a specific device and a specific manufacturer based on the MAC address preset by the manufacturer. However, attackers can also read MAC addresses from packets sent by the original device, insert that MAC address into a self-made device, and thus impersonate the original device. Typically, MAC addresses are associated with the manufacturer in principle, but a drawback is that they can be changed / configured.

[0005] As mentioned above, because security anomaly detection tools store detected facility components along with their data (including their MAC addresses) in a list / manifestation (which is often unprotected), attackers can also obtain the MAC address, for example, from the original device's documentation and abuse it to impersonate the original device.

[0006] The aforementioned drawback stems from the unreliability and lack of trustworthiness of the equipment data detected by anomaly detection tools. This results in the inability to definitively verify and trust the originality of facility components detected by these tools—that is, their identity relative to the manufacturer and their affiliation. Consequently, counterfeit and / or manipulated equipment can be stored as original equipment in a facility's inventory and then participate in communications, despite being untrustworthy and potentially (due to negligence or intent) compromising the facility's system integrity and availability. In the context of industrial security, this necessitates finding solutions to reduce (or ideally eliminate) the risks of such manipulation, thereby enabling a higher level of protection. Summary of the Invention

[0007] Therefore, the object of the present invention is to improve the system and method mentioned at the beginning in terms of safety.

[0008] This objective is achieved using a system of the type mentioned in the invention, comprising a first module and a second module. The first module is configured to establish a trust relationship with a component of the industrial control system and request a component certificate from the component, wherein the component certificate contains relevant information about the component. The second module is configured to check the component certificate based on relevant data stored in a trusted database (wherein the relevant data includes one or more chains of trust and / or one or more certificate revocation lists) and through interaction with the component (e.g., regarding the authenticity of the component). During the check, one or more chains of trust and / or one or more certificate revocation lists are verified, and an appropriate response is made to the check result. Here, when the system responds to the check result, it may introduce a corresponding notification, such as generating an alarm and / or introducing a corresponding action (e.g., interrupting communication with the component).

[0009] The system is therefore able to check the status of the component's certificate itself (expired / not expired, revoked / not revoked, etc.) and / or the status of the certificate of the higher-level certificate authority (which issues the certificate to the component) and / or the status of the certificate of the so-called root certificate authority (which forms the trust anchor).

[0010] When connecting components, for example, a system designed as an anomaly detection tool can establish a preferred confidential connection with the component and require the component to send its component certificate to the system, so that the component certificate can be interactively (interacting with the component) checked by the system. A second module undertakes the task of interactively checking the component certificate. This means that the second module interacts with the component while simultaneously checking or verifying the component certificate. Interaction with the component occurs during the certificate check to exchange relevant information about the check.

[0011] In the context of this disclosure, "trustworthy" means "free from the influence / interference of third parties," and in particular "cannot be manipulated" and "its authenticity is protected" or "it is genuine." A database considered trustworthy in the sense of this disclosure is characterized, in particular, that (part-specific) entries (e.g., part names and serial numbers, and especially the status of inspections) cannot be manipulated without being detected.

[0012] The trust relationship between a system (e.g., an anomaly detection tool) and a component can be established using a whitelist securely stored in the component (e.g., during debugging) or by performing certificate-based authentication. If a whitelist is used, the component can check if the anomaly detection tool is, for example, on that list. In the case of certificate-based authentication, the component can use certain standards and data securely stored within the component to check whether it trusts the anomaly detection tool's certificate, which the tool uses to authenticate itself, and thus trusts the anomaly detection tool itself. Compared to using whitelist filtering, certificate-based authentication achieves a higher level of security or trust.

[0013] The component certificate contains relevant information about the component. This information may include, but is not limited to, manufacturer-specific information such as manufacturer X, equipment factory Y, etc., and / or OEM (Original Equipment Manufacturer)-specific information and / or integrator-specific information and / or customer facility or customer sub-facility-specific information.

[0014] When interacting with a component, the system checks the component's certificate based on relevant data stored in a trusted database. For example, the relevant data (used for checking) could be stored in the component manufacturer's certificate repository. Here, the system can, for example, access the trusted database or certificate repository to perform a data comparison between the certificate provided by the component and the manufacturer's certificate in the certificate repository. Based on the results of the check, the system can generate appropriate notifications and / or trigger the exclusion of the component from communication within the industrial control system's network.

[0015] For example, a component certificate can be issued, but is not limited to, by an OEM (e.g., by an engineering office), an integrator, or in another area of ​​a customer facility (e.g., at the cargo entrance), and thus represents the component's connection at that OEM / integrator / customer facility.

[0016] In this context, data related to verification includes, but is not limited to, manufacturer-specific data such as manufacturer “X”, equipment factory “Y”, certificate “ABC”, etc., and / or OEM-specific data and / or integrator-specific data and / or customer facility-specific data or customer sub-facility-specific data.

[0017] Therefore, all design options described here are valid if the component certificate links the component to an OEM / integrator or the corresponding customer facility. Use the relevant data (for verification) depending on the issuer of the component certificate.

[0018] Therefore, the system is capable of performing credentialed and unmanipulated verification of identity and origin (the affiliation of facility components with their manufacturers). Verification can be performed ad hocly (if necessary, such as immediately after a component is connected to the network) or proactively and cyclically.

[0019] In addition, the system responds appropriately to the inspection results, for example by generating corresponding notifications and / or taking appropriate actions, such as interrupting communication with the component.

[0020] The verification of components and their detection in industrial control systems can be performed fully automatically using this system.

[0021] In conjunction with this invention, the term "module" is understood to mean a hardware module, a software module, or a combination of hardware and software modules.

[0022] In particular, the first and second modules of the system can be designed as software modules, for example, as corresponding parts of program code.

[0023] In particular, a module can include physical and / or logical sub-modules.

[0024] In one implementation, it is effective if a component is configured to use its private key for its component certificate during an inspection without revealing that private key. Here, with the use of appropriate encryption methods, the component can prove to the system that it knows the private key (or the public key contained in the component certificate) of the component certificate without disclosing it.

[0025] In one implementation, if the system has a secure (e.g., physical or logical) memory or storage location that is preferably protected against unauthorized modification or manipulation, and is configured to retrieve relevant data from a trusted database (e.g., from the manufacturer's certificate repository) via a secure connection at regular time intervals or in an event-controlled manner (e.g., triggered by changes to a certificate or associated chain of trust or the manufacturer's revocation list) and store or mount it on secure memory.

[0026] Generally, in the context of this disclosure, the term "security" refers to security in the sense of IT security or "network security" (particularly concerning the three most important protection objectives "integrity," "confidentiality," and "availability," as well as the protection objective "authenticity," which plays a significant role in this disclosure). Secure components or secure storage specifically mean preventing unauthorized access through appropriate protection measures / mechanisms.

[0027] For example, the second module can include a more secure (e.g., physical or logical) memory or storage location, such as one capable of storing certificates and associated trust chains and / or certificate revocation lists. Thus, the second module can, for example, have a physical portion designed as physically secure memory and a software module configured to perform the functions described above, acquiring data related to the inspection and storing or installing it in secure memory or storage location.

[0028] In one implementation, it can be proposed that the check can have three possible results: "check successful", "check failed", or "check is not feasible".

[0029] For example, if a missing certificate is found in the component manufacturer's certificate when comparing certificates, the inspection result "Inspection is not feasible" can be displayed.

[0030] In one implementation, the component certificate can be a manufacturer's device certificate. Unlike a MAC address, a component certificate, especially a manufacturer's device certificate, cannot be successfully manipulated. This means, for example, that a copied or manipulated device without the private key of the manufacturer's device certificate (compared to the original device) cannot successfully prove that the manufacturer's device certificate belongs to it.

[0031] In one implementation, it is advantageous if the relevant data includes a trust chain and / or a certificate revocation list or multiple certificate revocation lists, wherein the trust chain should be part of the component certificate. Here, for example, if the trust chain is stored in the system's secure (physical or logical) memory or storage location, checks can be performed quickly by comparing the component certificate with the trust chain stored by the manufacturer. When a manufacturer's certificate revocation list exists, the system can also check the revocation status to see if the component certificate just checked has been revoked.

[0032] "Trust chain" or "certificate chain" are terms known to those skilled in the art. In a configuration file titled "Internet X.509 Public Key Infrastructure Certificates and Certificate Revocation Lists (CRLs) Profile," developed within the scope of RFC 5280, "trust chain" or "certificate chain" is defined as a "certificate path." It states there: "Generally, multiple certificate chains may be required, which include a certificate of the public key owner (the ultimate entity) signed by a CA, and certificates of zero or more additional CAs signed by other CAs. Such a chain, referred to as a certificate path, is necessary because users of the public key only initialize with a limited number of trusted CA public keys."

[0033] The term “chain of trust” is understood within the scope of this disclosure as a list of certificates (a chain of certificates), which preferably begins with the certificate of an end entity, followed by one or more CA certificates, the last of which is, for example, a self-signed certificate.

[0034] When inspecting a chain of trust, it is preferable to inspect or verify each certificate in the chain or list.

[0035] A certificate chain can have the following properties. First, the issuer of each certificate (except the last one) corresponds to the subject of the next certificate in the list. Second, each certificate (except the last one) should be signed using the key of the next certificate in the chain, so the signature can be verified using the public key from subsequent certificates. Third, the last certificate in the list is the trust anchor: a trusted certificate because it is provided through a trusted mechanism. The trust anchor is a CA certificate (or more specifically, the CA's public check key), which the relying party uses as the starting point for path verification.

[0036] In one embodiment, it can be advantageously proposed that the system includes a third module configured to record relevant information from the component certificate in a computer-implemented device list and to mark relevant information based on the inspection results, such as by highlighting or equipping it with appropriate status and / or flags.

[0037] The third module preferably includes a list of computer-implemented devices.

[0038] In one implementation, the system can be effective if it includes a fourth module configured to create and / or configure and / or use different inspection profiles to inspect different components, wherein the inspection profile characterizes the inspection process.

[0039] Within the scope of this disclosure, the term "inspection profile" is understood to mean, for example, different methods / procedures used to perform inspections of a component, depending on the component. Therefore, an inspection profile is a component-specific inspection method used to perform component inspections interactively.

[0040] For example, the inspection of components using TLS (Transport Layer Security) can be technically designed as a TLS handshake. Here, the component uses its component certificate as the TLS server certificate, specifically demonstrating to the inspection authority / system (e.g., to anomaly detection tools) that it knows the private key of the public key listed on the certificate without revealing it. Another example is a component that is only "capable" of OPC UA (Open Platform Communications Unified Architecture), which can demonstrate to its counterparty that it knows the private key using procedures according to Part 21 of the OPC UA. A challenge-and-response approach can also be used for this, and it can be considered, for example, within the scope of other configuration files.

[0041] In one embodiment, the system may include a fifth module configured to create and / or configure and / or use different action profiles based on the results of an inspection, and / or prevent further communication between components and other facility components.

[0042] According to the present invention, the object of the present invention is also achieved by the computer-implemented method of the type described above, namely,

[0043] - Establish trust relationships with components of the industrial control system and request component certificates from the components, where the component certificates contain relevant information about the components.

[0044] - Component certificates are checked during interactions with components and based on relevant data stored in a trusted database, wherein the relevant data includes one or more chains of trust and / or one or more certificate revocation lists, wherein, during the check, one or more chains of trust and / or one or more certificate revocation lists are verified, and

[0045] - Respond appropriately to the results of the inspection.

[0046] Here, in response to the results of the inspection, it is possible to introduce appropriate notifications, such as alarms, and / or appropriate actions, such as interrupting communication with the component.

[0047] In one implementation, it can be advantageously proposed that a component uses its private key for a component certificate during inspection without revealing that private key.

[0048] In one implementation, relevant data, and preferably additional OEM-specific, integrator-specific, or customer-specific data, are obtained from a trusted database via a secure connection at fixed time intervals or in an event-controlled manner, or are stored or mounted on a corresponding secure storage device (when it includes, for example, a certificate).

[0049] In one implementation, this can be advantageous if the component certificate is a manufacturer's equipment certificate, and / or the associated data includes a chain of trust for the component certificate and / or one (or more) certificate revocation lists.

[0050] In one implementation, it can be advantageously proposed that relevant information from component certificates is recorded in a computer-implemented device inventory, and this information is marked based on inspection results, for example, by highlighting or equipping it with appropriate status and / or flags. This enables the automated and dynamic construction of a computer-implemented device inventory, where relevant device data, particularly the inspection status, can be used for the component.

[0051] In one implementation, it can be advantageous to create and / or configure and / or use different inspection profiles to inspect different components, wherein the inspection profile characterizes the process of inspection or inspection method.

[0052] In one implementation, it is advantageous to propose, based on the results of the inspection, the creation and / or configuration and / or use of different action profiles, and / or the prevention of further communication between components and other system components.

[0053] This allows the system to consider or explain the status of the check to the user. Consequently, the user can directly or indirectly participate in configuring the relevant profile to select the appropriate response.

[0054] Furthermore, according to the present invention, this objective is achieved by a device inventory implemented by a computer of the type mentioned at the beginning, wherein the device inventory includes at least one component certificate of a component and a notification associated with that component, wherein the notification is generated by the method described above.

[0055] A computer-implemented method for creating or updating a device inventory is also disclosed. As described above, the computer-implemented device inventory can preferably be developed continuously and dynamically, thereby including at least one component certificate for a component and a notification associated with that component, which is generated according to the method.

[0056] Furthermore, this objective is achieved using a computer program according to the invention, wherein the computer program includes instructions that, when executed by a system, cause the execution of the above-described method.

[0057] In addition, the use of component certificates for interactive verification of components in industrial control systems has been disclosed.

[0058] In summary, the provided system and method address the problem that specific, relevant equipment data used to verify components of industrial control systems are easily manipulated and therefore unreliable.

[0059] Another aspect of the invention is the ability to use different inspection processes and inspection agencies (with trusted inventory) simultaneously in the same environment. All components inspected in different ways and methods (e.g., according to pre-configured or dynamically configurable inspection profiles at runtime) or their related data can be entered into a common inventory, allowing users to have a unified understanding of all components of the facility, including their verification status. Attached Figure Description

[0060] The invention will now be described and explained in more detail with reference to the embodiments shown in the accompanying drawings. The drawings show:

[0061] Figures 1 to 4 illustrate the verification of system components using existing technologies and anomaly detection tools.

[0062] Figure 5 This demonstrates an interactive inspection of the manufacturer's equipment certificate using an anomaly detection tool.

[0063] Figure 6 Anomaly detection tools are shown.

[0064] Figure 7 The document shows a list of devices used to input the inspection results into a computer.

[0065] Figure 8 This demonstrates how to apply for a manufacturer's equipment certificate through the equipment application process.

[0066] Figure 9 The issuance of the manufacturer's equipment certificate is shown.

[0067] Figure 10 Another anomaly detection tool was shown, and

[0068] Figure 11A flowchart of a method for verifying components is shown. Detailed Implementation

[0069] In the embodiments and drawings, elements that are the same or have the same function can be respectively provided with the same reference numerals.

[0070] First, referring to Figures 1 to 4, the prior art is briefly outlined. Figures 1 to 4 show an industrial control system 1 of an automated facility (particularly a production or processing facility). Components of the industrial control system 1 are connected, for example, via an industrial Ethernet 8. It should be understood that components of the industrial control system 1 can also be connected via other common connection types (e.g., WLAN, Bluetooth, WAN, etc.) for information exchange purposes. Figures 1 and 2 show a scenario in which a (new) device 2 is connected to the industrial control system 1, verified, and recorded in a computer-implemented device list 3. Device 2 is designed as an industrial controller.

[0071] When the industrial controller 2 is connected to the industrial control system 1, the industrial controller 2 exchanges information with the server 4, which has, for example, the functions of an operator station (OS) or an engineer station (ES) and is configured to perform the connection and online of the industrial controller.

[0072] Another server 5 has a system 6 for verifying components or equipment of the industrial control system 1.

[0073] Servers 4 and 5 do not need to be separate. A single server can have their functions (not shown here).

[0074] System 6 is designed as an anomaly detection tool, which monitors the traffic between industrial controller 2 and OS / ES server 4 to read the MAC address 7 of industrial controller 2. Industrial controller 2 is the original equipment.

[0075] According to existing technology, state-of-the-art security anomaly detection tools can extract manufacturer-specific device data (such as MAC address 7) from detected network packets when necessary and verify it according to specific criteria. Furthermore, they can check the association between a specific device and a specific manufacturer based on MAC address 7 preset by the manufacturer.

[0076] For example, the anomaly detection tool 6 can infer the name and manufacturer of device 2 based on the read MAC address 7.

[0077] After the anomaly detection tool 6 has obtained manufacturer-specific information based on the MAC address 7, it creates a new device list entry 30 for device 2 in the computer-implemented device list 3. The device list typically has multiple entries 30, 31, 32, 33, 34, 35, 36, and 37 (Figure 2).

[0078] Device inventory entries 30, 31, 32, 33, 34, 35, 36, or 37 created for a device can contain the following (meta) information, such as:

[0079] - Device MAC address 7;

[0080] - Device IP address (static or dynamic);

[0081] - Device MLFB (Static) (MLFB = Machine-readable Product Name);

[0082] - Manufacturer Device Certificate (MDC) (Static);

[0083] - Facility-specific or facility-related Customer Device Certificate (CDC);

[0084] - Project-related Device Certificate (PDC) or (if the device is used for multiple projects) multiple such certificates (dynamic);

[0085] - Project-related operating certificates obtained from equipment licensing bodies (dynamically);

[0086] - Additional information regarding technical and mechanical characteristics, including communication and / or application protocols (static and / or dynamic) regarding performance and support.

[0087] Device list 3 is typically unprotected, allowing attackers to extract MAC address 7 from the original device 2's documentation and misuse it to forge the original device's identity.

[0088] Possible attacks of this type are shown in Figures 3 and 4.

[0089] Figure 3 illustrates the connection between the manipulated device 2' (e.g., an industrial controller) and the industrial control system 1. The manipulated device 2' can be, for example, a cloned device. The manipulated device 2' is not the original device 2. However, the manipulated device 2' has the MAC address 7 of the original device 2.

[0090] After the anomaly detection tool 6 detects the corresponding network packet and extracts the MAC address 7 from the network packet, it creates a corresponding device list entry 30 in the computer-implemented device list 30 (Figure 4). Since the MAC address 7 of the manipulated device 2' is the same as the MAC address 7 of the original device 2, it can be successfully verified even if the manipulated device 2' is not the original device 2. The manipulated fake device 2' can then participate in the communication of the factory's industrial control system 1 as the original device 2, even though it is untrusted and can (due to negligence or intention) jeopardize the system integrity and availability of the facility.

[0091] Figure 5 A portion of an industrial control system 100 for an automated facility (particularly a production or process facility) is shown. Components of the industrial control system 100 are connected, for example, via an industrial Ethernet 8. It should be understood that components of the industrial control system 100 can also be connected via other common connection types (e.g., WLAN, Bluetooth, WAN, etc.) to enable information exchange.

[0092] The industrial control system 100 has a component 200 designed as an industrial controller and a server 500.

[0093] To verify component 200, server 500 has an anomaly detection tool 600, wherein the anomaly detection tool 600 corresponds to the system according to the present invention.

[0094] Anomaly detection tool 600 includes a first module 601 and a second module 602 (see...) Figure 6 Modules 601 and 602 can be designed as software modules, for example. However, it is also possible to design at least one of modules 601 and 602 as a combination of software and hardware components.

[0095] When the component 200 is connected, the first module 601 establishes a trust relationship with the component 200 in order to request the component certificate 201 from the component 200. Figure 5 The industrial controller 200 is shown to be able to include a component certificate 201 having a public key associated with the component certificate 201.

[0096] Now for reference Figure 8 and Figure 9This section explains the application and creation of a Part Certificate 201. Part certificates, such as Part Certificate 201, can be issued and signed by a manufacturer's responsible and trusted Issuing Certification Authority (or Issuing CA for short). Furthermore, the part certificate is linked to a specific ID (e.g., serial number) and a key (private key) for the corresponding part, where the key is located within the part / device (e.g., software-bound), or ideally securely stored in the part's hardware (hardware-bound).

[0097] For example, a component certificate can be placed on the associated component / equipment during the manufacturing process at the equipment factory.

[0098] Specifically, Figure 8 and 9 The steps for applying a component certificate in the form of a Manufacturer Equipment Certificate (MDG) 201 to an industrial controller 200 are shown.

[0099] Manufacturer X has / includes: an equipment factory X1 in which industrial controller 200 is manufactured; and a public key infrastructure having a trust center X2 for issuing trusted certificates.

[0100] A key 202 can be generated in the hardware of device 200 during manufacturing. Device 200 can then use the secret key 202 to sign a certificate signing request 203 and transmit it via secure communication X3 (e.g., encrypted) to the responsible issuing authority X21, which may be located, for example, in the trust center X2 of manufacturer X.

[0101] Trust Center X2 can include a root Certificate Authority X22 (root CA) capable of creating (self-signed) root certificates / trust anchors X220. Issuing CA X21 can process certificate requests 203 and create component certificates 201 based on them. Component certificates 201 can therefore be designed as a chain of certificates. Such a chain of certificates is also called a certificate path or a chain of trust. The last certificate in the chain of trust 201 is a trust anchor X220 issued by the root CA X22.

[0102] Certificate Request 203 typically contains important device data (such as manufacturer-specific device data), specifically the names of the manufacturer (“X”) and manufacturing plant (“X1”), the ID of device 200 (e.g., serial number), and the public key of key 202 used to sign Certificate Request 203. The data from Certificate Request 203 (including the public key) can be referenced from the issuing CA X21 to the issued device certificate 201. After the issuance of MDC 201, it can be transferred from the issuing CA X21 to the device plant X1 via secure path X3, and then applied to device 200 (see [link to MDC 201]). Figure 9 ).

[0103] As described above, in addition to manufacturer-specific equipment data, specifically the names of the manufacturer (“X”) and manufacturing plant (“XI”), the serial number of equipment 200, and the public key of key 202 used to sign certificate request 203, component certificate 201 also includes a certificate X210 of an associated higher-level issuing CA X21 responsible for equipment plant X1 named “X1”, and a root certificate X220 of an associated higher-level root CA X22 responsible for manufacturer X named “X”. All of these are instances of relevant equipment data (for anomaly detection tool 600 to check).

[0104] In addition, the applicant / owner's Component Certificate 201ID (Identification), device name, issuer name (issuer CAX21), and its validity period ("valid from... to...") or other such information may be specified by standards such as IEEE 802.1AR 2018 or manufacturer-specific standards.

[0105] Figures 5 to 7 As can be seen, the second module 602 checks the component certificate 201. This check is performed interactively. Here, the anomaly detection tool 600 exchanges information with the component 200. The prior art anomaly detection tool 6 does not have this interaction pre-configured (Figures 1 to 4). For the check, the anomaly detection tool 600 uses relevant data 901 stored in a trusted database 900, such as manufacturer-specific data. The second module 602 is designed, for example, as a software module, and may include corresponding program code with instructions that, when executed, trigger an interactive check of the component certificate 201.

[0106] Trusted database 900, for example, can belong to manufacturer X of component 200, such as a certificate repository designed to be manufacturer X.

[0107] Furthermore, the anomaly detection tool 600 can have a secure memory 6020 arranged in the second module 602 so that, for example, when the relevant data 901 in the database changes, the relevant data 901 can be obtained from the trusted database 900 in a secure manner and method, such as via a secure communication channel at regular time intervals or in an event-controlled manner, and stored or installed on the secure memory 6020.

[0108] The relevant data 901 may include a (manufacturer-specific) chain of trust 9010 for the component certificate 201 and / or a certificate revocation list (a list of revoked certificates) 9011.

[0109] Based on relevant data 901, the anomaly detection tool 600 can check the correctness, consistency and validity of the component certificate content, perform identity and originality checks on the component 200, and check the revocation status of the component certificate 201.

[0110] During the interactive inspection, component 200 is able to use its private key for component certificate 201 without revealing the private key 202 thereon.

[0111] The results of the check can be, for example: "Check successful", "Check failed", or "Check is not feasible".

[0112] For example, based on the inspection results, the anomaly detection tool 600 generates a notification and sends it to the responsible agency.

[0113] Following the inspection, relevant, such as manufacturer-specific, information from the inspected component certificate 201 can be recorded in the computer-implemented device list 300, and the inspection results can be marked, for example, by highlighting or providing appropriate status and / or markings. For this purpose, anomaly detection tool 600 (see...) can be used... Figure 10 The third module 603 is provided in ().

[0114] The anomaly detection tool 600 can include a computer-implemented list of devices 300.

[0115] If the inspection is successful, relevant, such as manufacturer-specific data (especially the corresponding MDC), can be securely stored in the computer-implemented device list 300 or the facility's device list (not shown) contained in the anomaly detection tool 600 with the (first) flag 301 "Identity / Originality: Inspection Successful".

[0116] If the inspection fails, for example when part certificate 201 has been revoked, the corresponding notification can also be distributed to the responsible agency. Here, the relevant data of the inspection, such as manufacturer-specific equipment with (second) status / mark 302 (e.g., identity / origin: inspection failed) (especially the corresponding MDC), can be securely stored in the integrated inventory 300 of the anomaly detection tool 600 itself or in the inventory of the facility (not shown here).

[0117] If inspection is not feasible, for example due to the lack of component certificate 201 and / or associated secret key, a corresponding notification can be generated (regarding that inspection is not feasible and unverifiable device 200 is therefore trustworthy) and transmitted to the responsible agency. In this case, the existing (uninspected) related data equipped with (third) status / mark 303 (e.g., "Identity / Originality: Inspection is not feasible") is recorded in list 300 or a list of dedicated facilities (not shown here).

[0118] Figure 10 The anomaly detection tool 600 is shown to include a fourth module 604 configured to create and / or configure and / or use different inspection profiles to inspect different components, wherein the inspection profile characterizes the inspection process. This is always advantageous when different manufacturers implement different inspection methods in their equipment.

[0119] from Figure 10 It can be seen that the anomaly detection tool 600 may include a fifth module 605, which is configured to create and / or configure and / or use different action profiles based on the inspection results, and / or (especially in particularly critical environments) prevent further communication between the component and / or other system components, for example, if the inspection fails or is not feasible.

[0120] Figure 11 A flowchart illustrating an embodiment of a method for verifying components of an industrial control system according to the present invention is shown. Here, firstly (step S1), a trust relationship is established with the components of the industrial control system, and a component certificate is requested from the components, wherein the component certificate contains relevant information, such as manufacturer-specific information about the components.

[0121] Then, based on relevant, manufacturer-specific data, such as data stored in a trusted database, an interactive check is performed on the component certificate (step S2). A notification is then generated based on the check results (step S3).

[0122] Figure 11 An example of a method is shown in which the check has three possible outcomes: M1 ("Check successful"), M2 ("Check failed"), and M3 ("Check is not feasible").

[0123] For example, in Figures 5 to 10 The environment described herein is executed using an anomaly detection tool 600. Figure 11 The method shown has steps S1 to S3.

[0124] Although the invention has been described and illustrated in more detail by way of examples, the invention is not limited to the disclosed examples. Variations can be derived by those skilled in the art without departing from the scope of the invention. In particular, the described anomaly detection tools and industrial control systems can be supplemented by features of the method, and the method can be supplemented by features of the anomaly detection tools and industrial control systems.

Claims

1. A system for verifying components of an industrial control system (100), wherein, The system (600) includes: - A first module (601) configured to establish a trust relationship with a component (200) of the industrial control system (100) and request a component certificate (201) from the component (200), wherein the trust relationship is a confidential connection and the component certificate (201) contains relevant information about the component (200); - Second module (602), the second module is configured for, Based on relevant data (901) stored in a trusted database (900), and The component certificate (201) is checked by interacting with the component (200) and an appropriate response is made to the check results, wherein the relevant data (901) includes one or more trust chains (9010) and / or includes one or more certificate revocation lists (9011), wherein one or more trust chains (9010) and / or one or more certificate revocation lists (9011) are verified during the check. The system (600) includes a fifth module (605) configured to create and / or configure and / or use different action profiles based on the inspection results, and / or prevent further communication between the component and other facility components.

2. The system according to claim 1, wherein, The system (600) has a secure memory (6020) and is configured to retrieve the relevant data (901) from the trusted database (900) via a secure connection at regular time intervals or in an event-controlled manner, and store or install the relevant data on the secure memory (6020).

3. The system according to claim 2, wherein, The memory (6020) is designed to be protected from unauthorized modification or manipulation.

4. The system according to claim 2 or 3, wherein, The second module (602) includes a memory (6020).

5. The system according to claim 2 or 3, wherein, The memory (6020) stores the certificate and the trust chain and / or certificate revocation list associated with the certificate.

6. The system according to any one of claims 1 to 3, wherein, The trusted database (900) is designed as a certificate repository for the manufacturer of the component (200).

7. The system according to any one of claims 1 to 3, wherein, The component certificate is a manufacturer's equipment certificate.

8. The system according to any one of claims 1 to 3, wherein, The system (600) includes a third module (603) configured to record the relevant information from the component certificate (201) in a computer-implemented device list (300) and to tag the relevant information based on the inspection results.

9. The system according to claim 8, wherein, The third module is configured to highlight the relevant information or equip the relevant information with appropriate status and / or flags (301, 302, 303) based on the inspection results.

10. The system according to any one of claims 1 to 3, wherein, The system (600) includes a fourth module (604) configured to create and / or configure and / or use different inspection profiles for inspecting different components, wherein the inspection profiles characterize the inspection process.

11. The system according to any one of claims 1 to 3, wherein, The component (200) is configured to use the component's private key for the component certificate (201) during the inspection without disclosing the private key.

12. A computer-based method for verifying components of an industrial control system (100), wherein, - Establish a trust relationship with a component (200) of the industrial control system (100) and request a component certificate (201) from the component (200), wherein the trust relationship is a confidential connection, and wherein the component certificate (201) contains relevant information about the component (200). - The component certificate (201) is checked by interacting with the component (200) and based on relevant data (901) stored in a trusted database (900), wherein the relevant data (901) includes one or more trust chains (9010) and / or includes one or more certificate revocation lists (9011), wherein, during the check, one or more of the trust chains (9010) and / or one or more of the certificate revocation lists (9011) are verified, and - Respond appropriately to the examination results. Based on the inspection results, different action profiles may be created and / or configured and / or used, and / or further communication between the component and other facility components may be prevented.

13. The method according to claim 12, wherein, The relevant data (901) is retrieved from the trusted database (900) via a secure connection and stored or installed on a secure storage device (6020) at regular time intervals or in an event-controlled manner.

14. The method according to claim 12 or 13, wherein, The component certificate is a manufacturer's equipment certificate.

15. The method according to claim 12 or 13, wherein, The relevant information from the component certificate is recorded in a computer-implemented device list (300), and the relevant information is tagged according to the inspection results.

16. The method according to claim 15, wherein, Based on the inspection results, highlight the relevant information or equip the relevant information with appropriate status and / or flags (301, 302, 303).

17. The method according to claim 12 or 13, wherein, Different inspection profiles are created and / or configured and / or used to inspect different components, wherein the inspection profiles characterize the inspection process.

18. A computer-implemented device inventory, the device inventory comprising at least one component certificate for a component and results of an inspection associated with said component, said inspection being performed by the method of any one of claims 12 to 17.

19. A computer program comprising instructions that, when executed by a system, cause the system to perform the method according to any one of claims 12 to 17.

Images