Internet of Things device security protection method, device and system based on behavioral baseline

Abstract

The present application provides a method, device and system for security protection of IoT devices based on behavioral baselines, the method comprising: monitoring target behaviors during the operation of the IoT device; wherein the target behaviors include behaviors related to the execution of executable files; when the target behaviors are monitored, determining the target executable files associated with the target behaviors, and using a preset algorithm to determine the uniqueness check value of the target executable files; matching the uniqueness check value of the target executable files with the uniqueness check value of the executable files stored in the device firmware of the IoT device; when the match is successful, allowing the target behaviors to occur; when the match fails, blocking the target behaviors. This method can reduce resource consumption and reduce the occurrence of false positives while improving the security of IoT devices.

Description

Technical Field

[0001] The present application relates to the field of Internet of Things security, and in particular to a method, device and system for protecting the security of Internet of Things devices based on a behavioral baseline. Background Art

[0002] There are usually two ways to detect abnormal device behavior: obtaining a behavioral baseline or using rule matching (such as antivirus engine / rule engine / machine learning model) for related events. The rule matching method requires real-time updates of rules or engines to ensure effectiveness, and the engine or machine learning model is difficult to run under the weak processing performance and storage space of IoT devices. It usually needs to connect to the server and use the processing power of the server for analysis. The deployment cost is extremely high in complex networks and with a large number of devices.

[0003] At present, building a behavioral baseline is mainly achieved by obtaining baseline behavior, that is, controlling the device to run for a certain period of time in a normal environment, and monitoring and obtaining the behavior that occurs during the operation of the device, so as to use the behavior that occurs during the operation of the device as the baseline behavior to build a behavioral baseline.

[0004] However, during the construction of the above-mentioned behavioral baseline, there may be a problem of incomplete baseline behavior acquisition. For example, some services did not occur during the operation of the device, and there was no corresponding behavior. As a result, false alarms may occur during security protection based on the constructed behavioral baseline. Summary of the invention

[0005] In view of this, the present application provides a method, device and system for security protection of IoT devices based on behavioral baseline.

[0006] Specifically, the present application is implemented through the following technical solutions:

[0007] According to a first aspect of an embodiment of the present application, a method for protecting the security of an Internet of Things device based on a behavior baseline is provided, which is applied to an Internet of Things device, and the method includes:

[0008] During the operation of the IoT device, target behaviors are monitored; wherein the target behaviors include behaviors related to the execution of executable files;

[0009] When a target behavior is detected, a target executable file associated with the target behavior is determined, and a uniqueness check value of the target executable file is determined using a preset algorithm;

[0010] Matching the uniqueness check value of the target executable file with the uniqueness check value of the executable file stored in the device firmware of the IoT device; wherein the uniqueness check value of the executable file stored in the device firmware of the IoT device includes: the uniqueness check value of each executable file in all executable files generated during the construction of the device firmware; the uniqueness check value of the executable file is determined using the preset algorithm;

[0011] In case of a successful match, the target behavior is allowed to occur;

[0012] In case of a matching failure, the target behavior is blocked.

[0013] According to a second aspect of an embodiment of the present application, there is provided an IoT device security protection device based on a behavior baseline, which is deployed on an IoT device, and the device includes:

[0014] A monitoring unit, used to monitor target behaviors during the operation of the IoT device; wherein the target behaviors include behaviors related to the execution of executable files;

[0015] A determination unit, configured to determine a target executable file associated with the target behavior when a target behavior is detected, and determine a uniqueness check value of the target executable file using a preset algorithm;

[0016] A matching unit, configured to match the uniqueness check value of the target executable file with the uniqueness check value of the executable file stored in the device firmware of the IoT device; wherein the uniqueness check value of the executable file stored in the device firmware of the IoT device includes: the uniqueness check value of each executable file in all executable files generated during the construction of the device firmware; the uniqueness check value of the executable file is determined using the preset algorithm;

[0017] The protection unit is used to allow the target behavior to occur if the match is successful; and to block the target behavior if the match fails.

[0018] According to a third aspect of an embodiment of the present application, an electronic device is provided, wherein:

[0019] Memory, used to store computer programs;

[0020] The processor is used to implement the method provided in the first aspect when executing the program stored in the memory.

[0021] According to a fourth aspect of an embodiment of the present application, a computer program product is provided. The computer program product stores a computer program, and when the computer program is executed by a processor, the method provided in the first aspect is implemented.

[0022] According to a fifth aspect of an embodiment of the present application, a computer program product is provided, wherein a computer program is stored in the computer program product, and when the computer program is executed by a processor, the method provided in the first aspect is implemented.

