WO2023092570A1 - Method, apparatus and system for software updating in an industrial network - Google Patents

Method, apparatus and system for software updating in an industrial network Download PDF

Info

Publication number
WO2023092570A1
WO2023092570A1 PCT/CN2021/134064 CN2021134064W WO2023092570A1 WO 2023092570 A1 WO2023092570 A1 WO 2023092570A1 CN 2021134064 W CN2021134064 W CN 2021134064W WO 2023092570 A1 WO2023092570 A1 WO 2023092570A1
Authority
WO
WIPO (PCT)
Prior art keywords
industrial network
verification result
patch
deployed
industrial
Prior art date
Application number
PCT/CN2021/134064
Other languages
French (fr)
Inventor
Daifei Guo
Original Assignee
Siemens Ltd., China
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Ltd., China filed Critical Siemens Ltd., China
Priority to PCT/CN2021/134064 priority Critical patent/WO2023092570A1/en
Publication of WO2023092570A1 publication Critical patent/WO2023092570A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
    • G06F2221/033—Test or assess software

Definitions

  • the present invention relates to security technology, and more particularly to a method, apparatus, system and computer-readable storage medium for software updating in an industrial network.
  • Software updating plays key role for security of industrial devices, providing various upgrade and security vulnerability fixing.
  • Traditionally for example, in IT environment, a patch can be delivered to a target device online and the patch will be automatically updated in the device. But in OT environment, software has strict requirement of compatibility and updating. Not having strict testing may cause running anomaly of industrial devices.
  • a system for software updating in an industrial network can include a first apparatus and at least one second apparatus, each second apparatus supervising an industrial network, wherein, the first apparatus can send to a second apparatus a first request to verify whether a new issued patch can be deployed in an industrial network supervised by the second apparatus; the second apparatus receives from the first apparatus the first request, tests the new issued patch in a simulated environment of the industrial network to generate a first verification result indicating whether the new issued patch can be deployed in the industrial network, and sends to the first apparatus the first verification result; the first apparatus receives from the second apparatus the first verification result, and adds the first verification result into a blockchain.
  • distributed verification for software updating and testing in an industrial network is proposed to generate simulated industrial environment and make the patch testing, the testing result is shared in a blockchain, then industrial networks can share the test result.
  • the distributed verification can speed up the process of verification of the latest patch.
  • the block chain-based software updating mechanism can provide the de-centralized management of patch verification request and verification process, it reduces the cost of the patch verification.
  • the block chain-based software updating mechanism can also provide the feature of tamper proof and trust-based result management, this can assure the verification result of patch is valid and trusty.
  • the verification result is based on a simulated environment of real industrial networks, which means that the result will be more accurate and more compatible with the target industrial network.
  • the simulated environment of the industrial network can be:
  • the simulated environment is built up based on real industrial network, which makes the testing result be more precise.
  • the second apparatus can send to the first apparatus a second request to query in what kind of industrial networks the new issued patch has been verified to be deployed; the first apparatus can get from the blockchain at least one second verification result indicating in what kind of industrial networks the new issued patch has been verified to be deployed and send to the second apparatus, the at least one second verification result; if none of at least one second verification result can indicate whether the new issued patch can be deployed in the industrial network the second apparatus will test the new issued patch.
  • the second apparatus Before running the test, the second apparatus can query in what kind of industrial networks the new issued patch has been verified to be deployed, and decide based on the available information whether it is necessary to run the test, with shared information in the blockchain, repeated testing can be avoided, which saves time and improve efficiency.
  • the second apparatus can send to the first apparatus a usage result indicating that the second apparatus uses a specific verification result of the at least one second verification result.
  • the first apparatus can set trust level of the second apparatus based on a first number of verification results submitted by the second apparatus and a second number of normal usage results submitted by other second apparatuses indicating that verification results submitted by the second apparatus are used by other second apparatuses and verified to be right; and label the first verification result with the trust level of the second apparatus.
  • the trust level can be a reference for other second apparatus to decide whether to use available verification results or run a test on its own.
  • FIG. 1 depicts a system for software updating in an industrial network.
  • FIG. 2 depicts a flow diagram of a method for software updating in an industrial network in accordance with one embodiment of the present disclosure.
  • FIG. 3 depicts a block diagram of a first apparatus for software updating in an industrial network in accordance with one embodiment of the present disclosure.
  • FIG. 4 depicts a block diagram of a second apparatus for software updating in an industrial network in accordance with one embodiment of the present disclosure.
  • the articles “a” , “an” , “the” and “said” are intended to mean that there are one or more of the elements.
  • the terms “comprising” , “including” and “having” are intended to be inclusive and mean that there may be additional elements other than the listed elements.
  • FIG. 1 depicts a system for software updating in an industrial network.
  • the system 100 can include: a first apparatus 10 and at least one second apparatus 20, each second apparatus corresponding to an industrial network 40, configured to executing patch verification for the corresponding industrial network 40.
  • an industrial network 40 “a supervised industrial network 40” .
  • the first apparatus 10 can be deployed in a cloud environment, which provides high availability for software updating status monitoring, distributed software updating verification management and sharing test results.
  • the second apparatuses 20 can be deployed locally on sites of industrial networks 40. It can be deployed in IT or OT environment. For example, a second apparatus 20 can be deployed in a server in an industrial network 40 it supervises.
  • the first apparatus 10 can monitor the software updating status, for example it can communicate with a patch center. When there is a new issued patch 30, the software updating procedure in the present disclosure can be triggered.
  • the first apparatus 10 can be configured to request all or part of the at least one second apparatus 20 to verify whether a new issued patch 30 can be deployed in industrial networks 40.
  • a second apparatus 20 can be configured to test the patch 30 in a simulated environment of the supervised industrial network 40 and generate verification result.
  • the first apparatus 10 can add received verification results into a blockchain for further sharing.
  • a second apparatus 20 can get information of the supervised industrial network 40 (such as system configuration, key processes and software) to build up a simulated environment of the industrial network 40.
  • the simulated environment can contain same hardware and software configuration.
  • the patch 30 can be downloaded and installed in the simulated environment, and then the second apparatus 20 can run a test (preferable for a preset period) . Verification result can be generated based on the status of simulated environment and sent to the first apparatus 10, the first apparatus 10 can add the verification result into a blockchain.
  • FIG. 2 depicts a flow diagram of a method for software updating in an industrial network in accordance with one embodiment of the present disclosure. As shown in FIG. 2, the method 200 can include following steps:
  • the first apparatus 10 can communicate with a patch center, once there is a new issued patch, the first apparatus 10 can detect it and trigger following steps.
  • the first apparatus 10 can get information of the new issued patch 30, which can include at least one of the following items:
  • target industrial network (may including software’s version in the target industrial network -) that the patch is to be deployed in
  • the first apparatus 20 can generate a first request for verification of the new issued patch 30.
  • the first request can include above information of the new issued patch 30 and optionally other information as shown below:
  • target industrial networks may including software’s version in the target industrial network
  • the above item (4) target industrial networks indicates the target industrial network the patch 30 is designed for. This item may also include information of software’s version and other information of the target industrial network.
  • the first apparatus 10 may expect that the patch 30 can be applicable for many industries and vendors of industrial networks, so in the first request, with the above items (5) and (6) , the first apparatus 10 indicates industries and vendors it expects to verify the patch 30.
  • the first apparatus 10 may already have the patch 30 verified by multiple second apparatuses 20 for multiple industrial networks 40.
  • the verification result may include for what industry, what vendor the patch 30 can be deployed in.
  • the verification result may also include for what industry, what vendor the patch 30 cannot be deployed in.
  • the verification results can be added into a blockchain for sharing among the at least one second apparatus 20.
  • the first apparatus 10 When the first apparatus 10 generates a new first request, it can get the verification results from the blockchain and enclose them in the first request.
  • the purpose of enclosing these items in the first request is for the second apparatus 20 to make decision on whether the patch 30 can be deployed in the supervised industrial network 40.
  • the receiver can refer to the available verification results and try to decide whether the patch 30 can be applied in the supervised industrial network 40. Of course, if there is no available verification result, the generated first request will not include such information.
  • S204 sending the first request, to the second apparatus 20 by the first apparatus 10.
  • the first apparatus 10 can send the first request directly to each second apparatus 20.
  • the first apparatus 10 can issue the first request, each second apparatus 20 periodically query the first request.
  • the second apparatus 20 may check whether the first request is valid. For example, the second apparatus 20 may check validity of the first apparatus 10, fields in the first request and/or integrity of the first request. The second apparatus 20 may also check whether “ (4) target industrial network that the patch is to be deployed in ” matches the supervised industrial network 40. Optionally, if the first request is valid and the target industrial network can match the supervised industrial network 40, the procedure will proceed to next steps, otherwise the procedure will be finished, the second apparatus 20 may reply to the first apparatus 10, indicating that the first request is invalid and/or the target industrial network does not match the supervised industrial network 40.
  • the second apparatus 20 can query in what kind of industrial networks the new issued patch 30 has been verified to be deployed via following steps S206 ⁇ S211.
  • each second verification result indicates a specific industry and a specific vendor of the industrial network a patch can be deployed.
  • a second verification result can also indicate a specific industry and a specific vendor of the industrial network in which a patch cannot be deployed.
  • step S209 determining by the second apparatus 20 if any of the at least one second verification result can indicate whether the new issued patch 30 can be deployed in the supervised industrial network 40. If a specific second verification result can indicate, the procedure will proceed to step S210; if none of the at least one second verification result can indicate, the procedure will proceed to step S211 ⁇ S216.
  • a second verification result indicates that the new issued patch 20 can be deployed in chemistry related industrial networks and the vendor of the industrial networks is vendor A.
  • the supervised industrial network 40 is also a chemistry related one, the vendor is also vendor A, the second apparatus 20 then can decide the new issued patch 30 can be deployed.
  • the second apparatus 20 can also run a test on the new issued patch 30 in such circumstances to ensure the new issued patch 30 can be deployed.
  • S210 sending by the second apparatus 20, to the first apparatus 10, a usage result indicating that the second apparatus 20 uses the specific second verification result .
  • the second apparatus 20 can build the simulated environment in one of following three ways. To be noted that, following three ways are just examples, they should not be considered as restriction on scope of the present disclosure.
  • the second apparatus 20 can get information of the supervised industrial network 40, which may include: information of configuration of the supervised industrial network, running processes or installed software in the supervised industrial network 40. Then the simulated environment can be built up, the patch 30 can be downloaded to the simulated environment.
  • the second apparatus 20 will monitor the status of the simulated environment, such as status of key processes and software. For example, following performance can be evaluated:
  • the second apparatus 20 can decide that the patch 30 can be deployed in the supervised industrial network 40.
  • the second apparatus 20 can build the simulated environment based on the backup image of the supervised industrial network 40 and monitor the status of the backup image after installing the patch 30.
  • the second apparatus 20 can decide that the new issued patch 20 can be deployed.
  • the patch 30 can also be installed in the backup host or network for test.
  • the backup host or network for test.
  • the patch 30 can also be installed in the backup host or network for test.
  • a distributed control system generally there are multiple engineering stations or operation stations, one of them can be chosen as the simulated environment.
  • S212 testing the new issued patch 30 by the second apparatus 20 to generate a first verification result indicating whether the patch 30 can be deployed in the supervised industrial network 40.
  • the second apparatus 20 can monitor the status of the simulated environment, if during the verification period, the status of the key processes and software is normal, the second apparatus 20 can decide that the patch 30 can be deployed in the supervised industrial network 40, otherwise, the second apparatus 20 can decide that the patch cannot be deployed in the supervised industrial network 40.
  • S215 setting by the first apparatus 10 trust level of the second apparatus 20 indicating to what extent verification results it submitted can be trusted.
  • the first apparatus 10 can set trust level of each second apparatus 20 based on:
  • the second apparatuses 20 who submit verification results, they can get higher trust levels and the trust levels can be labelled to the verification results they submitted.
  • the initial trust level of each second apparatus 20 can be zero, after it submits one verification result, the number of the verification results it submits can be recorded. The number of usages of the verification results by other second apparatuses 20 can also be recorded.
  • the trust level of a second apparatus 20 can be calculated with the percentage of the number of the normal usage result divided by the total number usage. The total number usage is equal to the number of the normal usage result plus the number of the usage result has problem.
  • FIG. 3 depicts a block diagram of a first apparatus 10 for software updating in an industrial network in accordance with one embodiment of the present disclosure.
  • the apparatus 10 for software updating in an industrial network presented in the present disclosure can be implemented as a network of computer processors, to execute above-mentioned method 200 at the side of the first apparatus 10 presented in the present disclosure.
  • the apparatus 10 can also be a single computer, as shown in FIG. 3, including at least one memory 102, which includes computer-readable medium, such as a random access memory (RAM) .
  • the apparatus 10 also includes at least one processor 101, coupled with the at least one memory 102.
  • Computer-executable instructions are stored in the at least one memory 102, and when executed by the at least one processor 101, can cause the at least one processor 101 to perform the steps described herein.
  • the at least one processor 101 may include a microprocessor, an application specific integrated circuit (ASIC) , a digital signal processor (DSP) , a central processing unit (CPU) , a graphics processing unit (GPU) , state machines, etc.
  • embodiments of computer-readable medium include, but not limited to a floppy disk, CD-ROM, magnetic disk, memory chip, ROM, RAM, an ASIC, a configured processor, all optical media, all magnetic tape or other magnetic media, or any other medium from which a computer processor can read instructions.
  • various other forms of computer-readable medium may transmit or carry instructions to a computer, including a router, private or public network, or other transmission device or channel, both wired and wireless.
  • the instructions may include code from any computer-programming language, including, for example, C, C++, C#, Visual Basic, Java, and JavaScript.
  • the at least one memory 102 shown in FIG. 3 can contain a software updating program 11, when executed by the at least one processor 101, causing the at least one processor 101 to execute the method 200 at the side of the first apparatus 10.
  • Data of blockchain 12 can also be stored in the at least one memory 102. These data can be received via a communication module 105 of the apparatus 10.
  • the software updating program 11 can include:
  • a sending module 111 configured to send to a second apparatus 20, a first request to verify whether a new issued patch 30 can be deployed in an industrial network 40 supervised by the second apparatus;
  • a receiving module 112 configured to receive from the second apparatus 20, a first verification result indicating whether the new issued patch 30 can be deployed in the industrial network 40, wherein the first verification result is based on a test of the new issued patch 30 in a simulated environment of the industrial network 40 via the second apparatus 20;
  • processing module 113 configured to add the first verification result into a blockchain.
  • the simulated environment of the industrial network 40 is:
  • the sending module 111 is further configured to: before the receiving module 112 receives the first verification result, receive from the second apparatus 20, a second request to query in what kind of industrial networks the new issued patch 30 has been verified to be deployed; the processing module 113 is further configured to get from the blockchain, at least one second verification result indicating in what kind of industrial networks the new issued patch 30 has been verified to be deployed; the sending module 112 is further configured to send to the second apparatus 20, the at least one second verification result; the receiving module 111 is further configured to: when receiving the first verification result, receiving, from the second apparatus 30, the first verification result, if none of the at least one second verification result can indicate whether the new issued patch 30 can be deployed in the industrial network 40.
  • the receiving module 111 is further configured to: receive, from the second apparatus 20, a usage result indicating that the second apparatus 20 uses a specific second verification result of the at least one second verification result, if the specific second verification result can indicate whether the new issued patch 30 can be deployed in the industrial network 40 .
  • the processing module 113 is further configured to: set trust level of the second apparatus 20 based on a first number of verification results submitted by the second apparatus 20 and a second number of normal usage results submitted by other second apparatuses 20 indicating that verification results submitted by the second apparatus 20 are used by other second apparatuses 20 and verified to be right; label the first verification result with the trust level of the second apparatus 20.
  • modules 111, 112, 113 are described above as software modules of the software updating program 11. Also, they can be implemented via hardware, such as ASIC chips. They can be integrated into one chip, or separately implemented and electrically connected.
  • FIG. 3 The architecture above is merely exemplary and used to explain the exemplary method 200 shown in FIG. 2.
  • FIG. 4 depicts a block diagram of a second apparatus 20 for software updating in an industrial network in accordance with one embodiment of the present disclosure.
  • the apparatus 20 for software updating in an industrial network presented in the present disclosure can be implemented as a network of computer processors, to execute above-mentioned method 200 at the side of the second apparatus 20 presented in the present disclosure.
  • the apparatus 20 can also be a single computer, as shown in FIG. 4, including at least one memory 202, which includes computer-readable medium, such as a random access memory (RAM) .
  • the apparatus 20 also includes at least one processor 201, coupled with the at least one memory 202.
  • Computer-executable instructions are stored in the at least one memory 202, and when executed by the at least one processor 201, can cause the at least one processor 201 to perform the steps described herein.
  • the at least one processor 201 may include a microprocessor, an application specific integrated circuit (ASIC) , a digital signal processor (DSP) , a central processing unit (CPU) , a graphics processing unit (GPU) , state machines, etc.
  • embodiments of computer-readable medium include, but not limited to a floppy disk, CD-ROM, magnetic disk, memory chip, ROM, RAM, an ASIC, a configured processor, all optical media, all magnetic tape or other magnetic media, or any other medium from which a computer processor can read instructions.
  • various other forms of computer-readable medium may transmit or carry instructions to a computer, including a router, private or public network, or other transmission device or channel, both wired and wireless.
  • the instructions may include code from any computer-programming language, including, for example, C, C++, C#, Visual Basic, Java, and JavaScript.
  • the at least one memory 202 shown in FIG. 4 can contain a software updating program 21, when executed by the at least one processor 201, causing the at least one processor 201 to execute the method 200 at the side of the second apparatus 20.
  • the software updating program 21 can include:
  • a receiving module 211 configure to receive from a first apparatus 10, a first request to verify whether a new issued patch 30 can be deployed in an industrial network 40 supervised by the second apparatus 20;
  • a processing module 212 configured to build up a simulated environment of the industrial network 40 and test the new issued patch 30 in the simulated environment to generate a first verification result indicating whether the new issued patch 30 can be deployed in the industrial network 40;
  • a sending module 213, configured to send to the first apparatus 10, the first verification result, for the first apparatus 10 to add into a blockchain.
  • the simulated environment of the industrial network 40 is:
  • the sending module 213 is further configured to: before the processing module 212 tests the new issued patch 20, send to the first apparatus 10, a second request to query in what kind of industrial networks the new issued patch 30 has been verified to be deployed; the receiving module 211 is further configured to receive, from the first apparatus 10, at least one second verification result indicating in what kind of industrial networks the new issued patch 30 has been verified to be deployed; the processing module 212 is further configured to: when testing the new issued patch 20, test the new issued patch 20 if the none of at least one second verification result can indicate whether the new issued patch 30 can be deployed in the industrial network 40.
  • the sending module 213 is further configured to: send to the first apparatus 10, a usage result indicating that the second apparatus 20 uses a specific verification result of the at least one second verification result, if the specific second verification result can indicate whether the new issued patch 30 can be deployed in the industrial network 40 .
  • the first verification result is labelled with the trust level of the second apparatus 20 based on a first number of verification results submitted by the second apparatus 20 and a second number of normal usage results submitted by other second apparatuses 20 indicating that verification results submitted by the second apparatus 20 are used by other second apparatuses 20 and verified to be right.
  • modules 211, 212, 213 are described above as software modules of the software updating program 21. Also, they can be implemented via hardware, such as ASIC chips. They can be integrated into one chip, or separately implemented and electrically connected.
  • the second apparatus 20 can also include a communication module 203, configured to communication with the first apparatus 10 and in the supervised industrial network 40. It should be mentioned that the present disclosure may include apparatuses having different architecture than shown in FIG. 4. The architecture above is merely exemplary and used to explain the exemplary method 200 shown in FIG. 2.
  • a computer-readable medium is also provided in the present disclosure, storing computer-executable instructions, which upon execution by a computer, enables the computer to execute any of the methods presented in this disclosure.
  • a computer program which is being executed by at least one processor and performs any of the methods presented in this disclosure.

