WO2020164040A1

WO2020164040A1 - Status change management method, apparatus and computer-readable medium

Info

Publication number: WO2020164040A1
Application number: PCT/CN2019/075047
Authority: WO
Inventors: Dai Fei Guo; Xin Yi WANG
Original assignee: Siemens Aktiengesellschaft; Siemens Ltd., China
Priority date: 2019-02-14
Filing date: 2019-02-14
Publication date: 2020-08-20
Also published as: CN113366476A

Abstract

A status change management method, apparatus and computer-readable medium are proposed, with which sensitive data does not need to be transferred out of a monitored network. A status change management method (300) by a device in a group comprises: detecting (S304) a status change of the device, verifying (S305) the status change. If the status change is verified as trustable, adding (S306) a node including a first log of the status change to a first chain corresponding to the device, broadcasting (S308) the first log in the group to verify (S309) the status change. If the status change is verified in the group as trustable, generating (S311) a second log of the status change based on the first log, and adding (S312) a node including the second log to a second chain corresponding to the group.

Description

Status change management method, apparatus and computer-readable medium

Technical Field

The present invention relates to techniques of security, and more particularly to a status change management method, apparatus and computer-readable medium.

Background Art

Security is vital for a system’s normal operation. Attacks aiming to infect or illegally change configuration of a system, such as DoS (Deny of Service) of a device in a system, can lead to status change of the device. So with proper status change detection, some attacks can be detected timely and with proper management methods damages to a system can be avoided.

However, not all the status changes are caused by attacks. There are still some normal software updates, configuration updates etc., which can cause status changes of a device. So how to effectively verify a status change of a device is also very important for a system’s normal operation.

Furthermore, once an attack happens, how to trace back to root causes is also useful to prevent future attacks.

Summary of the Invention

The present disclosure provides a status change management method, apparatus, and computer-readable medium, with which status change of a device can be effectively detected and verified, even without a third part trustworthy authority. And once an attack happens, root causes can be traced back for prevention of future attacks.

According to a first aspect of the present disclosure, a status change management method performed by a device in a group is presented, it includes: detecting a status change of the device and verifying the status change; and if the status change is verified as locally trustable, adding a node including a first log of the status change to a first chain, wherein the first chain corresponds to the device, and broadcasting the first log in the group to verify the status change, and if the status change is verified in the group as trustable, generating a second log of the status change based on the first log, and adding a node including the second log to a second chain, wherein the second chain corresponds to the group.

According to a second aspect of the present disclosure, a status change management apparatus is presented, it includes a status detection agent and a status management system. The status detection agent includes a detection module configured to detect a status change of a device in a group, a status analysis module configured to verifying the status change, a first chain generator configure to add a node including a first log of the status change to a first chain if the status change is trustable, wherein the first chain corresponds to the device. The status management system includes a communication module configured to broadcast the first log in the group to verify the status change, a second chain generator configured to generate a second log of the status change and add a node including the second log to a second chain, wherein the second chain corresponds to the group, if the status change is verified in the group as trustable.

According to a third aspect of the present disclosure, a status change management apparatus is presented, it includes: at least one memory configured to store instructions, and at least one processor coupled to the at least one memory and upon execution of the executable instructions, configured to: detect a status change of the device; verify the status change, and if the status change is trustable, add a node including a first log of the status change to a first chain, wherein the first chain corresponds to the device; broadcast the first log in the group to verify the status change, and if the status change is verified in the group as trustable, generate a second log of the status change based on the first log, and add a node including the second log to a second chain, wherein the second chain corresponds to the group.

According to a fourth aspect of the present disclosure, a computer-readable medium is presented, it stores executable instructions, which upon execution by a computer, enables the computer to execute the method of the first aspect.

With the first chain of local status and the second chain of group status, status change of a device can be effectively detected and verified, even without a third part trustworthy authority. And once an attack happens, with logs recorded in the first chain and the second chain, root causes can be traced back for prevention of future attacks. The solutions provided in the disclosure can protect a device in a group, such as a control device in the industrial control system, from illegal modification or malicious misuse of system resource.