[0023] According to a sixth aspect of an embodiment of the present application, there is provided an Internet of Things device security protection system based on a behavior baseline, comprising: a continuous integration system, and an Internet of Things device; wherein:

[0024] The continuous integration system is used to obtain all executable files generated during the construction process of the device firmware, and determine the uniqueness check value of each executable file using a preset algorithm, and store the uniqueness check value of the executable file in the device firmware;

[0025] The Internet of Things device is used to monitor target behavior during device operation; wherein the target behavior includes behavior related to the execution of an executable file; when the target behavior is monitored, the target executable file associated with the target behavior is determined, and a uniqueness check value of the target executable file is determined using a preset algorithm; the uniqueness check value of the target executable file is matched with the uniqueness check value of the executable file stored in the device firmware of the Internet of Things device; wherein the uniqueness check value of the executable file stored in the device firmware of the Internet of Things device includes: the uniqueness check value of each executable file in all executable files generated during the construction of the device firmware; the uniqueness check value of the executable file is determined using the preset algorithm; if the match is successful, the target behavior is allowed to occur; if the match fails, the target behavior is blocked.

[0026] The IoT device security protection method based on behavior baseline of the embodiment of the present application monitors the target behavior during the operation of the IoT device. When the target behavior is detected, the target executable file associated with the target behavior is determined, and the uniqueness check value of the target executable file is determined by using a preset algorithm. Then, the uniqueness check value of the target executable file can be matched with the uniqueness check value of the executable file stored in the device firmware of the IoT device. When the match is successful, the target behavior is allowed to occur; when the match fails, the target behavior is blocked, and the uniqueness check value of all executable files generated during the device firmware construction process is determined and stored. The uniqueness check value of each executable file in all executable files generated during the device firmware construction process is used as the behavior baseline, and the target executable file associated with the monitored target behavior is checked. By constructing the behavior baseline based on all executable files generated during the device firmware construction process, the comprehensiveness of the behavior baseline is improved, and the occurrence of false alarms can be effectively reduced. In addition, since the target behavior related to the execution of the executable file is usually small, and the execution of malicious programs in the device is usually related to the execution of the executable file, it is possible to reduce resource consumption while preventing the execution of malicious programs in the device and improving the security of the IoT device. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Figure 1 A flowchart of a method for protecting the security of an IoT device based on a behavioral baseline is shown as an exemplary embodiment of the present application;

[0028] Figure 2 A schematic diagram of the construction behavior of a subassembly shown as an exemplary embodiment of the present application;

[0029] Figure 3 A schematic diagram of a device firmware construction process shown as an exemplary embodiment of the present application;

[0030] Figure 4 A schematic diagram of a construction process of device firmware with added security components is shown as an exemplary embodiment of the present application;

[0031] Figure 5 A schematic diagram of the structure of a security protection device for an Internet of Things device based on a behavior baseline is shown as an exemplary embodiment of the present application;

[0032] Figure 6 The figure is a schematic diagram of the hardware structure of an electronic device shown as an exemplary embodiment of the present application. DETAILED DESCRIPTION

[0033] In order to enable those skilled in the art to better understand the technical solutions provided by the embodiments of the present application and to make the above-mentioned purposes, features and advantages of the embodiments of the present application more obvious and understandable, the technical solutions in the embodiments of the present application are further described in detail below in conjunction with the accompanying drawings.

[0034] See also Figure 1 , is a flow chart of a method for protecting the security of an Internet of Things device based on a behavior baseline provided in an embodiment of the present application, wherein the method for protecting the security of an Internet of Things device based on a behavior baseline can be applied to Internet of Things devices, such as Figure 1 As shown, the IoT device security protection method based on behavior baseline may include the following steps:

[0035] Step S100: During the operation of the IoT device, target behaviors are monitored; wherein the target behaviors include behaviors related to the execution of executable files.

[0036] In an embodiment of the present application, in order to prevent malicious programs from being executed in an IoT device, specific behaviors (which may be referred to as target behaviors) related to the execution of executable files in the IoT device may be monitored.

[0037] For example, for an IoT device, the executable file needs to set the executable permission before it can be executed in the IoT device, and for the executable file with the executable permission, the execution of the executable file needs to be realized by starting a process.

[0038] Accordingly, the behaviors related to the execution of the executable file may include, but are not limited to, some or all of the behaviors such as file permission change behavior (INOTIFY) and process startup behavior (NETLINK).

[0039] Step S110: when a target behavior is detected, a target executable file associated with the target behavior is determined, and a uniqueness check value of the target executable file is determined using a preset algorithm.