Abstract

A method, apparatus, system and computer-readable medium for software updating in an industrial network are presented. A method (200) for software updating in an industrial network (40), executed by a first apparatus (10), including sending, to a second apparatus (20), a first request to verify whether a new issued patch (30) can be deployed in an industrial network (40) supervised by the second apparatus; receiving, from the second apparatus (20), a first verification result indicating whether the new issued patch (30) can be deployed in the industrial network (40), wherein the first verification result is based on a test of the new issued patch (30) in a simulated environment of the industrial network (40) via the second apparatus (20); adding the first verification result into a blockchain.

Description

Method, apparatus and system for software updating in an industrial network Technical Field
The present invention relates to security technology, and more particularly to a method, apparatus, system and computer-readable storage medium for software updating in an industrial network.
Background Art
With development of digitalization technology in OT (Operational Technology) area, more industrial networks are connected to IT (Information Technology) and other enterprise networks. Possibility of industrial networks’ exposure to various attacks becomes higher. For devices in critical industrial networks, cyber security protective measures become essential, and regular software updating industrial networks is also necessary.
Software updating (such as patch updating) plays key role for security of industrial devices, providing various upgrade and security vulnerability fixing. Traditionally, for example, in IT environment, a patch can be delivered to a target device online and the patch will be automatically updated in the device. But in OT environment, software has strict requirement of compatibility and updating. Not having strict testing may cause running anomaly of industrial devices.
To avoid software updating causing running anomaly, some industrial control system providers make the central patch testing mechanism in a simulation environment. During testing, compatibility between new software patch and current software will be checked. But it is difficult to simulate all real OT environments in different industry networks. Compatibility has to be checked many times when a new patch is issued which may cause great threat and risk to stability of the production process.
Summary of the Invention
In present disclosure, a method, apparatus, system and computer-readable storage medium are provided.
A system for software updating in an industrial network can include a first apparatus and at least one second apparatus, each second apparatus supervising an industrial network, wherein, the first apparatus can send to a second apparatus a  first request to verify whether a new issued patch can be deployed in an industrial network supervised by the second apparatus; the second apparatus receives from the first apparatus the first request, tests the new issued patch in a simulated environment of the industrial network to generate a first verification result indicating whether the new issued patch can be deployed in the industrial network, and sends to the first apparatus the first verification result; the first apparatus receives from the second apparatus the first verification result, and adds the first verification result into a blockchain.
With solutions provided in the present disclosure, distributed verification for software updating and testing in an industrial network is proposed to generate simulated industrial environment and make the patch testing, the testing result is shared in a blockchain, then industrial networks can share the test result. The distributed verification can speed up the process of verification of the latest patch. Also, the block chain-based software updating mechanism can provide the de-centralized management of patch verification request and verification process, it reduces the cost of the patch verification. The block chain-based software updating mechanism can also provide the feature of tamper proof and trust-based result management, this can assure the verification result of patch is valid and trusty. Furthermore, the verification result is based on a simulated environment of real industrial networks, which means that the result will be more accurate and more compatible with the target industrial network.
Optionally, the simulated environment of the industrial network can be:
- a virtual environment built up based on information of configuration of the industrial network , running processes and installed software in the industrial network ; or
- a backup image of the industrial network; or
- a physical backup of the industrial network; or
- a physical backup of a host in the industrial network.
The simulated environment is built up based on real industrial network, which makes the testing result be more precise.
Optionally, before testing the new issued patch, the second apparatus can send to the first apparatus a second request to query in what kind of industrial networks the new issued patch has been verified to be deployed; the first apparatus can get from the blockchain at least one second verification result indicating in what kind of industrial networks the new issued patch has been verified to be deployed and send to the second apparatus, the at least one second verification result; if none of at  least one second verification result can indicate whether the new issued patch can be deployed in the industrial network the second apparatus will test the new issued patch.
Before running the test, the second apparatus can query in what kind of industrial networks the new issued patch has been verified to be deployed, and decide based on the available information whether it is necessary to run the test, with shared information in the blockchain, repeated testing can be avoided, which saves time and improve efficiency.
Optionally, if a specific second verification result can indicate whether the new issued patch can be deployed in the industrial network, the second apparatus can send to the first apparatus a usage result indicating that the second apparatus uses a specific verification result of the at least one second verification result. The first apparatus can set trust level of the second apparatus based on a first number of verification results submitted by the second apparatus and a second number of normal usage results submitted by other second apparatuses indicating that verification results submitted by the second apparatus are used by other second apparatuses and verified to be right; and label the first verification result with the trust level of the second apparatus.
The trust level can be a reference for other second apparatus to decide whether to use available verification results or run a test on its own.
Brief Description of the Drawings
The above-mentioned attributes and other features and advantages of the present technique and the manner of attaining them will become more apparent and the present technique itself will be better understood by reference to the following description of embodiments of the present technique taken in conjunction with the accompanying drawings, wherein:
FIG. 1 depicts a system for software updating in an industrial network.
FIG. 2 depicts a flow diagram of a method for software updating in an industrial network in accordance with one embodiment of the present disclosure.
FIG. 3 depicts a block diagram of a first apparatus for software updating in an industrial network in accordance with one embodiment of the present disclosure.
FIG. 4 depicts a block diagram of a second apparatus for software updating in an industrial network in accordance with one embodiment of the present disclosure.
Reference Numbers:
100, a system for software updating in an industrial network
10, a first apparatus for software updating in an industrial network
20, a second apparatus for software updating in an industrial network
30, a new issued patch
40, industrial networks in which the new issued patch 30 may be installed
200, a method for software updating in an industrial network
S201～S216, steps of method 200
11, a software updating program at the first apparatus 10’s side
12, blockchain
101, at least one processor
102, at least one memory
103, a communication module
111, a sending module
112, a receiving module
113, a processing module
21, a software updating program at the second apparatus 20’s side
201, at least one processor
202, at least one memory
203, a communication module
211, a receiving module
212, a processing module
213, a sending module
Detailed Description of Example Embodiments
Hereinafter, above-mentioned and other features of the present technique are described in detail. Various embodiments are described with reference to the drawing, where like reference numerals are used to refer to like elements throughout. In the following description, for purpose of explanation, numerous specific details are set forth in order to provide a thorough understanding of one or more embodiments. It may be noted that the illustrated embodiments are intended to explain, and not to limit the invention. It may be evident that such embodiments may be practiced without these specific details.
When introducing elements of various embodiments of the present disclosure, the articles “a” , “an” , “the” and “said” are intended to mean that there are one or more of the elements. The terms “comprising” , “including” and “having” are  intended to be inclusive and mean that there may be additional elements other than the listed elements.
Now the present disclosure will be described hereinafter in details by referring to FIG. 1 to FIG. 4.
FIG. 1 depicts a system for software updating in an industrial network. As shown in FIG. 1, the system 100 can include: a first apparatus 10 and at least one second apparatus 20, each second apparatus corresponding to an industrial network 40, configured to executing patch verification for the corresponding industrial network 40. In order to make the description concise, we call an industrial network 40 “a supervised industrial network 40” .
The first apparatus 10 can be deployed in a cloud environment, which provides high availability for software updating status monitoring, distributed software updating verification management and sharing test results.
The second apparatuses 20 can be deployed locally on sites of industrial networks 40. It can be deployed in IT or OT environment. For example, a second apparatus 20 can be deployed in a server in an industrial network 40 it supervises.
The first apparatus 10 can monitor the software updating status, for example it can communicate with a patch center. When there is a new issued patch 30, the software updating procedure in the present disclosure can be triggered.
The first apparatus 10 can be configured to request all or part of the at least one second apparatus 20 to verify whether a new issued patch 30 can be deployed in industrial networks 40. A second apparatus 20 can be configured to test the patch 30 in a simulated environment of the supervised industrial network 40 and generate verification result. The first apparatus 10 can add received verification results into a blockchain for further sharing. A second apparatus 20 can get information of the supervised industrial network 40 (such as system configuration, key processes and software) to build up a simulated environment of the industrial network 40. The simulated environment can contain same hardware and software configuration. The patch 30 can be downloaded and installed in the simulated environment, and then the second apparatus 20 can run a test (preferable for a preset period) . Verification result can be generated based on the status of simulated environment and sent to the first apparatus 10, the first apparatus 10 can add the verification result into a blockchain.
Details of functions and processing of the first apparatus 10 and the at least one second apparatus will be described in combination with FIG. 2.
FIG. 2 depicts a flow diagram of a method for software updating in an industrial network in accordance with one embodiment of the present disclosure. As shown in FIG. 2, the method 200 can include following steps:
S201: monitoring software updating status by the first apparatus 10.
The first apparatus 10 can communicate with a patch center, once there is a new issued patch, the first apparatus 10 can detect it and trigger following steps.
S202: getting information of the new issued patch 30 by the first apparatus 10.
Optionally, the first apparatus 10 can get information of the new issued patch 30, which can include at least one of the following items:
(1) patch name
(2) patch version
(3) vendor name of the patch
(4) target industrial network (may including software’s version in the target industrial network -) that the patch is to be deployed in
S203: the first apparatus 20 can generate a first request for verification of the new issued patch 30. The first request can include above information of the new issued patch 30 and optionally other information as shown below:
(1) patch name
(2) patch version
(3) vendor name of the patch
(4) target industrial networks (may including software’s version in the target industrial network) that the patch is to be deployed in
(5) what industry does the patch need to be verified
(6) what vendor’s industrial network does the patch need to be verified
(7) verified period requirement
(8) industry and vendor (industrial network’s vendor) have been verified that the patch can be deployed in
(9) industry or vendor (industrial network’s vendor) has been verified that the patch cannot be deployed in
The above item (4) target industrial networks indicates the target industrial network the patch 30 is designed for. This item may also include information of software’s version and other information of the target industrial network. The first apparatus 10 may expect that the patch 30 can be applicable for many industries and vendors of industrial networks, so in the first request, with the above items (5) and (6) , the first apparatus 10 indicates industries and vendors it expects to verify the  patch 30.
The first apparatus 10 may already have the patch 30 verified by multiple second apparatuses 20 for multiple industrial networks 40. The verification result may include for what industry, what vendor the patch 30 can be deployed in. the verification result may also include for what industry, what vendor the patch 30 cannot be deployed in. As above mentioned, the verification results can be added into a blockchain for sharing among the at least one second apparatus 20. When the first apparatus 10 generates a new first request, it can get the verification results from the blockchain and enclose them in the first request. The purpose of enclosing these items in the first request is for the second apparatus 20 to make decision on whether the patch 30 can be deployed in the supervised industrial network 40. Once the first request is received by a second apparatus 20, the receiver can refer to the available verification results and try to decide whether the patch 30 can be applied in the supervised industrial network 40. Of course, if there is no available verification result, the generated first request will not include such information.
S204: sending the first request, to the second apparatus 20 by the first apparatus 10. The first apparatus 10 can send the first request directly to each second apparatus 20. Or the first apparatus 10 can issue the first request, each second apparatus 20 periodically query the first request.
S205: checking the first request by the second apparatus 20.
Optionally, the second apparatus 20 may check whether the first request is valid. For example, the second apparatus 20 may check validity of the first apparatus 10, fields in the first request and/or integrity of the first request. The second apparatus 20 may also check whether “ (4) target industrial network that the patch is to be deployed in ” matches the supervised industrial network 40. Optionally, if the first request is valid and the target industrial network can match the supervised industrial network 40, the procedure will proceed to next steps, otherwise the procedure will be finished, the second apparatus 20 may reply to the first apparatus 10, indicating that the first request is invalid and/or the target industrial network does not match the supervised industrial network 40.
Optionally, if there is no above item (8) or (9) , the second apparatus 20 can query in what kind of industrial networks the new issued patch 30 has been verified to be deployed via following steps S206～S211.
S206: sending by the second apparatus 20, to the first apparatus 10, a second request to query in what kind of industrial networks the new issued patch 30 has been verified to be deployed.
S207: getting by the first apparatus 10, from the blockchain, at least one second verification result indicating in what kind of industrial networks the new issued patch 30 has been verified to be deployed. For there may be some other second apparatuses 20 which have sent to the first apparatus 10 verification results, and the first apparatus 10 have added into the blockchain, when the first apparatus 10 receives the second request, it can get the at least one second verification result from the blockchain. For example, each second verification result indicates a specific industry and a specific vendor of the industrial network a patch can be deployed. Optionally, a second verification result can also indicate a specific industry and a specific vendor of the industrial network in which a patch cannot be deployed.
S208: sending by the first apparatus 10, the at least one second verification result to the second apparatus 20.
S209: determining by the second apparatus 20 if any of the at least one second verification result can indicate whether the new issued patch 30 can be deployed in the supervised industrial network 40. If a specific second verification result can indicate, the procedure will proceed to step S210; if none of the at least one second verification result can indicate, the procedure will proceed to step S211～S216.
For example, a second verification result indicates that the new issued patch 20 can be deployed in chemistry related industrial networks and the vendor of the industrial networks is vendor A. The supervised industrial network 40 is also a chemistry related one, the vendor is also vendor A, the second apparatus 20 then can decide the new issued patch 30 can be deployed. Of course, depending on different preset strategies, the second apparatus 20 can also run a test on the new issued patch 30 in such circumstances to ensure the new issued patch 30 can be deployed.
S210: sending by the second apparatus 20, to the first apparatus 10, a usage result indicating that the second apparatus 20 uses the specific second verification result .
S211: building up a simulated environment of the supervised industrial network 40 by the second apparatus 20.
Optionally, the second apparatus 20 can build the simulated environment in one of following three ways. To be noted that, following three ways are just examples, they should not be considered as restriction on scope of the present disclosure.
Example 1:
If the supervised industrial network 40 does not depend on USB license or any  hardware license, the second apparatus 20 can get information of the supervised industrial network 40, which may include: information of configuration of the supervised industrial network, running processes or installed software in the supervised industrial network 40. Then the simulated environment can be built up, the patch 30 can be downloaded to the simulated environment.
After the patch 30 is downloaded and installed in the simulated environment, the second apparatus 20 will monitor the status of the simulated environment, such as status of key processes and software. For example, following performance can be evaluated:
(1) CPU occupied rate and system RAM and hard disk occupied rate.
(2) Network communication port conflicted.
(3) Log about the key process
(4) Do the key processes or software restart?
If during the verification period (specified in the first request) , the status of the key processes and software is normal, the second apparatus 20 can decide that the patch 30 can be deployed in the supervised industrial network 40.
Example 2
The second apparatus 20 can build the simulated environment based on the backup image of the supervised industrial network 40 and monitor the status of the backup image after installing the patch 30.
If the running status of key processes and software is normal, the second apparatus 20 can decide that the new issued patch 20 can be deployed.
Example 3:
If there is real physical backup industrial network or host in the supervised industrial network 40, the patch 30 can also be installed in the backup host or network for test. For example, in a distributed control system, generally there are multiple engineering stations or operation stations, one of them can be chosen as the simulated environment.
S212: testing the new issued patch 30 by the second apparatus 20 to generate a first verification result indicating whether the patch 30 can be deployed in the supervised industrial network 40.
As mentioned above, the second apparatus 20 can monitor the status of the simulated environment, if during the verification period, the status of the key processes and software is normal, the second apparatus 20 can decide that the patch 30 can be deployed in the supervised industrial network 40, otherwise, the second apparatus 20 can decide that the patch cannot be deployed in the supervised  industrial network 40.
S213: sending by the second apparatus 20 the first verification result to the first apparatus 10.
S214: adding the first verification result by the first apparatus 10 into the above mentioned blockchain.
S215: setting by the first apparatus 10 trust level of the second apparatus 20 indicating to what extent verification results it submitted can be trusted.
Optionally, the first apparatus 10 can set trust level of each second apparatus 20 based on:
- a first number of verification results by the respective second apparatus 20 indicating whether new issued patches can be deployed in the industrial network 40, and
- a second number of normal usage results submitted by other second apparatuses 20 indicating that verification results submitted by the respective second apparatus 20 are used by other second apparatuses 20 and verified to be right.
For the second apparatuses 20 who submit verification results, they can get higher trust levels and the trust levels can be labelled to the verification results they submitted. For example, the initial trust level of each second apparatus 20 can be zero, after it submits one verification result, the number of the verification results it submits can be recorded. The number of usages of the verification results by other second apparatuses 20 can also be recorded. For example, the trust level of a second apparatus 20 can be calculated with the percentage of the number of the normal usage result divided by the total number usage. The total number usage is equal to the number of the normal usage result plus the number of the usage result has problem.
S216: labelling the first verification result with the trust level of the second apparatus (20) .
FIG. 3 depicts a block diagram of a first apparatus 10 for software updating in an industrial network in accordance with one embodiment of the present disclosure. The apparatus 10 for software updating in an industrial network presented in the present disclosure can be implemented as a network of computer processors, to execute above-mentioned method 200 at the side of the first apparatus 10 presented in the present disclosure. the apparatus 10 can also be a single computer, as shown in FIG. 3, including at least one memory 102, which includes computer-readable  medium, such as a random access memory (RAM) . The apparatus 10 also includes at least one processor 101, coupled with the at least one memory 102. Computer-executable instructions are stored in the at least one memory 102, and when executed by the at least one processor 101, can cause the at least one processor 101 to perform the steps described herein. The at least one processor 101 may include a microprocessor, an application specific integrated circuit (ASIC) , a digital signal processor (DSP) , a central processing unit (CPU) , a graphics processing unit (GPU) , state machines, etc. embodiments of computer-readable medium include, but not limited to a floppy disk, CD-ROM, magnetic disk, memory chip, ROM, RAM, an ASIC, a configured processor, all optical media, all magnetic tape or other magnetic media, or any other medium from which a computer processor can read instructions. Also, various other forms of computer-readable medium may transmit or carry instructions to a computer, including a router, private or public network, or other transmission device or channel, both wired and wireless. The instructions may include code from any computer-programming language, including, for example, C, C++, C#, Visual Basic, Java, and JavaScript.
The at least one memory 102 shown in FIG. 3 can contain a software updating program 11, when executed by the at least one processor 101, causing the at least one processor 101 to execute the method 200 at the side of the first apparatus 10. Data of blockchain 12 can also be stored in the at least one memory 102. These data can be received via a communication module 105 of the apparatus 10.
The software updating program 11 can include:
- a sending module 111, configured to send to a second apparatus 20, a first request to verify whether a new issued patch 30 can be deployed in an industrial network 40 supervised by the second apparatus;
- a receiving module 112, configured to receive from the second apparatus 20, a first verification result indicating whether the new issued patch 30 can be deployed in the industrial network 40, wherein the first verification result is based on a test of the new issued patch 30 in a simulated environment of the industrial network 40 via the second apparatus 20;
- a processing module 113, configured to add the first verification result into a blockchain.
Optionally, the simulated environment of the industrial network 40 is:
- a virtual environment built up based on information of configuration of the industrial network 40, running processes and installed software in the industrial network 40; or
- a backup image of the industrial network 40; or
- a physical backup of the industrial network 40; or
- a physical backup of a host in the industrial network 40.
Optionally, the sending module 111 is further configured to: before the receiving module 112 receives the first verification result, receive from the second apparatus 20, a second request to query in what kind of industrial networks the new issued patch 30 has been verified to be deployed; the processing module 113 is further configured to get from the blockchain, at least one second verification result indicating in what kind of industrial networks the new issued patch 30 has been verified to be deployed; the sending module 112 is further configured to send to the second apparatus 20, the at least one second verification result; the receiving module 111 is further configured to: when receiving the first verification result, receiving, from the second apparatus 30, the first verification result, if none of the at least one second verification result can indicate whether the new issued patch 30 can be deployed in the industrial network 40.
Optionally, the receiving module 111 is further configured to: receive, from the second apparatus 20, a usage result indicating that the second apparatus 20 uses a specific second verification result of the at least one second verification result, if the specific second verification result can indicate whether the new issued patch 30 can be deployed in the industrial network 40 .
Optionally, the processing module 113 is further configured to: set trust level of the second apparatus 20 based on a first number of verification results submitted by the second apparatus 20 and a second number of normal usage results submitted by other second apparatuses 20 indicating that verification results submitted by the second apparatus 20 are used by other second apparatuses 20 and verified to be right; label the first verification result with the trust level of the second apparatus 20.
Although the  modules  111, 112, 113 are described above as software modules of the software updating program 11. Also, they can be implemented via hardware, such as ASIC chips. They can be integrated into one chip, or separately implemented and electrically connected.
It should be mentioned that the present disclosure may include apparatuses having different architecture than shown in FIG. 3. The architecture above is merely exemplary and used to explain the exemplary method 200 shown in FIG. 2.
FIG. 4 depicts a block diagram of a second apparatus 20 for software updating in  an industrial network in accordance with one embodiment of the present disclosure.
The apparatus 20 for software updating in an industrial network presented in the present disclosure can be implemented as a network of computer processors, to execute above-mentioned method 200 at the side of the second apparatus 20 presented in the present disclosure. the apparatus 20 can also be a single computer, as shown in FIG. 4, including at least one memory 202, which includes computer-readable medium, such as a random access memory (RAM) . The apparatus 20 also includes at least one processor 201, coupled with the at least one memory 202. Computer-executable instructions are stored in the at least one memory 202, and when executed by the at least one processor 201, can cause the at least one processor 201 to perform the steps described herein. The at least one processor 201 may include a microprocessor, an application specific integrated circuit (ASIC) , a digital signal processor (DSP) , a central processing unit (CPU) , a graphics processing unit (GPU) , state machines, etc. embodiments of computer-readable medium include, but not limited to a floppy disk, CD-ROM, magnetic disk, memory chip, ROM, RAM, an ASIC, a configured processor, all optical media, all magnetic tape or other magnetic media, or any other medium from which a computer processor can read instructions. Also, various other forms of computer-readable medium may transmit or carry instructions to a computer, including a router, private or public network, or other transmission device or channel, both wired and wireless. The instructions may include code from any computer-programming language, including, for example, C, C++, C#, Visual Basic, Java, and JavaScript.
The at least one memory 202 shown in FIG. 4 can contain a software updating program 21, when executed by the at least one processor 201, causing the at least one processor 201 to execute the method 200 at the side of the second apparatus 20.
The software updating program 21 can include:
- a receiving module 211, configure to receive from a first apparatus 10, a first request to verify whether a new issued patch 30 can be deployed in an industrial network 40 supervised by the second apparatus 20;
- a processing module 212, configured to build up a simulated environment of the industrial network 40 and test the new issued patch 30 in the simulated environment to generate a first verification result indicating whether the new issued patch 30 can be deployed in the industrial network 40;
- a sending module 213, configured to send to the first apparatus 10, the first verification result, for the first apparatus 10 to add into a blockchain.
Optionally, the simulated environment of the industrial network 40 is:
- a virtual environment built up based on information of configuration of the industrial network 40, running processes and installed software in the industrial network 40; or
- a backup image of the industrial network 40; or
- a physical backup of the industrial network 40; or
- a physical backup of a host in the industrial network 40.
Optionally, the sending module 213 is further configured to: before the processing module 212 tests the new issued patch 20, send to the first apparatus 10, a second request to query in what kind of industrial networks the new issued patch 30 has been verified to be deployed; the receiving module 211 is further configured to receive, from the first apparatus 10, at least one second verification result indicating in what kind of industrial networks the new issued patch 30 has been verified to be deployed; the processing module 212 is further configured to: when testing the new issued patch 20, test the new issued patch 20 if the none of at least one second verification result can indicate whether the new issued patch 30 can be deployed in the industrial network 40.
Optionally, the sending module 213 is further configured to: send to the first apparatus 10, a usage result indicating that the second apparatus 20 uses a specific verification result of the at least one second verification result, if the specific second verification result can indicate whether the new issued patch 30 can be deployed in the industrial network 40 .
Optionally, the first verification result is labelled with the trust level of the second apparatus 20 based on a first number of verification results submitted by the second apparatus 20 and a second number of normal usage results submitted by other second apparatuses 20 indicating that verification results submitted by the second apparatus 20 are used by other second apparatuses 20 and verified to be right.
Although the  modules  211, 212, 213 are described above as software modules of the software updating program 21. Also, they can be implemented via hardware, such as ASIC chips. They can be integrated into one chip, or separately implemented and electrically connected.
The second apparatus 20 can also include a communication module 203, configured to communication with the first apparatus 10 and in the supervised industrial network 40. It should be mentioned that the present disclosure may include apparatuses having different architecture than shown in FIG. 4. The  architecture above is merely exemplary and used to explain the exemplary method 200 shown in FIG. 2.
A computer-readable medium is also provided in the present disclosure, storing computer-executable instructions, which upon execution by a computer, enables the computer to execute any of the methods presented in this disclosure.
A computer program, which is being executed by at least one processor and performs any of the methods presented in this disclosure.
While the present technique has been described in detail with reference to certain embodiments, it should be appreciated that the present technique is not limited to those precise embodiments. Rather, in view of the present disclosure which describes exemplary modes for practicing the invention, many modifications and variations would present themselves, to those skilled in the art without departing from the scope and spirit of this invention. The scope of the invention is, therefore, indicated by the following claims rather than by the foregoing description. All changes, modifications, and variations coming within the meaning and range of equivalency of the claims are to be considered within their scope.