In an embodiment of the present disclosure, the initial status of the device is verified and if the initial status is trustable, the initial node of the first chain is created, and the log of the initial status in the initial node id recorded.

The initial status verification can check the initial status of the device, and prevent initially any possible attacks.

In an embodiment of the present disclosure, if any of following conditions or any combination of the following conditions is met, the status change can be verified as trustable:

-update file or component in the device causing the first status change is signed by a trustable Certificate Authority;

-the first status change does not need process behavior, control behavior or network behavior;

-the first status change doesn’t cause change of the device’s configuration.

With definitions of above conditions, criteria are provided for verifying local status change by the device.

In an embodiment of the present disclosure, if all other devices in a same virtual group with the device verify the status change as trustable, the status change is verified in the group as trustable, wherein devices in a same virtual group have same security properties.

A virtual group with same security property can build the relevance relation among different devices, which make it possible to choose relevant device (s) to verify status change of other device (s) . This can improve the efficiency and precision of the status change verification.

In an embodiment of the present disclosure, devices in the group competes to be an accounting device in the group, and the winning device generates the second log of the status change, and adds a node including the second log to a second chain. Optionally, devices in the same virtual group with the device whose statuses are verified as trustable have same higher opportunity to be an accounting device in the group, than devices not in the same virtual group with the device.

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 devices in a system.

FIG. 2A depicts the first chain of the present disclosure.

FIG. 2B depicts the second chain of the present disclosure.

FIG. 3 depicts a flow chart for a status change management method of the present disclosure.

FIG. 4 depicts a block diagram displaying an exemplary embodiment of a status management apparatus of the present disclosure.

FIG. 5 depicts the other block diagram displaying an exemplary embodiment of a status change management apparatus of the present disclosure.

Reference Numbers:

100, a group of devices

10, a device in the group 100

20, a virtual group

300, a status change management method of the present disclosure

400, 500, status change management apparatuses of the present disclosure

S301～S313, steps of the status change management method of the present disclosure

411, a detection module

412, a status analysis module

413, a first chain generator

414, a status configuration DB

415, a first chain DB

421, a group based status verification module

422, a communication module

423, a second chain generator

424, a group chain configuration DB

425, a status gather module

426, a second chain DB

51, at least one memory

52, at least one processor

Detailed Description of Example Embodiments

As mentioned above, attacks bring threats to a system, which may cause destructive damage, so how to detect attacks to ensure security is vital for a system’s normal operation.

Taking an industrial control system as an example, historically, industrial control systems have commonly been based upon proprietary industrial protocols and operated in isolated environments, which are considered with limited network connection to open Internet environment. Today with advanced technologies development, e.g. Cloud, Big Data, AI (Artificial Intelligence) , etc. industrial control systems are more commonly connected to open networks for communicating with remote sites, and also for remote diagnostics and analysis. Obviously, risks of cyber-attack are growing with digitalization and increased networking of machines and industrial plants. For critical devices in an industrial control system, such as PLCs (Programmable Logic Controller) , which control industrial processes, appropriate protective measures are mandatory.

However, it is difficult for most industrial control systems to install traditional blacklist anti-malware software since they need to control production processes real time and don’t have enough resources to execute such anti-malware software. Furthermore, features of attacks should be known in advance and recorded for identification of such attacks. So it is not effective for unknown malware software and attacks. Some white list based schemes have been proposed to provide high effective anti-malware capabilities in an industrial network. But this method is also only effective to known components or firmware, it is difficult to prevent attacks to malicious modification or update to the industrial control component, configuration, important data file or firmware. And a lot of human efforts are needed for white list maintenance.

