System and method for verifying components of an industrial monitoring system

Abstract

A system for verifying components of an industrial monitoring system includes a first module which is configured to establish a trust relationship with a component of the industrial monitoring system and request a component certificate from the component. The component certificate contains relevant information relating to the component. A second module is configured to check, in interaction with the component, the component certificate on the basis of relevant data stored in a trusted database, and to generate a notification on the basis of the result of the checking process.

Claims

1. A system for verifying components of an industrial monitoring system, the system for verifying components comprising: a first module configured to establish a relationship of trust as a confidential connection with a component of the industrial monitoring system, and to request a component certificate from the component, with the component certificate containing relevant information relating to the component; a second module configured to check the component certificate based on relevant data kept in a trustworthy database and comprising one or more trust chains and/or one or more certificate blacklists, and in interaction with the component, to validate during the check one or more trust chains and/or one or more certificate blacklists, and to respond appropriately to a result of the check; a further module configured to prevent further communication between the component and other plant components as a function of the result of the check; and a secure memory configured to obtain the relevant data from the trustworthy database at regular intervals or in an event-controlled manner via a secure connection and to store or install the relevant in the secure memory, wherein the second module comprises the secure memory.

2. The system of claim 1, wherein the secure memory is embodied as a memory protected against unauthorized changes or manipulations.

3. The system of claim 1, wherein certificates and trust chains and/or certificate blacklists associated with the certificates are saved in the secure memory.

4. The system of claim 1, wherein the trustworthy database is embodied as a certificate repository of the manufacturer of the component.

5. The system of claim 1, wherein the component certificate is a manufacturer device certificate.

6. The system of claim 1, further comprising a third module configured to accept relevant information from the component certificate into a computer-implemented device inventory and to highlight the relevant information or provide the relevant information with an appropriate status and/or flag in accordance with the result of the check.

7. The system of claim 1, further comprising a fourth module configured to create and/or configure and/or use different check profiles for checking different components, wherein the check profiles characterize a procedure of the checking process.

8. The system of claim 1, wherein the further module comprises a fifth module configured to create and/or configure and/or use different action profiles.

9. The system of claim 1, wherein the component is configured to use its private key to the component certificate during the check, without disclosing said private key.

10. A computer-implemented method for verifying components of an industrial monitoring system, the computer implemented method comprising: establishing with a first module, a relationship of trust as a confidential connection with a component of the industrial monitoring system; requesting, with the first module, a component certificate from the component, wherein the component certificate contains relevant information relating to the component; checking, with a second module, the component certificate in interaction with the component and based on relevant data kept in a trustworthy database, wherein the relevant data comprises one or more trust chains and/or one or more certificate blacklists; validating, with the second module, during the check one or more trust chains and/or one or more certificate blacklists; giving with the second module, an appropriate response to a result of the check; preventing, with a further module further communication between the component and other plant components as a function of the result of the check; obtaining, with a secure memory, the relevant data from the trustworthy database at regular intervals or in an event-controlled manner via a secure connection; and storing or installing the relevant data in the secure memory, wherein the second module comprises the secure memory.

11. The method of claim 10, wherein the component certificate is a manufacturer device certificate.

12. The method as claimed in one of claim 10, further comprising: accepting relevant information from the component certificate into a computer-implemented device inventory; and highlighting the relevant information or providing an appropriate status and/or flag for the relevant information in accordance with the result of the check.

13. The method of claim 10, further comprising creating and/or configuring and/or using different check profiles for checking different components, wherein the check profiles characterize a procedure of the checking process.

14. The method of claim 10, further comprising: creating and/or configuring and/or using different action profiles as a function of the result of the check.

15. A computer-implemented device inventory comprising at least one component certificate for a component and a result of a check associated with the component in accordance with a method of claim 10.

16. A computer program embodied on a non-transitory computer readable medium comprising commands, which when executed by a system, cause the system to execute a method as set forth in claim 10.

Description

BRIEF DESCRIPTION OF THE DRAWING

(1) The invention is described and explained in greater detail below on the basis of the exemplary embodiments represented in the figures, in which:

(2) FIG. 1 to FIG. 4 show the verification of plant components by means of anomaly detection tools in accordance with the prior art,

(3) FIG. 5 shows an interactive check of a manufacturer device certificate by an anomaly detection tool,

(4) FIG. 6 shows an anomaly detection tool,

(5) FIG. 7 shows the entry of the check results into a computer-implemented device inventory,

(6) FIG. 8 shows an application for a manufacturer device certificate by a device,