Claims (15)

  1. A method (200) for software updating in an industrial network (40) , executed by a first apparatus (10) , comprising:
    - sending (S204) , to a second apparatus (20) , a first request to verify whether a new issued patch (30) can be deployed in an industrial network (40) supervised by the second apparatus;
    - receiving (S213) , from the second apparatus (20) , a first verification result indicating whether the new issued patch (30) can be deployed in the industrial network (40) , wherein the first verification result is based on a test of the new issued patch (30) in a simulated environment of the industrial network (40) via the second apparatus (20) ;
    - adding (S214) the first verification result into a blockchain.
  2. the method (200) according to claim 1, wherein the simulated environment of the industrial network (40) is:
    - a virtual environment built up based on information of configuration of the industrial network (40) , running processes and installed software in the industrial network (40) ; or
    - a backup image of the industrial network (40) ; or
    - a physical backup of the industrial network (40) ; or
    - a physical backup of a host in the industrial network (40) .
  3. the method (200) according to claim 1,
    - after sending (S204) the first request, the method further comprises:
    - receiving (S206) , from the second apparatus (20) , a second request to query in what kind of industrial networks the new issued patch (30) has been verified to be deployed;
    - getting (S207) , from the blockchain, at least one second verification result indicating in what kind of industrial networks the new issued patch (30) has been verified to be deployed;
    - sending (S208) , to the second apparatus (20) , the at least one second verification result;
    - receiving (S213) the first verification result further comprises: receiving, from the second apparatus (30) , the first verification result, if none of the at least one second verification result can indicate whether the new issued patch (30) can be deployed in the industrial network (40) .
  4. the method (200) according to claim 3, further comprising:
    - receiving (S210) , from the second apparatus (20) , a usage result indicating that the second apparatus (20) uses a specific second verification result of the at least one second verification result, if the specific second verification result can indicate whether the new issued patch (30) can be deployed in the industrial network (40) .
  5. the method (200) according to claim 4, further comprising:
    - setting (S215) trust level of the second apparatus (20) based on a first number of verification results submitted by the second apparatus (20) and a second number of normal usage results submitted by other second apparatuses (20) indicating that verification results submitted by the second apparatus (20) are used by other second apparatuses (20) and verified to be right;
    - labelling (S216) the first verification result with the trust level of the second apparatus (20) .
  6. A method (200) for software updating in an industrial network (40) , executed by a second apparatus (20) , comprising:
    - receiving (S204) , from a first apparatus (10) , a first request to verify whether a new issued patch (30) can be deployed in an industrial network (40) supervised by the second apparatus (20) ;
    - building (S211) up a simulated environment of the industrial network (40) ;
    - testing (S212) the new issued patch (30) in the simulated environment to generate a first verification result indicating whether the new issued patch (30) can be deployed in the industrial network (40) ;
    - sending (S213) , to the first apparatus (10) , the first verification result, for the first apparatus (10) to add into a blockchain.
  7. the method (200) according to claim 6, wherein the simulated environment of the industrial network (40) is:
    - a virtual environment built up based on information of configuration of the industrial network 40, running processes and installed software in the industrial network 40; or
    - a backup image of the industrial network (40) ; or
    - a physical backup of the industrial network (40) ; or
    - a physical backup of a host in the industrial network (40) .
  8. the method (200) according to claim 6, wherein
    - after receiving (S204) the first request, the method further comprises:
    - sending (S206) , to the first apparatus (10) , a second request to query in what kind of industrial networks the new issued patch (30) has been verified to be deployed;
    - receiving (S208) , from the first apparatus (10) , at least one second verification result indicating in what kind of industrial networks the new issued patch (30) has been verified to be deployed;
    - testing (S212) the new issued patch (20) further comprises: testing the new issued patch (20) if the none of at least one second verification result can indicate whether the new issued patch (30) can be deployed in the industrial network (40) .
  9. the method (200) according to claim 8, further comprising:
    - sending (S210) , to the first apparatus (10) , a usage result indicating that the second apparatus (20) uses a specific verification result of the at least one second verification result, if the specific second verification result can indicate whether the new issued patch (30) can be deployed in the industrial network (40) .
  10. the method (200) according to claim 9, wherein the first verification result is labelled with the trust level of the second apparatus (20) based on a first number of verification results submitted by the second apparatus (20) and a second number of normal usage results submitted by other second apparatuses (20) indicating that verification results submitted by the second apparatus (20) are used by other second apparatuses (20) and verified to be right.
  11. A system (100) for software updating in an industrial network (40) , comprising: a first apparatus (10) and at least one second apparatus (20) , each second apparatus supervising an industrial network (40) , wherein,
    - the first apparatus (10) is configured to: send, to a second apparatus (20) , a first request to verify whether a new issued patch (30) can be deployed in an industrial network (40) supervised by the second apparatus (20) ;
    - the second apparatus (20) is configured to:
    - receive, from the first apparatus (10) , the first request;
    - testing the new issued patch (30) in a simulated environment of the industrial network (40) to generate a first verification result indicating whether the  new issued patch (30) can be deployed in the industrial network (40) ;
    - send, to the first apparatus (10) , the first verification result;
    - the first apparatus (10) , is further configured to:
    - receive, from the second apparatus (20) , the first verification result;
    - add the first verification result into a blockchain.
  12. A first apparatus (10) for software updating in an industrial network, comprising:
    - at least one processor (101) ;
    - at least one memory (102) , coupled to the at least one processor (101) , configured to execute method according to any of claims 1～5.
  13. A second apparatus (20) for software updating in an industrial network, comprising:
    - at least one processor (201) ;
    - at least one memory (202) , coupled to the at least one processor (201) , configured to execute method according to any of the claims 6～10.
  14. A computer-readable medium for software updating in an industrial network, storing computer-executable instructions, wherein the computer-executable instructions when executed cause at least one processor to execute method according to any of the claims 1～10.
  15. An apparatus (10, 20) for software updating in an industrial network, comprising modules to execute the steps in any of the claims 1～10.