[0040] Step S120: Match the uniqueness check value of the target executable file with the uniqueness check value of the executable file stored in the device firmware of the IoT device; wherein the uniqueness check value of the executable file stored in the device firmware of the IoT device includes: the uniqueness check value of each executable file in all executable files generated during the device firmware construction process; the uniqueness check value of the executable file is determined using a preset algorithm.

[0041] In an embodiment of the present application, in order to prevent malicious programs from being executed in an IoT device, a unique check value for each executable file among all executable files generated during the device firmware construction process can be pre-determined and stored. The unique check value can be used to perform a legitimacy check on executable files that may be executed during the operation of the IoT device.

[0042] Exemplarily, the uniqueness check value of an executable file may be used to uniquely identify an executable file, which may include but is not limited to a hash value, a content fingerprint, or a digital signature value.

[0043] In one example, considering that the resources of IoT devices are usually limited, the uniqueness check value of the executable file can choose to calculate a hash value with relatively low resource requirements.

[0044] Accordingly, when a target behavior is detected, an executable file associated with the target behavior (which may be referred to as a target executable file) may be determined, and a uniqueness check value of the target executable file may be determined using a preset algorithm.

[0045] When the uniqueness check value of the target executable file is determined, the uniqueness check value of the target executable file may be matched with the uniqueness check value of the executable file stored in the device firmware of the IoT device.

[0046] That is, the uniqueness check value of the target executable file can be compared with the uniqueness check value of each executable file stored in the device firmware of the IoT device to determine whether there is a uniqueness check value (which can be called the target uniqueness check value) that is the same as the uniqueness check value of the target executable file among the uniqueness check values ​​of each executable file stored in the device firmware of the IoT device.

[0047] If the uniqueness check value of each executable file stored in the device firmware of the IoT device contains the target uniqueness check value, it can be determined that the match is successful. In this case, it can be determined that the target executable file is a legitimate executable file, such as an executable file that comes with the system.

[0048] If the uniqueness check value of each executable file stored in the device firmware of the IoT device does not contain the target uniqueness check value, it can be determined that the match fails. In this case, it can be determined that the target executable file is an illegal executable file, such as an executable file of a malicious program.

[0049] Step S130: When the match is successful, the target behavior is allowed to occur.

[0050] In an embodiment of the present application, when the uniqueness check value of the target executable file successfully matches the uniqueness check value of the executable file stored in the device firmware of the Internet of Things device, that is, when the uniqueness check value of each executable file stored in the device firmware of the Internet of Things device contains the target uniqueness check value, the target behavior can be allowed to occur, that is, a normal response can be made to the target behavior.

[0051] Step S140: When the matching fails, the target behavior is blocked.

[0052] In an embodiment of the present application, when the uniqueness check value of the target executable file fails to match the uniqueness check value of the executable file stored in the device firmware of the Internet of Things device, that is, the uniqueness check value of each executable file stored in the device firmware of the Internet of Things device does not contain the target uniqueness check value, the target behavior can be blocked, that is, the target behavior is prevented from being carried out and the response to the target behavior is refused.

[0053] It can be seen that in Figure 1 In the method flow shown, during the operation of the IoT device, the target behavior is monitored. When the target behavior is monitored, the target executable file associated with the target behavior is determined, and the uniqueness check value of the target executable file is determined using a preset algorithm. Then, the uniqueness check value of the target executable file can be matched with the uniqueness check value of the executable file stored in the device firmware of the IoT device. When the match is successful, the target behavior is allowed to occur; when the match fails, the target behavior is blocked, and the uniqueness check value of each executable file in all executable files generated during the device firmware construction process is determined and stored. The uniqueness check value of all executable files generated during the device firmware construction process is used as a behavior baseline, and the target executable file associated with the monitored target behavior is checked. By constructing a behavior baseline based on all executable files generated during the device firmware construction process, the comprehensiveness of the behavior baseline is improved, and the occurrence of false alarms can be effectively reduced. In addition, since the target behavior related to the execution of executable files is usually small, and the execution of malicious programs in the device is usually related to the execution of executable files, it is possible to prevent malicious programs from being executed in the device and reduce resource consumption while improving the security of the IoT device.

[0054] In some embodiments, the target behavior includes a file permission change behavior for an executable file;

[0055] The above-mentioned monitoring of target behaviors may include:

[0056] Monitor file permission changes;

[0057] In the case where a file permission change behavior is detected, determining whether the file targeted by the file permission change behavior is an executable file;

[0058] In a case where the file targeted by the file permission change behavior is an executable file, it is determined that the target behavior is monitored; wherein the target executable file is the file targeted by the file permission change behavior.

[0059] For example, the target behavior includes a file permission change behavior for an executable file.