This disclosure provides a status change management method, apparatus, and computer-readable medium, with which status change of a device can be effectively detected and verified, even without a third part trustworthy authority. For example, if integrity of file or data or process of a device in a group is tampered, the device itself can’t detect attacks. Other devices in the same group can collect log of the status change of this device and make analysis, such as comparison with own processes to find possible abnormity and attacks. And once an attack happens, root causes can be traced back for prevention of future attacks.

Hereinafter, above-mentioned and other features of the present technique are described in details. 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.

The present technique has been described hereinafter in details by referring to FIG. 1 to 5.

By way of introduction, FIG. 1 depicts devices in a group. Referring to FIG. 1, a group 100 includes devices, such as device 10. The group 100 can be part of a system, or the whole system, such as an industrial control system.

Referring to FIG. 2A and FIG. 2B, the status management solutions presented in this disclosure are based on a double-chain structure.

A first chain shown in FIG. 2A records local status change information within the device 10. Each of Nodes “Local status 1” , “Local status 2” , …, “Local status n” record status change information in a time sequence, n is a positive integer. Once status change is detected and verified as trustable by the device 10 locally, a node will be added in the first chain and a first log of the status change will be recorded in the new added node in the first chain. Optionally, for each device in the group 100, there is a corresponding first chain to record local status change information.

A second chain shown in FIG. 2B records overall status change information of the group 100. Each of nodes “Overall status 1” , “Overall status 2” , …, “overall status m” record the overall status change information in a time sequence, m is a positive integer. The first log of local status change will be gathered and the status change of the device 10 will be verified, if trustable a second log of status change of the device 10 will be generated and a node will be added in the second chain, and the second log of status change of the device 10 will be recorded in the new added node in the second chain. Optionally, the second log can also include information of status change of other device (s) in the group 100. Logs of status change of devices in the group 100 can be collected and status change of devices in the group 100 can be recorded periodically.

With the double chain structure, status change of the device 10 can be verified both locally and on a group-level. And with the recorded status change information, root cause of an attack can be traced back.

FIG. 3 depicts a flow chart for a status change management method 100 of the present disclosure.

In step S301, the device 10 verifies its initial status. If the initial status is trustable, the device 10 proceeds with steps S302 and S303.

In step S302, the device 10 creates an initial node of a first chain. That is, the “Local status 1” in FIG. 2 A.

In step S303, the device 10 records log of the initial status in the initial node.

Optionally, status information of a device can be defined in a status configuration DB (for example: the status configuration DB 414 in status change management apparatus 400 of the present disclosure) , which may include following objects:: control componentin a device, important process running on a device, predefined important file (script, web page, data file) related to control process or application, configuration parameter (s) of a device and/or application (s) running on a device (such as IP address of a server connected to the device 10) , firmware of a device, patch status information of a device, signature status for a process/control component/patch in a device, information of control behavior of a device, information of network behavior of a device, etc.

A log of an initial status may include following contents: object description of the device 10 (the object here include mean any object (s) defined in the status configuration DB) , initial status description of the device 10, time stamp, information of the initial node, node sequence number of the initial node, hash value of the contents of the initial node, etc.

The device 10 proceeds with step S304.

In step S304, the device 10 detects a status change of the device 10.

In step S305, the device 10 verifies the status change locally, and if the status change is verified as trustable, the device 10 proceeds with step S306 and S307; otherwise, the device 10 proceeds with step S306’.

To verify the status change, the device 10 can monitor its status, any change will be analyzed.

Optionally, the device 10 can verify the status change as trustable, if any of the following conditions is met:

-update file or component in the device 10 causing the status change is signed by a trustable Certificate Authority;

-the status change does not need process behavior, control behavior or network behavior;

-the status change doesn’t cause change of the device’s configuration.

Or, the device 10 can verify the status change as trustable if a combination of the above conditions is met. For example, if update file or component in the device 10 causing the status change is signed by a trustable Certificate Authority, and the status change does not need process behavior, control behavior or network behavior, the device 10 verify the status change as trustable.