PCT/CN2021/134064 2021-11-29 2021-11-29 Method, apparatus and system for software updating in an industrial network WO2023092570A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CN2021/134064 WO2023092570A1 (en) 2021-11-29 2021-11-29 Method, apparatus and system for software updating in an industrial network

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2021/134064 WO2023092570A1 (en) 2021-11-29 2021-11-29 Method, apparatus and system for software updating in an industrial network

Publications (1)

Publication Number Publication Date
WO2023092570A1 true WO2023092570A1 (en) 2023-06-01

Family

ID=86538762

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/134064 WO2023092570A1 (en) 2021-11-29 2021-11-29 Method, apparatus and system for software updating in an industrial network

Country Status (1)

Country Link
WO (1) WO2023092570A1 (en)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109768954A (en) * 2017-11-09 2019-05-17 诺基亚通信公司 Method and apparatus for the integrity protection system supported by block chain
WO2020016480A1 (en) * 2018-07-16 2020-01-23 Nokia Technologies Oy Electronic device update management
WO2020157369A1 (en) * 2019-01-30 2020-08-06 Nokia Solutions And Networks Oy Remote blockchain network agent for verifying and accepting patch requests from a patch initiator and method thereof
US20210067536A1 (en) * 2019-07-03 2021-03-04 Battelle Memorial Institute Blockchain cybersecurity audit platform

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109768954A (en) * 2017-11-09 2019-05-17 诺基亚通信公司 Method and apparatus for the integrity protection system supported by block chain
WO2020016480A1 (en) * 2018-07-16 2020-01-23 Nokia Technologies Oy Electronic device update management
WO2020157369A1 (en) * 2019-01-30 2020-08-06 Nokia Solutions And Networks Oy Remote blockchain network agent for verifying and accepting patch requests from a patch initiator and method thereof
US20210067536A1 (en) * 2019-07-03 2021-03-04 Battelle Memorial Institute Blockchain cybersecurity audit platform