[0060] Exemplarily, during the operation of the IoT device, the file permission change behavior can be monitored. When the file permission change behavior is detected, the file targeted by the file permission change behavior can be obtained, and it can be determined whether the file is an executable file.

[0061] In the case that the file is an executable file, the file permission change behavior may be determined as the target behavior.

[0062] It should be noted that in an embodiment of the present application, when file permission change behavior is monitored, but the file targeted by the permission change behavior is not an executable file, there is no need to perform special processing on the permission change behavior, that is, it will not interfere with the normal progress of the permission change behavior.

[0063] In one example, blocking the target behavior may include:

[0064] Denies permission changes to the target executable file, and deletes the target executable file.

[0065] For example, when a file permission change behavior for an executable file is detected, and the uniqueness check value of the target executable file (the executable file targeted by the file permission change behavior) fails to match the uniqueness check value of the executable file stored in the device firmware of the IoT device, it can be determined that the target executable file is an executable file corresponding to a malicious program. In order to avoid the impact of the execution of the executable file on the security of the IoT device, the permission change of the target executable file can be refused. In addition, the target executable file can also be deleted to further improve the security of the IoT device.

[0066] In some embodiments, the target behavior includes a process initiation behavior;

[0067] In the above case where the target behavior is detected, the target executable file associated with the target behavior is determined, including:

[0068] In the case of detecting the process startup behavior, determining the executable file corresponding to the currently started process as the target executable file;

[0069] The above allows the target behavior to occur, including:

[0070] Allow the currently started process to run;

[0071] The above blocking of target behaviors includes:

[0072] Terminate the currently started process.

[0073] Take the example that the target behavior includes process startup behavior.

[0074] Exemplarily, during the operation of the IoT device, the process startup behavior can be monitored.

[0075] When the process startup behavior is monitored, the executable file corresponding to the currently started process can be determined as the target executable file, and the uniqueness check value of the target executable file can be determined using a preset algorithm.

[0076] When the uniqueness check value of the target executable file is determined, the uniqueness check value of the target executable file may be matched in the manner described in the above embodiment.

[0077] If the match is successful, the currently started process may be allowed to run.

[0078] In the case of a matching failure, the currently started process may be terminated, that is, the currently started process may be prohibited from running.

[0079] In some embodiments, the uniqueness check value of the executable file stored in the device firmware of the IoT device is stored in the security component of the IoT device; the security component is constructed using the uniqueness check values ​​of all executable files generated during the construction of subcomponents other than the security component during the construction of the device firmware as construction dependencies.

[0080] Exemplarily, during the construction process of the device firmware of the Internet of Things device, an additional security component can be added. The security component can use the uniqueness check value of each executable file generated in the construction process of all subcomponents other than the security component during the construction process of the device firmware as a construction dependency. That is, during the construction process of the security component, it is necessary to obtain the uniqueness check value of each executable file generated in the construction process of all other subcomponents during the construction process of the device firmware, and use the obtained uniqueness check value of the executable file as the construction dependency of the security component.

[0081] By building a security component in the above manner, the security component can obtain the uniqueness check value of each executable file in the executable files generated during the construction of all other sub-components, and store it together with the uniqueness check value of the executable file generated during the construction of this component (security component) in the security component. In this way, the security component can store the uniqueness check value of each executable file in all executable files generated during the device firmware construction process.

[0082] It should be noted that in the embodiment of the present application, in addition to constructing the security component in the above manner to obtain and store the uniqueness check value of each executable file among all executable files generated during the device firmware construction process, it is also possible to obtain the uniqueness check value of the executable file generated during the construction process of each sub-component during the device firmware construction process and store it in the designated storage space of the device firmware.

[0083] However, when security protection measures are taken for IoT devices, it is usually necessary to set up a security component in the device firmware (the security component can perform security protection-related processing operations during the operation of the IoT device). Therefore, by using the uniqueness check value of each executable file generated in the construction process of all other subcomponents in the construction process of the device firmware as the construction dependency of the security component, the uniqueness check value of each executable file generated in the construction process of the device firmware can be collected and stored without making major changes to the construction logic of the device firmware.

[0084] Illustratively, in an embodiment of the present application, when a security component is constructed in the manner described above, during the operation of the IoT device, the security protection processing flow described in the above embodiment can be implemented through the security component, and the uniqueness check value of each executable file among all executable files generated during the device firmware construction process is used as the behavior baseline to verify the target executable file associated with the monitored target behavior.

[0085] In some embodiments, the uniqueness check value of the executable file stored in the device firmware of the IoT device is obtained by:

[0086] For any packaging tool chain in the packaging tool chain set, in the process of calling the packaging tool chain to build a subcomponent, the construction parameters are transparently transmitted to the tool chain corresponding to the packaging tool chain through the packaging tool chain, and the tool chain is called to compile the construction parameters; wherein the packaging tool chain set is obtained by packaging each tool chain in the tool chain set in the device firmware construction process;