(7) FIG. 9 shows the issue of a manufacturer device certificate,

(8) FIG. 10 shows a further anomaly detection tool, and

(9) FIG. 11 shows a flow diagram of a method for verifying components.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

(10) In the exemplary embodiments and figures, identically or identically acting elements can in each case be provided with the same reference characters.

(11) Reference is first made to FIGS. 1 to 4, which briefly outline the prior art. FIGS. 1 to 4 show an industrial monitoring system 1 of an automation plant, in particular a production or process plant. The components of the Industrial monitoring system 1 are for example connected via Industrial Ethernet 8. Obviously the components of the industrial monitoring system 1 can also be connected using other standard types of connection, for example WLAN, Bluetooth, WAN, etc., for the purpose of exchanging information. FIGS. 1 and 2 illustrate a situation in which a (new) device 2 is connected to the industrial monitoring system 1, verified and accepted into a computer-implemented device inventory 3. The device 2 is embodied as an industrial controller.

(12) On connection of the industrial controller 2 to the industrial monitoring system 1 the industrial controller 2 exchanges information with a server 4, which for example has functionalities of an operator station (OS) or an engineering station (ES) and is configured to perform the connection or onboarding of the industrial controller.

(13) Another server 5 has a system 6 for verifying components or devices of the industrial monitoring system 1.

(14) The servers 4 and 5 need not be separate. A single server (not shown here) can contain their functionalities.

(15) The system 6 is embodied as an anomaly detection tool which listens to the traffic between the industrial controller 2 and the OS/ES server 4 in order to read the MAC address 7 of the industrial controller 2. The industrial controller 2 is an original device.

(16) The security anomaly detection tools in accordance with the prior art can if required extract manufacturer-specific device data (e.g. MAC addresses 7) among other things from the detected network packets and verify them in accordance with particular criteria. Among other things, the association of a particular device with a particular manufacturer can in this case be checked on the basis of the MAC address 7 assigned by the manufacturer.

(17) Based on the MAC address 7 read the anomaly detection tool 6 can for example extrapolate the name and the manufacturer of the device 2.

(18) After the anomaly detection tool 6 has used the MAC address 7 to determine the manufacturer-specific information, it creates a new device inventory entry 30 for the device 2 in the computer-implemented device inventory 3. The device inventory normally has multiple entries 30, 31, 32, 33, 34, 35, 6, 37 (FIG. 2).

(19) A device inventory entry 30, 31, 32, 33, 34, 35, 36 or 37 created for a device can for example contain the following (meta-)information: the device MAC address 7, the device IP address (static or dynamic), the device MLFB (static) (MLFB=machine-readable product designation), the manufacturer device certificate (MDC) (static), the plant-specific or plant-related customer device certificate (CDC), the project-related device certificate (PDC) or (if the device is employed in multiple projects) a plurality of such certificates (dynamic), project-related operational certificates, that have already been obtained from the device authority (dynamic), further information regarding the technical and mechanical features, including as regards the performance and the communication and/or application protocols supported (static and/or dynamic).

(20) The device inventory 3 is generally not protected, so that an attacker can extract the MAC address 7 for example from the documentation for the original device 2 and misuse it to simulate the identity of an original device.

(21) A possible attack of this type is shown in FIGS. 3 and 4.

(22) FIG. 3 illustrates the connection of a manipulated device 2, for example of an industrial controller to the industrial monitoring system 1. The manipulated device 2 can for example be a replicated device. The manipulated device 2 is not an original device 2. Nevertheless the manipulated device 2 has the MAC address 7 of an original device 2.

(23) After the anomaly detection tool 6 has detected the corresponding network packet and extracted the MAC address 7 therefrom, it creates a corresponding device inventory entry 30 in the computer-implemented device inventory 3 (FIG. 4). Since the MAC address 7 of the manipulated device 2 and the MAC address 7 of the original device 2 are identical, the manipulated device 2 is successfully verified, even though it is not an original device 2. The manipulated fake device 2 can then participate as an original device 2 in the communication in the industrial monitoring system 1 of the plant, even though it is not trustworthy and can potentially (because of negligence or deliberately) endanger the system integrity and availability of the plant.

(24) FIG. 5 shows a section of an industrial monitoring system 100 of an automation plant, in particular a production or process plant. The components of the industrial monitoring system 100 are for example connected via Industrial Ethernet 8. Obviously the components of the industrial monitoring system 100 can also be connected using other standard types of connection, for example WLAN, Bluetooth, WAN, etc., for the purpose of exchanging information.