Similar Documents

Publication Publication Date Title
EP3511820A1 (en) Cloud based artifact lifecycle management system and method thereof
US11714910B2 (en) Measuring integrity of computing system
WO2020202934A1 (en) Risk evaluation/countermeasure planning system and risk evaluation/countermeasure planning method
CN111262889B (en) Authority authentication method, device, equipment and medium for cloud service
EP3477524B1 (en) Methods and systems for holistically attesting the trust of heterogeneous compute resources
US11030347B2 (en) Protect computing device using hash based on power event
JP2010033563A (en) Method and system for platform-based trust verifying service for multi-party verification
CN110688428B (en) Method and device for issuing intelligent contracts
US11436324B2 (en) Monitoring parameters of controllers for unauthorized modification
US11095454B2 (en) Releasing secret information in a computer system
CN113282946B (en) Information security method and system based on data access process in high-reliability environment
US20240104213A1 (en) Securing node groups
KR20090040017A (en) System and method for vulnerability assessment of network based on business model
CN112995236B (en) Internet of things equipment safety management and control method, device and system
WO2021121382A1 (en) Security management of an autonomous vehicle
CN108027856B (en) Real-time indicator for establishing attack information using trusted platform module
CN109889477A (en) Server based on trusted cryptography's engine starts method and device
CN111967016B (en) Dynamic monitoring method of baseboard management controller and baseboard management controller
CN115879099A (en) DCS controller, operation processing method and protection subsystem
WO2023092570A1 (en) Method, apparatus and system for software updating in an industrial network
CN109117625B (en) Method and device for determining safety state of AI software system
CN110941825A (en) Application monitoring method and device
CN113157543B (en) Trusted measurement method and device, server and computer readable storage medium
CN114969712A (en) Trusted program dynamic measurement method and device based on LSM framework
CN113779562A (en) Zero trust based computer virus protection method, device, equipment and medium

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21965300

Country of ref document: EP

Kind code of ref document: A1