The above conditions can be stored in the above mentioned status configuration DB, and an administrator can modify or change the conditions.

In step S306, the device 10 adds a node including a first log of the status change to the first chain (shown in FIG. 2A) .

In step S304～S306, the device 10 detects status according to the status configuration in the status configuration DB 414 and generates the latest status report, if the status is changed, the device 10 analyzes whether the status change is trustable or harmless, that is verifying the status change, and then will combine the log of status change and hash value of the previous node in the first chain to generate the new node in the first chain. A node in the first chain may include the following information: status change log: new object description (the object here include mean any object (s) defined in the status configuration DB) , new status description, time stamp, node information, node sequence number, hash value of the previous node, hash value of the node content, etc. The first log of the status change can include any combination of following items of information. Then, the device 10 proceeds with step S307.

In step S306’, the device 10 can broadcast an alarm to all other devices in the group 100, and/or management device (s) for the group 100. Other devices and/or management device (s) can record the alarm for later attack identification and analysis.

Optionally, in step S307, the device 10 will verify the trust level of the status change by checking the log of the status change based on a group chain configuration DB (for example: the group chain configuration DB 424 in status change management apparatus 400 of the present disclosure) . If the status change is trustable, the device 10 proceeds with S308, otherwise the device 10 proceeds with S308’.

In step S308, the device 10 broadcasts the log of the status change in the group 100. Other devices in the group 100 then get the log of the status change.

In step S309, other devices in the group 100 verify the second status by checking the log of the status change, based on the group chain configuration DB. Devices in the group 100 can access the same group chain configuration DB. Or there is a group chain configuration DB in each device in the group 100, and they are synchronized to make sure that contents in all of them are the same. If the status change is verified in the group as trustable, the device 10 proceeds with step S310, otherwise, the device 10 proceeds with step S310’.

Optionally, if all other devices in the group 200 verify the status change, the status change can be considered to be verified in the group 100 as trustable. Or optionally, if all other devices in a same virtual group 20 with the device 10 verify the status change as trustable, the status change can be considered to be verified in the group 100 as trustable.

Here, devices in a same virtual group have same security properties.

A virtual group can include devices in the group 100 which have same security properties. So a virtual group can be built based on the security property relevance of devices. A virtual group can be built based on following criteria:

1) If devices are in the same process, they can be in the same virtual group.

2) If devices are running the same application, they can be in the same virtual group.

3) If devices are of same type. Such as inverters in an industrial control system can have same security properties.

4) If devices are updated with the same patch periodically.

5) If devices are in the same signature status for a process/component/patch.

6) If devices have same controlling behavior (s) .

7) If devices have same network behavior (s) .

In step S310’, the device 10 can broadcast an alarm to all other devices in the group 100, and/or to management device (s) for the group 100. Other devices and/or management device (s) can record the alarm for later attack identification and analysis.

In step S310, devices in the group 100 compete to be an accounting device in the group 100. Optionally, a device in the same virtual group 20 with the device 10 has higher priority than other devices not in the same virtual group 20 to become the accounting device if they can prove their statuses are trustable. And optionally, one random generator will determine which one can be the accounting device to generate and record a new node of the second chain. If the device 10 wins the competition to be the accounting node, the device 10 proceeds with step S311and S312, otherwise the procedure 300 will go to step S311’, S312’ and S313.

In step S311, the device 10 generates a second log of the status change. The device 10 can collect logs of status change from other devices in the group 100, and based on the collected logs and its own first log of the status change, generate the second log of the status change.

In step S312, the device 10 adds a node including the second log to the second chain.

Optionally a node in the second chain may include following information: Status change log (that is the second log of the status change) , Node description of changing status, time stamp, accounting node information, random number, hash value of the previous node, hash value of this node content, etc.

In step S311’, the winning accounting device in the group 100 collect logs of status change (such as the first log of the status change) from devices in the group 100.

In step S312’, the winning accounting device generates a second log of the status change based on the collected logs.