[0087] Scanning the build result generated by the tool chain through the packaging tool chain to obtain the executable file included in the build result generated by the tool chain;

[0088] Based on the executable files obtained through each packaging tool chain, a preset algorithm is used to determine the uniqueness check value of the executable file.

[0089] Exemplarily, during the construction of device firmware, it is usually necessary to construct multiple subcomponents, and based on the constructed multiple subcomponents, the multiple subcomponents are used as construction dependencies of the device firmware to implement the construction of the device firmware.

[0090] Considering that the executable files generated during the construction process may be packaged or encrypted when the device firmware is built, you may not be able to obtain all the executable files generated during the construction process when the device firmware is built.

[0091] Based on this, in order to more comprehensively collect the executable files generated during the device firmware building process, the executable files can be collected during the compilation phase in the subcomponent building process, that is, during the process of compiling the building parameters using the tool chain.

[0092] Among them, during the construction process of the device firmware, for any sub-component, the system (such as the continuous integration system) can obtain the construction parameters required to build the sub-component during the construction of the sub-component, and call the tool chain to compile the construction parameters to realize the construction of the sub-component.

[0093] In the process of calling the tool chain to compile the build parameters, an executable file will be generated, and the generated executable file will be included in the build result.

[0094] In order to achieve the above-mentioned purpose, in an embodiment of the present application, each tool chain in a tool chain set in a device firmware construction process may be packaged to obtain a packaged tool chain set.

[0095] Exemplarily, the encapsulation tool chain can be understood as adding an encapsulation layer outside the tool chain, which can transparently transmit the build parameters and scan the executable files of the build results generated by the tool chain.

[0096] Correspondingly, for any packaging tool chain in the packaging tool chain set, in the process of calling the packaging tool chain to build a sub-component, the construction parameters can be passed through the packaging tool chain to the tool chain corresponding to the packaging tool chain, the tool chain can be called to compile the construction parameters, and the construction results generated by the tool chain can be scanned through the packaging tool chain to obtain the executable file included in the construction results generated by the tool chain.

[0097] Exemplarily, for executable files obtained through various packaging tool chains, a preset algorithm may be used to determine a uniqueness check value of the executable file.

[0098] In order to enable those skilled in the art to better understand the technical solutions provided in the embodiments of the present application, the technical solutions provided in the embodiments of the present application are described below with reference to specific examples.

[0099] The device firmware of an IoT device is usually composed of several sub-components. Each sub-component can contain a different set of executable files. The sub-components are interdependent. After the sub-components are built, they are finally packaged into the entire device firmware and burned into the device. Once burned, they are rarely changed.

[0100] For example, the construction process of an independent subcomponent can be seen in Figure 2 .

[0101] like Figure 2 As shown in the figure, the build behavior of a subcomponent can be described as: the process of generating build products using source code and build dependencies within a build process.

[0102] The build process usually involves the tool chain used (such as gcc / clang), the build system (such as cmake / make), and some build parameters (such as whether to enable certain specific functions, the default log level, etc.).

[0103] It should be noted that within an embedded system, the build system and build parameters for compiling different subcomponents may be different, but the tool chain is usually the same.

[0104] based on Figure 2 The entire device firmware construction process can be found in Figure 3 .

[0105] like Figure 3 As shown in Figure 1, the construction of the entire device firmware can be described as a sub-component construction with multi-level dependencies. During the entire construction process, all executable files that may be executed in subsequent device operations are generated.

[0106] Based on this, in this embodiment, the construction process of all subcomponents can be intervened, and in the process of generating the construction products, the executable files therein can be extracted and the hash values ​​can be calculated.

[0107] like Figure 4As shown, in this embodiment, during the construction process of the device firmware, a new subcomponent (which may be called a security component) is additionally added. The security component may use the hash values ​​of all executable files generated by other subcomponents during the construction process as construction dependencies, so that in the subsequent device operation stage, the hash values ​​of the executable files generated during the construction process may be used as the behavioral baseline to perform legitimacy verification on the executable files in the operation stage.

[0108] In this embodiment, the implementation process of obtaining the hash value of each executable file in all executable files generated during the device firmware building process may include:

[0109] S0. Encapsulate the toolchain set (T0, T1...Tn) in the device firmware building process to obtain a packaged toolchain set (W0, W1...Wn).

[0110] Exemplarily, the tool chain Ti is packaged to obtain a packaged tool chain Wi, wherein i=0, 1…n.