(25) The industrial monitoring system 100 has a component 200 embodied as an industrial controller, and a server 500.

(26) To verify the component 200 the server 500 has an anomaly detection tool 600, wherein the anomaly detection tool 600 corresponds to the inventive system.

(27) The anomaly detection tool 600 comprises a first module 601 and a second module 602 (see FIG. 6). The modules 601 and 602 can for example be embodied as software modules. However, it is also conceivable for at least one of the modules 601, 602 to be embodied as a combination of software and hardware components.

(28) On connection of the component 200 the first module 601 establishes a relationship of trust with the component 200, in order to request a component certificate 201 from the component 200. FIG. 5 shows that the industrial controller 200 can comprise the component certificate 201 with a public key associated with the component certificate 201.

(29) To Illustrate the application for and creation of the component certificate 201 reference is now made to FIGS. 8 and 9. Component certificates such as the component certificate 201 can e.g. be issued and signed by a competent trustworthy issuing certification authority (Issuing CA for short) of the manufacturer. Additionally, component certificates are linked to a unique ID (e.g. a serial number) of the respective component and to a private key, wherein the private key is securely stored in the component/in the device (e.g. software-based) or ideally in the hardware of the component (hardware-based).

(30) Component certificates can for example be placed into the associated components/devices during manufacture in a device plant.

(31) FIGS. 8 and 9 provide a concrete illustration of placement of a component certificate in the form of a manufacturer device certificate (MDC) 201 into an industrial controller 200.

(32) A manufacturer X has/comprises a device plant X1, in which industrial controllers 200 are manufactured, and a public key infrastructure with a trust center X2 for issuing trustworthy certificates.

(33) During the manufacture a private key 202 can be generated in the hardware of the device 200. Using this private key 202 the device 200 can then sign a certificate signing request 203 and send it via a secure communication X3, e.g. encrypted, to a competent issuing certification authority X21, which can e.g. be located in the trust center X2 of the manufacturer X.

(34) The trust center X2 can comprise a root certification authority X22 (Root CA), which can create (self-signed) root certificates/trust anchors X220. The issuing CA X21 can process the certificate signing request 203 and based on this create a component certificate 201. The component certificate 201 can thus be embodied as a chain of certificates. Such certificate chains are also called certification paths or trust chains. The last certificate in the trust chain 201 is a trust anchor X220 issued by the root CA X22.

(35) The certificate signing request 203 generally contains some important device data (e.g. manufacturer-specific device data), in particular the name of the manufacturer (X) and of the manufacturing plant (X1), an ID (e.g. serial number) of the device 200 and the public key for the private key 202 used to sign the certificate signing request 203. The data from the certificate signing request 203 (including the public key) can be transferred by the issuing CA X21 into the issued device certificate 201. After the MDC 201 has been issued it can be transferred by the issuing CA X21 on a secure path X3 to the device plant X1 and then placed onto the device 200 (see FIG. 9).

(36) In light of the above, the component certificate 201 can also contain, apart from the manufacturer-specific device data, in particular the name of the manufacturer (X) and of the manufacturing plant (X1), the serial number of the device 200 and the public key for the private key 202 used to sign the certificate signing request 203, as well as a certificate X210 of the associated, higher-level issuing CA X21, which is responsible for the device plant X1 named X1, and the root certificate X220 of the associated, higher-level root CA X22, which is responsible for the manufacturer X named X. All these are examples of the relevant device data (relevant for the check by the anomaly detection tool 600).

(37) Additionally the component certificate 201 can contain the ID (identification) of the applicant/owner, a name of the device, a name of the issuer (of the issuing CA X21) and its period of validity (valid from . . . to . . . ). One or more of these details can for example be laid down by standards, such as e.g. IEEE 802.1AR 2018 or by manufacturer-specific standards.

(38) FIGS. 5 to 7 show that the second module 602 checks the component certificate 201. The check takes place interactively. The anomaly detection tool 600 in this case exchanges Information with the component 200. Such Interaction is not provided for in the case of anomaly detection tools 6 in accordance with the prior art (FIG. 1 to FIG. 4). For the check the anomaly detection tool 600 uses relevant, for example manufacturer-specific, data 901, which is kept in a trustworthy database 900. The second module 602, which for example is embodied as a software module, can comprise a corresponding program code which contains commands that on execution of the program code bring about the interactive check of the component certificate 201.

(39) The trustworthy database 900 can for example belong to the manufacturer X of the component 200, e.g. can be embodied as a certificate repository of the manufacturer X.