In step S313, the winning accounting device add a node including the second log to the second chain.

FIG. 4 depicts a block diagram displaying an exemplary embodiment of a status management apparatus 400 of the present disclosure.

Referring to FIG. 4, the status management apparatus 400 may include a status detection agent 41 used to verify local status of the device 10 and maintain the first chain corresponding to the device 10. The status management apparatus 400 also includes a status management system 42, used to verify overall status of the group 100 and maintain the second chain corresponding to the group 100.

The status detection agent 41may include following modules:

-a detection module 411, configured to detect a status change of a device in a group;

-a status analysis module 412, configured to verifying the status change;

-a first chain generator 413, configure to add a node including a first log of the status change to a first chain if the status change is trustable, wherein the first chain corresponds to the device;

-a status configuration DB 414, configured to define status information of the device 10;

-a first chain DB 415, configured to store data of nodes of the first chain.

And the status management system 42 may include following modules:

-a group based status verification module 421, configured to verify status change (s) of other device (s) in the group 100, optionally , also configured to verify the trust level of the status change by checking the log of the status change based on the above mentioned group chain configuration DB .

-a communication module 422, configured to broadcast the first log in the group to verify the status change, also receive status logs from other devices in the group.

-a second chain generator 423, configured to generate a second log of the status change, and add a node including the second log to a second chain, wherein the second chain corresponds to the group, if the status change is verified in the group as trustable;

-a group chain configuration DB 424, based on which the status change can be verified;

-a second chain DB 426, configured to store data of nodes of the second chain;

-a status gather module 425, configured to collect the log of the status change.

Optionally, the status management system 42, the status detection agent 41 and modules can be software modules which include executable instructions. Upon execution by a computer, the executable instructions enable the computer to execute any of the methods presented in this disclosure.

Optionally, the status analysis module 412 is further configured to verify the initial status of the device 10. The first chain generator 413 is further configured to create the initial node of the first chain, and record the log of the initial status in the initial node.

Optionally, when verifying the status change, the status analysis module 412 is further configured to verify the status change as trustable if any of following conditions or any combination of the following conditions is met:

-update file or component in the device causing the status change is signed by a trustable Certificate Authority;

-the status change doesn’t cause change of the device’s configuration.

Optionally, if all other devices in a same virtual group 100 with the device 10 verify the status change as trustable, the status change is verified in the group 100 as trustable, wherein devices in a same virtual group 20 have same security properties.

Optionally, before generating a second log of the status change, and adding a node including the second log to a second chain, the second chain generator 423 is further configured to compete to be an accounting device in the group 100. And when generating a second log of the status change, and adding a node including the second log to a second chain, the second chain generator 423 is further configure d to: if winning, generate a second log of the status change, and add a node including the second log to a second chain, as the accounting device in the group 100.

Optionally, when competing to be an accounting device in the group 100, the second chain generator 423 is further configured to: make the device 10 together with other devices in the same virtual group 20 with the device 10 whose statuses are verified as trustable have same higher opportunity to be an accounting device in the group 100, than devices not in the same virtual group 20 with the device 10, wherein devices in a same virtual group 20 have same security properties.

Now, in combination of an exemplary procedure, functions of the above modules and interactions between them will be introduced.

An exemplary industrial scenario is as followed: some engineer stations, operation stations and application servers install the Status Management System and Status Detection Agent to detect the status and verify changes. One patch will be applied in one industrial control device (such as a PLC) by administrator. The patch has been signed with trustable CA and was issued by the original vendor.

In initial phase, the detection module 411 of the status detection agent 41 of the device 10 gathers status information according to the status configuration in the status configuration DB 414. The detection module 411 detects status information of the device 10, control process the device 10 involves in, patch and/or configuration of the device 10, etc. status analysis module 412 analyzes the status according to the Status Configuration Database. For example, it analyzes hash value and signature of a patch to verify whether it is trustable. If the initial status is trustable, the first chain generator 413 creates the initial node of the first chain which will be stored in the first chain DB 415.