[0111] S1. In the process of calling the encapsulation tool chain Wi to build subcomponents, the encapsulation tool chain Wi can pass the construction parameters to Ti and call Ti for compilation.

[0112] S2. When the compilation of Ti is completed, the build result generated by the tool chain Ti can be scanned by the encapsulation tool chain Wi to obtain the executable file set included in the build result generated by the tool chain.

[0113] S3. Calculate a hash value for each executable file in the executable file set.

[0114] S4. Repeat the above process for all other sub-components until all other sub-components are built, obtain the hash values ​​of all executable files (which can be recorded as B1), and pass them to the security component as a build dependency. The security component can store the obtained hash values ​​of the executable files of all other sub-components and the hash values ​​of the executable files generated during the construction of this component in the security component.

[0115] It should be noted that, in addition to the hash value of each executable file in all the above executable files, the construction dependency of the security component may also include other information, which is not limited in the embodiment of the present application.

[0116] In this embodiment, when the construction of the device firmware is completed as described above, during the operation of the IoT device, the IoT device can obtain the hash value of each executable file in all executable files generated in the device firmware process from the security component, and can use the hash value of each executable file in all executable files generated in the device firmware process as a behavioral baseline to automatically identify malicious programs and achieve security protection.

[0117] Exemplarily, the safety protection implementation process during the operation of the device may include:

[0118] S1. During the operation of IoT devices, the file permission change behavior and process startup behavior in the system are monitored.

[0119] S2. When a file permission change behavior is detected, determine whether the file targeted by the file permission change behavior is an executable file; if so, go to S3; otherwise, go to S1.

[0120] S3: Calculate the hash value of the executable file and match the hash value of the executable file in B1. If the match is successful, go to S1; if the match fails, go to S4.

[0121] S4. Delete the executable file, record the event, and go to S1.

[0122] S5. When the process startup behavior is detected, the hash value of the executable file corresponding to the currently started process is calculated, and the hash value of the executable file is matched in B1. If the match is successful, go to S6; if the match fails, go to S7.

[0123] S6. Release the process and go to S1.

[0124] S7. Terminate the process and go to S1.

[0125] The method provided by the present application is described above. The device provided by the present application is described below:

[0126] See also Figure 5 , is a schematic diagram of the structure of a security protection device for an Internet of Things device based on a behavior baseline provided in an embodiment of the present application, such as Figure 5 As shown, the IoT device security protection device based on behavior baseline may include:

[0127] A monitoring unit 510, configured to monitor target behaviors during the operation of the IoT device; wherein the target behaviors include behaviors related to the execution of executable files;

[0128] The determination unit 520 is used to determine the target executable file associated with the target behavior when the target behavior is detected, and determine the uniqueness check value of each executable file in the target executable file by using a preset algorithm;

[0129] A matching unit 530 is used to match the uniqueness check value of the target executable file with the uniqueness check value of the executable file stored in the device firmware of the IoT device; wherein the uniqueness check value of the executable file stored in the device firmware of the IoT device includes: the uniqueness check value of all executable files generated during the construction process of the device firmware; the uniqueness check value of the executable file is determined using the preset algorithm;

[0130] The protection unit 540 is used to allow the target behavior to occur if the match is successful; and to block the target behavior if the match fails.

[0131] In some embodiments, the target behavior includes a file permission change behavior for an executable file;

[0132] The monitoring unit 510 monitors the target behavior, including:

[0133] Monitor file permission changes;

[0134] In the case where a file permission change behavior is detected, determining whether the file targeted by the file permission change behavior is an executable file;

[0135] In a case where the file targeted by the file permission change behavior is an executable file, it is determined that a target behavior is monitored; wherein the target executable file is the file targeted by the file permission change behavior.

[0136] In some embodiments, the protection unit 540 blocks the target behavior, including:

[0137] The permission change of the target executable file is refused, and the target executable file is deleted.

[0138] In some embodiments, the target behavior includes a process initiation behavior;

[0139] The step of determining a target executable file associated with the target behavior when the target behavior is detected includes:

[0140] In the case of monitoring the process startup behavior, determining the executable file corresponding to the currently started process as the target executable file;

[0141] The allowing the target behavior to occur includes:

[0142] Allow the currently started process to run;

[0143] The blocking of the target behavior includes:

[0144] Terminate the currently started process.

[0145] In some embodiments, the uniqueness check value of the executable file stored in the device firmware of the Internet of Things device is stored in the security component of the Internet of Things device; the security component is constructed using the uniqueness check value of each executable file in all executable files generated during the construction of other subcomponents except the security component during the construction of the device firmware as a construction dependency.

[0146] In some embodiments, the uniqueness check value of the executable file stored in the device firmware of the IoT device is generated by:

[0147] For any packaging tool chain in the packaging tool chain set, in the process of calling the packaging tool chain to build a subcomponent, the construction parameters are transparently transmitted to the tool chain corresponding to the packaging tool chain through the packaging tool chain, and the tool chain is called to compile the construction parameters; wherein the packaging tool chain set is obtained by packaging each tool chain in the tool chain set in the process of building the device firmware;

[0148] Scanning the build result generated by the tool chain through the packaging tool chain to obtain the executable file included in the build result generated by the tool chain;

[0149] Based on the executable files obtained through each packaging tool chain, the uniqueness check value of the executable file is determined using the preset algorithm.

[0150] In some embodiments, the preset algorithm is a hash algorithm, and the uniqueness check value is a hash value.

[0151] An embodiment of the present application also provides an electronic device, including a processor and a memory, wherein the memory is used to store computer programs; the processor is used to implement the above-described method for protecting the security of an Internet of Things device based on a behavioral baseline when executing the program stored in the memory.

[0152] See also Figure 6, is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present application. The electronic device may include a processor 601 and a memory 602 storing machine executable instructions. The processor 601 and the memory 602 may communicate via a system bus 603. In addition, by reading and executing the machine executable instructions corresponding to the IoT device security protection logic based on the behavioral baseline in the memory 602, the processor 601 may execute the IoT device security protection method based on the behavioral baseline described above.

[0153] The memory 602 mentioned herein may be any electronic, magnetic, optical or other physical storage device that may contain or store information, such as executable instructions, data, etc. For example, the machine-readable storage medium may be: RAM (RadomAccess Memory, random access memory), volatile memory, non-volatile memory, flash memory, storage drive (such as hard disk drive), solid state drive, any type of storage disk (such as optical disk, DVD, etc.), or similar storage medium, or a combination thereof.

[0154] In some embodiments, a machine-readable storage medium is also provided. Figure 6 The memory 602 in the machine-readable storage medium stores machine executable instructions, and when the machine executable instructions are executed by the processor, the IoT device security protection method based on the behavioral baseline described above is implemented. For example, the machine-readable storage medium can be ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, etc.

[0155] An embodiment of the present application also provides a computer program product, which stores a computer program, and when a processor executes the computer program, it prompts the processor to execute the Internet of Things device security protection method based on behavioral baseline described above.

[0156] The embodiment of the present application also provides an Internet of Things device security protection system based on a behavior baseline, including: a continuous integration system, and an Internet of Things device; wherein:

[0157] The continuous integration system is used to obtain all executable files generated during the construction process of the device firmware, and determine the uniqueness check value of each executable file using a preset algorithm, and store the uniqueness check value of the executable file in the device firmware;

[0158] The Internet of Things device is used to monitor target behavior during device operation; wherein the target behavior includes behavior related to the execution of an executable file; when the target behavior is monitored, the target executable file associated with the target behavior is determined, and a uniqueness check value of the target executable file is determined using a preset algorithm; the uniqueness check value of the target executable file is matched with the uniqueness check value of the executable file stored in the device firmware of the Internet of Things device; wherein the uniqueness check value of the executable file stored in the device firmware of the Internet of Things device includes: the uniqueness check value of each executable file in all executable files generated during the construction of the device firmware; the uniqueness check value of the executable file is determined using the preset algorithm; if the match is successful, the target behavior is allowed to occur; if the match fails, the target behavior is blocked.

[0159] Exemplarily, the continuous integration system is a system independent of the IoT device and is used to generate device firmware for the IoT device.

[0160] Exemplarily, the specific implementation of the continuous integration system determining the uniqueness check value of each executable file among all executable files generated during the device firmware building process can refer to the relevant description in the above embodiments.

[0161] Exemplarily, the IoT device may implement security protection in the manner described in the above embodiments.

Claims

1. A method for protecting the security of IoT devices based on behavioral baselines, characterized in that: Applied to an IoT device, the method comprises: During the operation of the IoT device, target behaviors are monitored; wherein the target behaviors include behaviors related to the execution of executable files; When a target behavior is detected, a target executable file associated with the target behavior is determined, and a uniqueness check value of the target executable file is determined using a preset algorithm; Match the uniqueness check value of the target executable file with the uniqueness check value of the executable file stored in the device firmware of the IoT device; wherein the uniqueness check value of the executable file stored in the device firmware of the IoT device includes: the uniqueness check value of each executable file in all executable files generated during the construction of the device firmware; the uniqueness check value of the executable file is determined using the preset algorithm; the uniqueness check value of the executable file stored in the device firmware of the IoT device is stored in the security component of the IoT device; the security component is constructed using the uniqueness check value of each executable file in all executable files generated during the construction of other subcomponents except the security component during the construction of the device firmware as a construction dependency; In case of a successful match, the target behavior is allowed to occur; In case of a matching failure, the target behavior is blocked.