(40) In addition the anomaly detection tool 600 can have a secure memory 6020, arranged for example in the second module 602, in order to obtain the relevant data 901 from the trustworthy database 900 at regular intervals or in an event-controlled manner, e.g. in the event of a change in the relevant data 901 in the database 900, in a secure manner, e.g. via a secure communication channel, and to store or install it in the secure memory 6020.

(41) The relevant data 901 can comprise (manufacturer-specific) trust chains 9010 for the component certificate 201 and/or certificate blacklists (lists of the blacklisted certificates) 9011.

(42) Based on the relevant data 901 the anomaly detection tool 600 can check the correctness, the consistency and the validity of the contents of the component certificate, perform an identity and originality check on the component 200 and check a revocation status of the component certificate 201.

(43) During the interactive check the component 200 can use its private key to the component certificate 201, without thereby disclosing said private key 202.

(44) The result of the check can for example be: check successful, check failed or check infeasible.

(45) As a function of the result of the check the anomaly detection tool 600 generates a notification and distributes it for example to a competent authority.

(46) After the check, relevant, e.g. manufacturer-specific, information can be accepted from the checked component certificate 201 into a computer-implemented device inventory 300 and in accordance with the result of the check characterized, for example highlighted or provided with an appropriate status and/or flag. A third module 603 can be provided for this in the case of the anomaly detection tool 600 (see FIG. 10).

(47) The anomaly detection tool 600 can comprise the computer-implemented device inventory 300.

(48) If a check is successful, the relevant, e.g. manufacturer-specific, data (in particular the respective MDCs) can be securely saved with a (first) flag 301 Identity/Originality: successfully checkedin the computer-implemented device inventory 300 contained in the anomaly detection tool 800 or in the device inventory of the plant (not shown).

(49) In the event that the check has failed, if for example the component certificate 201 has already been revoked, a corresponding notification can likewise be distributed to the competent authority. In this case the relevant, e.g. manufacturer-specific, data (in particular the respective MDCs) subject to the checkprovided with a (second) status/flag 302 (e.g. Identity/Originality: check failed)can be securely stored in the anomaly detection tool's 600 own integrated inventory 300 or in the inventory of the plant (not shown here).

(50) If a check is infeasible, for example because of the absence of the component certificate 201 and/or of the associated private key, a corresponding notification (to the effect that the check is infeasible and that the device 200 cannot therefore be demonstrated to be trustworthy) can likewise be generated and sent to a competent authority. In this case the available (unchecked) relevant dataprovided with a (third) status/flag 303 (e.g. Identity/Originality: check infeasible)can be accepted into the inventory 300 or a dedicated plant inventory (not shown here).

(51) FIG. 10 shows that the anomaly detection tool 600 can comprise a fourth module 604, which is configured to create and/or configure and/or use different check profiles for checking different components, wherein the check profiles characterize a procedure of the checking process. This is always advantageous in cases in which different manufacturers have implemented different checking methods in their devices.

(52) It can be seen from FIG. 10 that the anomaly detection tool 600 can comprise a fifth module 605, which is configured to create and/or configure and/or use different action profiles as a function of the result of the check, and/orin particular in an especially critical environmentto prevent further communication between the component and/or other plant components, e.g. If the check has failed or is infeasible.

(53) FIG. 11 shows a flow diagram of a form of embodiment of the inventive method for verifying components of an industrial monitoring system. In this case firstly (step S1) a relationship of trust is established with a component of the industrial monitoring system and a component certificate is requested from the component, wherein the component certificate contains relevant, e.g. manufacturer-specific, information relating to the component.

(54) Following this an interactive check of the component certificate is performed (step S2) on the basis of relevant, e.g. manufacturer-specific, data kept in a trustworthy database. Then on the basis of a result of the check a notification is generated (step S3).

(55) FIG. 11 shows an example of the method, in which the check has three possible outcomes: M1 (check successful), M2 (check failed) and M3 (check infeasible).

(56) The method Illustrated in FIG. 11 with steps S1 to S3 can be performed for example in the environment described in FIGS. 5 to 10 by means of the anomaly detection tool 600.

(57) Although the invention has been illustrated and described in detail using exemplary embodiments, the invention is not restricted by the disclosed examples. Variations thereof can be derived by the person skilled in the art, without departing from the scope of protection of the invention, as defined by the claims below. In particular, the described anomaly detection tool and the industrial monitoring system can be supplemented by features of the method and the method by features of the anomaly detection tool and of the industrial monitoring system.