The detection module 411 monitors status changing of the device 10 and detects malicious or illegal manipulation of configuration, patch or software.

When a patch is installed in the device (for example: by the administrator) , the detection module 411 will detect this kind of status changes. It can detect signature of the patch and the status analysis module will verify the signature of the patch.

If the patch is verified as trustable, the first chain generator 413 will send the first log of the status change to the status gather module 425 of the device 10. The group based status verification module 421 will verify the signature of the patch with the public key of the issuer.

If the patch is verified by the group based status verification module 421 as trustable, it will broadcast the first log of the status change and information of the patch via a communication module 422 in the group 100. The status gather module 422 of other devices in the group 100 will get the first log and information of the patch, and verify them based on the group chain configuration DB if they are one device in the same virtual group 20 with the device 10, which means they have the same security properties, such as installing the same patch and having the same public key of the vendor signing the patch..

If all devices in the same virtual group 20 with the device 10 verify that the status change is trustable, the patch will be installed on the device 10.

The Status Management System 42 of each device in the group 100 will compete to record the second log of the status change and generate a new node in the second chain. Device (s) in the same virtual group 20 with the device 10 will have higher priority to become the accounting node if they can prove their statuses are trustable. For those trustable devices in the same virtual group, one random generator will calculate one random number and compare it with sequence number (from 1 to n) of the device. If the remain of the random number divided by the total number of the device is equal to the sequence number of the device, the device will be chosen as accounting device.

The accounting device will get the first log of the first status from the patching device 10 and generate a new node in the second chain. The new node will be verified by all nodes in the second chain and then the new node will be effective in the second chain.

FIG. 5 depicts the other block diagram displaying an exemplary embodiment of a status change management apparatus 500 of the present disclosure. Referring to FIG. 5, the status change management apparatus 500 may include: at least one memory 51 configured to store instructions; and at least one processor 52 coupled to the at least one memory 51, and upon execution of the executable instructions, configured to: detect a status change of the device 10 and verify the status change. If the status change is trustable, the at least one processor 52 if further configured to add a node including a first log of the status change to a first chain corresponding to the device 10 and broadcast the first log in the group 100 to verify the status change, and if the status change is verified in the group 100 as trustable, generate a second log of the status change based on the first log, and add a node including the second log to a second chain, wherein the second chain corresponds to the group 100.

Optionally, the at least one processor 52 is further, upon execution of the executable instructions, configured to: verify the trust level of the status change based on a group chain DB by checking the log of the status change after the status change is verified as trustable based on a status change configuration DB. If the status change is trustable, the at least one processor 52 is further configured to broadcast the first log and get the status of change verified in the group 100.

Optionally, the at least one processor 52 is further, upon execution of the executable instructions, configured to: verify the initial status of the device 10. If the initial status is trustable, create the initial node of the first chain and record the log of the initial status in the initial node.

Optionally, when verifying the status change, the at least one processor 52 is further, upon execution of the executable instructions, configured to: verify the status change as trustable if any of following conditions or any combination of the following conditions is met:

-the status change doesn’t cause change of the device’s configuration.

Optionally, if all other devices in a same virtual group 20 with the device 10 verify the status change as trustable, the status change is considered to be verified in the group 100 as trustable, wherein devices in a same virtual group 20 have same security properties.

Optionally, before generating a second log of the status change, and adding a node including the second log to a second chain, the at least one processor 52 is further, upon execution of the executable instructions, configured to: compete to be an accounting device in the group 100. And when generating a second log of the status change, and adding a node including the second log to a second chain, the at least one processor 52 is further, upon execution of the executable instructions, configured to: if winning, generate a second log of the status change, and adding a node including the second log to a second chain, as the accounting device in the group.