2. The method according to claim 1, characterized in that The target behavior includes a file permission change behavior for an executable file; The monitoring of the target behavior includes: Monitor file permission changes; In the case where a file permission change behavior is detected, determining whether the file targeted by the file permission change behavior is an executable file; In a case where the file targeted by the file permission change behavior is an executable file, determining that a target behavior is monitored; wherein the target executable file is the file targeted by the file permission change behavior; Wherein, blocking the target behavior includes: The permission change of the target executable file is refused, and the target executable file is deleted.

3. The method according to claim 1, characterized in that The target behavior includes a process initiation behavior; The step of determining a target executable file associated with the target behavior when the target behavior is detected includes: In the case of monitoring the process startup behavior, determining the executable file corresponding to the currently started process as the target executable file; The allowing the target behavior to occur includes: Allow the currently started process to run; The blocking of the target behavior includes: Terminate the currently started process.

4. The method according to any one of claims 1 to 3, characterized in that: The uniqueness check value of the executable file stored in the device firmware of the IoT device is generated in the following manner: For any packaging tool chain in the packaging tool chain set, in the process of calling the packaging tool chain to build a subcomponent, the construction parameters are transparently transmitted to the tool chain corresponding to the packaging tool chain through the packaging tool chain, and the tool chain is called to compile the construction parameters; wherein the packaging tool chain set is obtained by packaging each tool chain in the tool chain set in the process of building the device firmware; Scanning the build result generated by the tool chain through the packaging tool chain to obtain the executable file included in the build result generated by the tool chain; Based on the executable files obtained through each packaging tool chain, the uniqueness check value of the executable file is determined using the preset algorithm.

5. The method according to any one of claims 1 to 3, characterized in that: The preset algorithm is a hash algorithm, and the uniqueness check value is a hash value.

6. A security protection device for IoT devices based on behavioral baseline, characterized in that: Deployed on an IoT device, the device includes: A monitoring unit, used to monitor target behaviors during the operation of the IoT device; wherein the target behaviors include behaviors related to the execution of executable files; A determination unit, configured to determine a target executable file associated with the target behavior when a target behavior is detected, and determine a uniqueness check value of the target executable file using a preset algorithm; A matching unit, used for matching the uniqueness check value of the target executable file with the uniqueness check value of the executable file stored in the device firmware of the IoT device; wherein the uniqueness check value of the executable file stored in the device firmware of the IoT device includes: the uniqueness check value of each executable file in all executable files generated during the construction of the device firmware; the uniqueness check value of the executable file is determined using the preset algorithm; the uniqueness check value of the executable file stored in the device firmware of the IoT device is stored in the security component of the IoT device; the security component is constructed using the uniqueness check value of each executable file in all executable files generated during the construction of other subcomponents except the security component during the construction of the device firmware as a construction dependency; The protection unit is used to allow the target behavior to occur if the match is successful; and to block the target behavior if the match fails.

7. An electronic device, characterized in that: comprising a processor and a memory, wherein: Memory, used to store computer programs; A processor, for implementing the method according to any one of claims 1 to 5 when executing a program stored in a memory.

8. A computer program product, characterized in that The computer program product stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 5 is implemented.

9. A security protection system for IoT devices based on behavioral baseline, characterized in that: include: Continuous integration systems, and IoT devices; among them: The continuous integration system is used to obtain all executable files generated during the construction process of the device firmware, and use a preset algorithm to determine the uniqueness check value of each executable file, and store the uniqueness check value of the executable file in the device firmware; the uniqueness check value of the executable file stored in the device firmware of the Internet of Things device is stored in the security component of the Internet of Things device; the security component is constructed using the uniqueness check value of each executable file in all executable files generated during the construction process of other subcomponents except the security component during the construction process of the device firmware as a construction dependency; The Internet of Things device is used to monitor target behavior during device operation; wherein the target behavior includes behavior related to the execution of an executable file; when the target behavior is monitored, the target executable file associated with the target behavior is determined, and a uniqueness check value of the target executable file is determined using a preset algorithm; the uniqueness check value of the target executable file is matched with the uniqueness check value of the executable file stored in the device firmware of the Internet of Things device; wherein the uniqueness check value of the executable file stored in the device firmware of the Internet of Things device includes: the uniqueness check value of each executable file in all executable files generated during the construction of the device firmware; the uniqueness check value of the executable file is determined using the preset algorithm; if the match is successful, the target behavior is allowed to occur; if the match fails, the target behavior is blocked.

Images