Optionally, when competing to be an accounting device in the group 100, the at least one processor 52 is further, upon execution of the executable instructions, configured to: make the device 10 together with other devices in the same virtual group 20 with the device 10 whose statuses are verified as trustable have same higher opportunity to be an accounting device in the group 100, than devices not in the same virtual group 20 with the device 10, wherein devices in a same virtual group 20 have same security properties.

A computer-readable medium is also provided in the present disclosure, storing 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.

This disclosure provides a status change management method, apparatus, and computer-readable medium, with which status change of a device can be effectively detected and verified, even without a third part trustworthy authority. And once an attack happens, root causes can be traced back for prevention of future attacks.

The solutions provided in the disclosure can protect a device in a group, such as a control device in the industrial control system, from illegal modification or malicious misuse of system resource which has the following advantages:

Every advice in the group has two sub-systems: the status management system and the status detection agent which can detect illegal changes or malicious misuses without central control or monitoring. Any change can be verified by the status detection Agent of a device locally and the other node on the group level.

Introduction of accounting node makes only devices with trustable status have the right to record new status and generate the new node which can assure that the node cannot make malicious modification to the chain. This can improve the security of the group.

Even both the status management system and status detection agent are attacked or illegally changed, other devices can easily find out that the status of a device is not secure any more.

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

A status change management method (300) performed by a device in a group, comprising:

- detecting (S304) a status change of the device;

- verifying (S305) the status change, and if the status change is verified as trustable,

- adding (S306) a node including a first log of the status change to a first chain, wherein the first chain corresponds to the device;

- broadcasting (S308) the first log in the group to verify (S309) the status change, and

- if the status change is verified in the group as trustable,

- generating (S311) a second log of the status change based on the first log, and

- adding (S312) a node including the second log to a second chain, wherein the second chain corresponds to the group.
The method of claim 1, further comprising:

- verifying (S301) the initial status of the device;

- if the initial status is verified as trustable,

- creating (S302) the initial node of the first chain, and

- recording (S303) the log of the initial status in the initial node.
The method of claim 1 or 2, wherein verifying (S305) the status change, comprises: if any of following conditions or any combination of the following conditions is met, verifying the status change as trustable:

- update file or component in the device causing the first status change is signed by a trustable Certificate Authority;

- the first status change does not need process behavior, control behavior or network behavior;

- the first status change doesn’t cause change of the device’s configuration.
The method of any of claims 1～3, wherein, if all other devices in a same virtual group with the device verify the status change as trustable, the status change is verified in the group as trustable, wherein devices in a same virtual group have same security properties.
The method of any of claims 1～4, wherein

- before generating (S311) a second log of the status change, and adding (S312) a node including the second log to a second chain, the method comprises:

competing (S310) to be an accounting device in the group, and

- generating (S311) a second log of the status change, and adding (S312) a node including the second log to a second chain, further comprises: if winning,

generating (S311) a second log of the status change, and adding (S312) a node including the second log to a second chain, as the accounting device in the group.
The method of claim 5, wherein competing (S310) to be an accounting device in the group, comprises: if the device’s status is trustable,

- making the device have same opportunity to be an accounting device in the group with other devices in the same virtual group with the device, and higher opportunity to be an accounting device in the group than devices not in the same virtual group with the device, wherein devices in a same virtual group have same security properties.
A status change management apparatus (400) , comprising:

- a status detection agent (41) , including:

- a detection module (411) , configured to detect a status change of a device in a group;

- a status analysis module (412) , configured to verifying the status change;

- a first chain generator (413) , configure to add a node including a first log of the status change to a first chain if the status change is trustable, wherein the first chain corresponds to the device;

- a status management system (42) , including:

- a communication module (422) , configured to broadcast the first log in the group to verify the status change;

- a second chain generator (423) , configured to:

- generate a second log of the status change based on the first log, and

- add a node including the second log to a second chain, wherein the second chain corresponds to the group,

if the status change is verified in the group as trustable.
The apparatus (400) of claim 7, wherein

- the status analysis module (412) is further configured to verify the initial status of the device;

- the first chain generator (413) is further configured to: if the initial status is verified as trustable,

- create the initial node of the first chain, and

- record the log of the initial status in the initial node.
The apparatus (400) of claim 7 or 8, wherein when verifying the status change, the status analysis module (412) is further configured to verify the status change as trustable if any of following conditions or any combination of the following conditions is met:

- updating file or device causing the status change is signed by a trustable Certificate Authority;

- the status change does not need process behavior, control behavior or network behavior;

- the status change doesn’t cause change of the device’s configuration.
The apparatus (400) of any of claims 7～9, wherein, if all other devices in a same virtual group with the device verify the status change as trustable, the status change is verified in the group as trustable, wherein devices in a same virtual group have same security properties.
The apparatus (400) of any of claim 7～10, wherein

- before generating a second log of the status change, and adding a node including the second log to a second chain, the second chain generator (423) is further configured to: compete to be an accounting device in the group, and

- when generating a second log of the status change, and adding a node including the second log to a second chain, the second chain generator (423) is further configured to: if winning, generate a second log of the status change, and add a node including the second log to a second chain, as the accounting device in the group.
The apparatus (400) of claim 11, wherein when competing to be an accounting device in the group, the second chain generator (423) is further configured to: if the device’s status is trustable, make the device have same opportunity to be an accounting device in the group with other devices in the same virtual group with the device, and higher opportunity to be an accounting device in the group than devices not in the same virtual group with the device, wherein devices in a same virtual group have same security properties.
A status change management apparatus (500) , comprising:

- at least one memory (51) , configured to store the executable instructions;

- at least one processor (52) , coupled to the at least one memory (51) , and upon execution of the executable instructions, configured to:

- detect a status change of the device;

- verify the status change, and if the status change is trustable,

- add a node including a first log of the status change to a first chain, wherein the first chain corresponds to the device;

- broadcast the first log in the group to verify the status change, and

- if the status change is verified in the group as trustable,

- generate a second log of the status change based on the first log, and

- add a node including the second log to a second chain, wherein the second chain corresponds to the group.
The apparatus (500) of claim 13, wherein the at least one processor (52) is further, upon execution of the executable instructions, configured to:

- verify the initial status of the device;

- if the initial status is verified as trustable,

- create the initial node of the first chain, and

- record the log of the initial status in the initial node.
The apparatus (500) of claim 13 or 14, wherein, when verifying the status change, the at least one processor (52) is further, upon execution of the executable instructions, configured to: verify the status change as trustable if any of following conditions or any combination of the following conditions is met:

- updating file or device causing the status change is signed by a trustable authentication center;

- the status change does not need process behavior, control behavior or network behavior;

-the status change doesn’t cause change of the device’s configuration.
The apparatus (500) of any claims 13～15, wherein if all other devices in a same virtual group with the device verify the status change as trustable, the status change is verified in the group as trustable, wherein devices in a same virtual group have same security properties.
The apparatus (500) of any of claims 13～16, wherein

- before generating a second log of the status change, and adding a node including the second log to a second chain, the at least one processor (52) is further, upon execution of the executable instructions, configured to: compete to be an accounting device in the group, and

- when generating a second log of the status change, and adding a node including the second log to a second chain, the at least one processor (52) is further, upon execution of the executable instructions, configured to: if winning, generate a second log of the status change, and adding a node including the second log to a second chain, as the accounting device in the group.
The apparatus (500) of claim 17, wherein when competing to be an accounting device in the group, the at least one processor (52) is further, upon execution of the executable instructions, configured to: if the device’s status is trustable, make the device have same opportunity to be an accounting device in the group with other devices in the same virtual group with the device, and higher opportunity to be an accounting device in the group than devices not in the same virtual group with the device, wherein devices in a same virtual group have same security properties.
A computer-readable medium, storing executable instructions, which upon execution by a computer, enables the computer to execute the method of any one of the claims 1～6.