Security detection method for edge device behaviors oriented to swan gap system

Abstract

The invention provides an edge device behavior security detection method for a swan gap system, and the method comprises the steps: extracting behavior expected data of each component from a source code or an intermediate representation, and constructing an expected behavior graph; collecting behavior data of each component, and constructing an actual behavior graph; comparing the actual behavior map with an expected behavior map, calculating the structural similarity between the actual behavior map and the expected behavior map, and marking a node or a behavior path deviating from the expectation; and comparing the capacity, authority and component calling relationship between the nodes or behavior paths deviating from the expectation and the expectation behavior map to obtain an abnormal behavior source, taking response measures of different levels according to the type, severity and influence range of the behavior paths deviating from the expectation, and generating an abnormal report. According to the method, deviation between behavior maps is identified through a structured comparison method, and abnormal behaviors such as unauthorized capability combination calling, implicit permission extension and service path hijacking are effectively discovered.

Description

Technical Field

[0001] The present invention belongs to the field of device management, and in particular relates to an edge device behavior security detection method for the Hongmeng system. Background Art

[0002] With the widespread deployment of the HarmonyOS operating system on edge devices, the system's component-based, distributed architecture, and multi-capability integration have significantly improved resource management and system flexibility, but have also placed higher demands on the security of device operation. Applications in the HarmonyOS system are managed and scheduled through multiple Ability modules, which can be scheduled by the system, triggered by users, or implicitly activated by other components, resulting in highly decoupled and flexible service composition capabilities. While this design optimizes resource utilization and user experience, it also makes the call paths between components more complex and dynamic, blurring the boundaries of permission usage, and making system behavior tracking and security monitoring more difficult. Current mainstream security detection methods are mostly based on traditional mobile platform architectures, typically relying on static permission analysis, API access sequence matching, and log backtracking. However, these methods fail to effectively account for the distributed scheduling characteristics of the HarmonyOS system, nor can they accurately restore the actual capability call paths and permission transfer processes, resulting in blind spots in identifying service composition calls, implicit permission abuse, and unauthorized behavior. Furthermore, edge devices generally face limited computing resources, making existing high-cost sandboxes or remote monitoring agents inadequate for this environment. More importantly, security testing of edge devices requires not only the discovery of problems, but also the provision of clear behavioral traceability and explanation paths to support compliance audits, security assessments, and post-event responsibility definition. However, traditional testing methods cannot meet this critical requirement. Summary of the Invention

[0003] The purpose of this invention is to design an edge device behavior security detection method for the Hongmeng system, which can trace back to the specific component behavior difference path and directly support business needs such as enterprise information security management, level protection assessment and data leakage prevention response.

[0004] In order to achieve the above objectives, the present invention provides a method for edge device behavior security detection for the Hongmeng system, the method comprising:

[0005] Extracting expected behavior data for each component from the source code or intermediate representation to construct an expected behavior graph, where the nodes of the expected behavior graph are composed of components, capabilities, and permissions, and the edges of the expected behavior graph are the dependencies between components, capabilities, and permissions;

[0006] Collect behavioral data for each component and construct an actual behavior graph. The nodes of the actual behavior graph are composed of components, capabilities, and permissions, and the edges of the actual behavior graph are the dependencies between components, capabilities, and permissions.

[0007] Comparing the actual behavior graph with the expected behavior graph, calculating the structural similarity between the actual behavior graph and the expected behavior graph, and marking nodes or behavior paths that deviate from expectations; the structural similarity calculation is based on node attributes, and when the structural similarity is lower than a preset threshold, it is marked as deviating from expectations;

[0008] Compare the capabilities, permissions, and component call relationships of the nodes or behavior paths that deviate from the expected behavior graph with the expected behavior graph to obtain the source of the abnormal behavior, and take different levels of response measures based on the type, severity, and scope of impact of the deviation from the expected behavior path, and generate an abnormality report.

[0009] Furthermore, the nodes of the expected behavior graph include component nodes, capability nodes and permission nodes. The component nodes represent functional modules in the system, the capability nodes represent functional interfaces required by each component, and the permission nodes represent operation permissions required by the components.

[0010] Furthermore, the edges of the expected behavior graph include component-to-capability edges and component-to-permission edges. The component-to-capability edges represent the capabilities declared by the component, and the component-to-permission edges represent the permissions required by the component.

[0011] Furthermore, a sliding window mechanism is used when constructing the actual behavior graph, and the data in each time window is updated over time, replacing the oldest data with the latest data.

[0012] Furthermore, a first regularization term is introduced when constructing the actual behavior graph. The first regularization term is used to control the weight of low-frequency behavior events and reduce the interference of low-frequency behaviors on the graph.

[0013] Furthermore, the types of deviation from expectations include component deviation, permission abuse and unauthorized invocation of capabilities. The component deviation refers to the calling relationship between components or the component itself not existing in the actual behavior graph, or its function does not conform to the definition of the expected behavior graph; the permission abuse refers to the permission request not existing in the expected behavior graph; the unauthorized invocation of capabilities refers to the component calling an unauthorized capability in the actual behavior graph, or calling a capability that does not conform to the expected behavior graph.

[0014] Furthermore, a second regularization term is introduced in the process of comparing the actual behavior graph with the expected behavior graph. The second regularization term is used to adjust the node weights in the graph comparison process to suppress the interference of low-priority events on graph construction and comparison.

[0015] Furthermore, the response measures at different levels include:

[0016] First-level response measures: Generate warning logs and record events, and continuously monitor abnormal behavior paths;

[0017] Level 2 response: Pause the execution of the relevant component and prompt the user for confirmation or verification;

[0018] Level 3 response measures: Isolate affected components, revoke sensitive permissions, trigger security recovery mechanisms, and lock the device to prevent further security risks.

[0019] Furthermore, the abnormal report includes the nodes or behavior paths that deviate from the expected ones, the sources of abnormal behaviors, the attribution analysis results, and the response measures.

[0020] Furthermore, the abnormality report also includes an abnormal behavior score, which is obtained by weighted calculation of the severity, frequency of occurrence, and impact of the abnormal behavior on the system.

[0021] The beneficial technical effects of the present invention are at least as follows:

[0022] In response to the above problems, the present invention provides an artificial intelligence simulation teaching method and system for holographic interactive teaching scenarios. The present invention extracts the expected behavior information of each component through static analysis of the source code or compiled products in the Hongmeng system, and constructs a static behavior graph based on this as a comparison benchmark. Combined with the scheduling information during device operation, the actual service call path and permission usage process of the device are dynamically restored. Through a structured comparison method, deviations between behavior graphs are identified, and abnormal behaviors such as unauthorized capability combination calls, implicit permission extensions, and service path hijacking are effectively discovered. This method does not rely on cloud-based model training, nor does it require the introduction of invasive monitoring components. It has the advantages of being lightweight and locally deployable. It is suitable for government and enterprise terminals and industrial control equipment with limited resources and extremely high requirements for behavioral compliance. In addition, the present invention has good interpretability. All detection results can be traced back to specific component behavior difference paths, and can directly support business needs such as enterprise information security management, level protection assessment, and data leakage prevention response. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The present invention is further described with reference to the accompanying drawings. However, the embodiments in the accompanying drawings do not constitute any limitation to the present invention. A person skilled in the art can obtain other drawings based on the following drawings without creative effort.

[0024] Figure 1 This is a flow chart of the edge device behavior security detection method for the Hongmeng system according to the present invention. DETAILED DESCRIPTION

[0025] The following describes embodiments of the present invention in detail. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended only to explain the present invention and are not to be construed as limiting the present invention.

[0026] In one or more embodiments, Figure 1 As shown, a method for edge device behavior security detection for the Hongmeng system is disclosed, and the method includes the following:

[0027] S1: Extract the expected behavior data of each component from the source code or intermediate representation and construct an expected behavior graph. The nodes of the expected behavior graph are composed of components, capabilities, and permissions, and the edges of the expected behavior graph are the dependencies between components, capabilities, and permissions.

[0028] Specifically, in this embodiment, this step aims to construct a component's expected behavior graph by statically analyzing the ArkTS source code or intermediate representation (IR) in the HarmonyOS system. This graph clearly defines the expected behavior of each component, including its required capability interfaces, permission requirements, and the calling relationships between components. This graph serves as a benchmark for behavioral compliance assessment during subsequent testing, helping the system identify whether actual behavior deviates from the developer's design intent.

[0029] The expected behavior graph is mainly used to represent how components interact through declared capabilities and permissions, and can further reveal the dependencies between different components.

[0030] In this example, the following data needs to be input to construct the expected behavior map:

[0031] ArkTS code or IR representation: Obtain the behavior definition of relevant modules from the application source code of the HarmonyOS system, especially the declaration capabilities, permission requirements and calling dependencies of each component.

[0032] Component declaration and permission list: Contains the capabilities and permissions (such as file reading and writing, network requests, etc.) declared by each component during the development phase, as well as the dependency paths with other components.

[0033] First, extract the behavior declarations of each component from the ArkTS source code or IR. These declarations typically exist in the code in the form of classes or modules, and developers typically define the component's functionality and permissions through annotations or specific code structures. For example, in HarmonyOS, a UI component might declare that it requires access to "location services" or "network requests," and these permissions and capabilities are explicitly listed in the code.

[0034] Use static analysis tools (such as abstract syntax tree (AST)-based parsing tools) to analyze the source code or IR and extract the functional declarations of each component. Specifically, this step parses the annotations of each class, method, and module to obtain the developer-declared permissions (such as "location" and "network") and capabilities (such as "access Bluetooth" and "read files"). This method obtains the required permissions and capability interfaces for each component.

[0035] More specifically, suppose a UI component declares "location permission" and "camera permission", then in the code, these two permissions will be marked as the capability interfaces required by the component and will serve as permission nodes when constructing the graph later.

[0036] Furthermore, the nodes of the graph will be composed of components, capabilities, and permissions. Each node represents an entity, such as a component (UI module, service module), a permission (such as positioning, storage), and a capability (such as network requests, Bluetooth access, etc.). Each component node will be connected to its declared capability node and permission node, with directed edges representing the relationship between components and capabilities (i.e., which capabilities the component declares) and the relationship between components and permissions (i.e., which permissions the component requires).

[0037] Specifically, if component A (such as a UI component) declares the "Access Camera" capability, a node is created for the component in the graph and connected to a "Camera Capability" node. If the component also declares "Location Permission," the component node is also connected to the "Location Permission" node.

[0038] Furthermore, the nodes in each graph are divided into three types: component nodes, capability nodes, and permission nodes. Component nodes represent functional modules in the system, capability nodes represent the functional interfaces required by each component, and permission nodes represent the operational permissions required by the component.

[0039] Edge types include:

[0040] Component-to-capability edge: indicates that a component declares a capability;

[0041] Component-to-permission edge: Indicates that a component requires a certain permission.

[0042] Furthermore, the expected behavior graph of the component is generated The diagram includes each component's permission requirements, capability declarations, and dependencies with other components. This diagram will serve as a baseline for subsequent steps to help determine whether the actual behavior meets expectations.

[0043] The key to this step is the combination of static code analysis and graph modeling, which structures the permissions, capabilities, and dependencies between components defined by developers during the programming phase into a graph. Traditional behavioral detection methods can usually only evaluate component behavior through a simple list of permissions, and cannot fully and accurately reflect the developer's intentions. This step constructs a more accurate "behavioral intention" model in the form of a graph, ensuring that subsequent behavioral detection can not only detect whether permissions are being abused, but also identify whether components deviate from the functional path expected by the developer. This graph will serve as an important basis for behavioral consistency verification in subsequent steps, providing an accurate benchmark for security detection.

[0044] S2: Collect the behavior data of each component and construct an actual behavior graph. The nodes of the actual behavior graph are composed of components, capabilities, and permissions, and the edges of the actual behavior graph are the dependencies between components, capabilities, and permissions.

[0045] Specifically, in this embodiment, this step captures the device's behavior data in real time through a sliding window mechanism to construct a real-time behavior graph. This allows real-time monitoring of whether devices are executing tasks according to the expected path and timely detection of deviations. Through this comparison, the system can identify whether the device has exhibited abnormal behaviors such as abuse of authority or unauthorized operation. In addition, this step also introduces a regularization term to optimize the stability of the graph construction and suppress the interference of low-priority behavioral events.

[0046] Specifically, while the device is running, the system collects real-time behavioral data from each component through HarmonyOS's event stream. This data includes information such as component wake-up, capability invocation, and permission requests. To prevent excessive data volume from impacting system performance, the system uses a sliding window mechanism. Data within each time window (for example, 5 minutes) is updated over time, with new data replacing the oldest data. This ensures that the system always focuses on recent behavioral data without being distracted by excessive historical data.

[0047] Specifically, suppose that while the device is running, component A requests permission to access the camera and executes the corresponding capability call. This action is recorded as an event. Over time, as the window slides, the previous event is replaced by the new event, maintaining the real-time nature of the data.

[0048] Furthermore, whenever the system captures a new behavioral event, the behavioral graph will be updated in real time. These behavioral events (such as component permission requests, component wakeups, and capability invocations) are recorded as graph nodes, with edges representing their relationships. Each event is converted into a node, which is connected by edges such as capability invocations and permission requests to form the device's behavioral path. The behavior graph is updated dynamically, constantly updating with each new event.

[0049] For example, if component A requests permission to access the camera and performs the related capability, the graph will be updated to include a node for the relationship between component A and "Camera Permission." The system will continue to process subsequent behavioral events, adding all components, permissions, capabilities, and other information to the graph as nodes and edges, thus forming the complete behavioral path of the device within the current time window.

[0050] Specifically, the construction of the behavior graph can be expressed in the following form:

[0051]

[0052] in, Represents a time window The captured behavioral events, is the number of behavior events in the current window, Identifies the current time window. Each event Contains information such as components, capabilities, permissions, etc., and is connected to other nodes through edges to form a complete behavior path. A behavior graph of a device within a specified time window, reflecting the device's behavior and capability call path.

[0053] Furthermore, when constructing a behavior graph, low-frequency behavior events can negatively impact the graph's accuracy and stability, especially those that are not critical to device behavior. To mitigate the impact of low-priority behavior events, this step introduces a regularization term to optimize stability and accuracy during graph construction. By controlling the weight of low-frequency behavior events, the regularization term reduces their impact on the graph, ensuring that the graph focuses more on core behaviors.

[0054] The regularization term is designed as follows:

[0055]

[0056] in, Indicates the time window Deviations in behavioral events, is the regularization coefficient, controlling the strength of the regularization term. This design effectively reduces the interference of low-frequency behaviors on the behavior graph, improving the quality and stability of the behavior graph. By introducing the regularization term, the system can more accurately construct the behavior graph, eliminating noise from low-priority events and improving the graph's ability to describe device behavior.

[0057] The core of this step is to ensure the real-time collection and accurate comparison of device behavior through the sliding window mechanism and real-time map construction. During comparison, the system can promptly detect deviations in device behavior and take appropriate action. By introducing regularization terms to optimize the stability and accuracy of graph construction, the system can effectively identify and suppress interference from low-frequency behavioral events. Furthermore, focusing on monitoring high-risk paths ensures timely detection of potential security issues, providing reliable support for subsequent behavioral consistency detection and deviation analysis.

[0058] S3: Comparing the actual behavior graph with the expected behavior graph, calculating the structural similarity between the actual behavior graph and the expected behavior graph, and marking nodes or behavior paths that deviate from the expected ones; the structural similarity calculation is based on the attributes of the nodes, and when the structural similarity is lower than a preset threshold, it is marked as deviating from the expected ones;

[0059] Specifically, in this embodiment, the purpose of this step is to compare the real-time behavior graph generated in step 2. and in step 1 , checking whether the device's behavior meets the developer's expectations and promptly identifying potential behavioral deviations. Behavioral deviations may include security risks such as permission abuse and unauthorized component calls. By comparing the graph structure, this step can clearly reveal the differences between the device's actual behavior and expected behavior, and generate a deviation report to provide a basis for subsequent security audits or remediation.

[0060] In this step, the core task is to compare two graphs: one is the expected behavior graph predefined by the developer , the other is a behavior graph generated in real time from the actual operation of the device Each graph consists of nodes and edges. Nodes represent device components, permissions, capabilities, etc., and edges represent the call relationships between them.

[0061] The purpose of this comparison is to determine whether the actual behavior graph is consistent with the expected behavior graph. Specifically, the system compares each node and edge, calculating the structural similarity between the actual and expected behavior graphs. If the matching degree of a node or edge is low, the system deems the node or behavior path to be deviated and marks it as an anomaly.

[0062] The formula for calculating graph similarity is as follows:

[0063]

[0064] in, and Respectively and The nodes, Representation node and The similarity between is the total number of nodes. Similarity is calculated based on node attributes, such as capability calls and permission requests. When the similarity falls below a set threshold, the node is considered to have deviated. This formula is the core comparison algorithm in this step, which evaluates the deviation between actual and expected behavior by calculating the similarity of the graph structure.

[0065] Furthermore, during the comparison process, the system will mark the behavioral paths that do not meet expectations. By comparing the graph structure, the system can identify the following types of deviations:

[0066] Component deviation: the calling relationship between components or the components themselves does not exist, or its function does not meet the The definition in .

[0067] Permission Abuse: If there is an unauthorized permission request in the actual behavior graph (for example, component A requests access to the camera permission, but this permission is not in the developer's expected graph), ), it is marked as a privilege abuse.

[0068] Unauthorized capability invocation: This means that a component invokes an unauthorized capability in its actual behavior graph, or invokes a capability that does not conform to the designed path.

[0069] For each detected deviation, the system will mark the anomaly and carry out subsequent processing. These deviations are recorded as deviation nodes and will be further processed in subsequent security audits and remediation steps.

[0070] Furthermore, to improve the accuracy of deviation detection, this step specifically focuses on high-risk paths, particularly those involving sensitive permissions (such as location, camera, and network access). The system prioritizes comparisons for behavior paths requesting multiple sensitive permissions and increases the frequency of monitoring for these paths. If a deviation from a high-risk path occurs, the system will promptly respond and record the abnormal behavior.

[0071] Specifically, during device operation, component A requested "camera permission" and "location permission," and subsequently executed related capability calls. This path is marked as a high-risk path by the system, and the sampling frequency of this path during the comparison process is increased to ensure that the system can promptly detect potential security risks.

[0072] Furthermore, during the graph comparison process, low-frequency behavioral events may cause unnecessary noise interference, affecting detection accuracy. To optimize this problem, this step introduces a regularization term. This regularization term is used to adjust the node weights during the graph comparison process, suppressing the interference of low-priority events on graph construction and comparison. The regularization term is implemented using the following formula:

[0073]

[0074] in, Indicates the time window Deviations in behavioral events, is the regularization coefficient, which controls the strength of the regularization term. By adjusting the influence of low-frequency behaviors, the regularization term helps the system focus more on core behavior paths, improving the accuracy of graph comparison.

[0075] This step uses a structured graph comparison method, based on the calculation of behavioral graph similarity, to accurately detect deviations between device behavior and expected behavior. By prioritizing high-risk paths and combining it with innovative regularization, the system effectively identifies potential security risks such as abuse of permissions and unauthorized calls, providing a precise basis for subsequent behavioral remediation and auditing. Through real-time monitoring and deviation detection, the entire solution ensures that devices operate as intended by developers, thereby improving system security and reliability.

[0076] S4: Compare the capabilities, permissions, and component call relationships of the nodes or behavior paths that deviate from the expected behavior graph with the expected behavior graph to obtain the source of the abnormal behavior, and take different levels of response measures based on the type, severity, and impact scope of the deviation from the expected behavior path, and generate an abnormality report.

[0077] Specifically, in this embodiment, the core objective of this step is to further attribute abnormal behavior based on the results of the previous step (graph structure comparison and behavioral deviation detection), analyze the root cause of the deviation, and implement responsive control measures based on the type of anomaly. Through anomaly attribution, the system identifies the component, permission, or behavioral path that caused the deviation and responds appropriately to each deviation. Finally, a detailed anomaly report is generated, helping security auditors quickly analyze and remediate issues and prevent potential future risks.

[0078] The goal of anomaly attribution is to identify the root cause of behavioral deviations. In this step, the system performs detailed attribution analysis by comparing the deviation behavior path with the capabilities, permissions, and component call relationships predefined in the graph. The core of the attribution process lies in understanding the context of the deviation node in the graph and identifying the root cause through the following analysis methods:

[0079] Component Association Analysis: The system analyzes the component where the behavior deviates, checking whether the component exceeds its defined permissions or invokes unauthorized capabilities. By reviewing the component's permission declarations and capability interfaces, the system can track and identify the component causing the deviation.

[0080] Permission Abuse Analysis: Compare the permission requests in the actual behavior graph with the permission requirements in the expected graph to determine whether any unauthorized permission requests have occurred. If a component requests a permission that is not defined in the expected graph, the system will mark the behavior as permission abuse.

[0081] Capability call path analysis: For deviated nodes, the system checks the capability call path to ensure that the capability call complies with the predetermined execution path. If the capability call exceeds the expected path, the system will track and mark it as an unauthorized capability call.

[0082] Based on these analyses, the system can identify the source of abnormal behavior and generate attribution reports for deviation nodes, providing a basis for subsequent response control.

[0083] After the attribution analysis is complete, the system determines the response measures based on the type, severity, and scope of the deviation. The goal of response control is to promptly prevent potential security threats and prevent further impact of non-compliant behavior on devices and systems. Depending on the nature of the deviation, the system will take the following different levels of response measures:

[0084] Level 1 response (minor anomalies): For minor abnormal behaviors (such as a high frequency of permission requests but no sensitive permissions involved), the system will generate a warning log and record the event, continuously monitoring the behavior path to prevent it from developing into a more serious security risk.

[0085] Level 2 response (moderate anomalies): For moderately severe anomalies (such as unauthorized permission requests that do not involve sensitive data), the system will suspend the execution of the relevant components and prompt the user for confirmation or verification to ensure that no unauthorized operations are performed.

[0086] Level 3 response measures (serious exceptions): For serious abnormal behaviors (such as unauthorized access, abuse of sensitive permissions, etc.), the system will immediately take security protection measures, including but not limited to: isolating affected components, revoking sensitive permissions, triggering security recovery mechanisms, and even locking the device to prevent further security risks.

[0087] Furthermore, this step introduces an innovative outlier scoring mechanism to assess the severity, frequency, and impact of deviant behaviors. Each deviant behavior is categorized into different response levels based on its score, allowing the system to intelligently prioritize the most severe or frequent outliers.

[0088] The abnormal behavior scoring mechanism takes into account the following three factors:

[0089] Severity: The severity of the deviant behavior, such as whether it involves access to sensitive data or whether it is an unauthorized call.

[0090] Frequency: How often does the deviant behavior occur in the system? Frequent abnormal behavior may lead to greater security threats.

[0091] Scope of impact: The scope of the abnormal behavior's impact on the system, including whether it affects multiple components and whether it destroys the core functions of the system.

[0092] The abnormal behavior scoring formula is as follows:

[0093]

[0094] in, Rate the severity of the abnormal behavior, is the frequency of abnormal behavior, is the impact of abnormal behavior on the system, is the weighting coefficient, which controls the impact of each factor on the final score.

[0095] The scoring system enables the system to respond flexibly to different types of abnormal behaviors, giving priority to the most serious, frequent or most influential deviations based on the score, thereby improving the efficiency of resource allocation and the accuracy of response.

[0096] After completing exception attribution and response control, a detailed exception report will be generated. The report content includes the following parts:

[0097] Abnormal deviation nodes and paths: Lists all deviation nodes and their behavior paths, including the type and source of deviation.

[0098] Attribution analysis results: Provides detailed attribution analysis to identify the component, permission, or capability call path that caused the anomaly.

[0099] Response control measures: Record the control measures taken for each abnormal behavior, such as suspending components, revoking permissions, and isolating operations.

[0100] Subsequent suggestions and repairs: Based on the nature and scope of the abnormal behavior, subsequent repair suggestions or safety measures are provided to help system administrators quickly restore the system to normal status.

[0101] Reports are output in a standardized format, making them easier for managers, operations personnel, or security auditors to review and act upon. Exception reports serve as an important basis for subsequent security fixes and audits.

[0102] Through the anomaly attribution and response control in this step, the system can efficiently identify and address abnormal device behavior during operation, promptly remediating potential safety hazards. An innovative anomaly scoring mechanism enables the system to prioritize responses to the most severe and frequent anomalies, ensuring the proper allocation of resources and the effectiveness of security protection. The resulting anomaly report provides a detailed basis for subsequent security audits and remediation efforts, enhancing the security and operability of the entire system.

[0103] An embodiment of the present invention further provides an edge device behavior security detection device for a Harmony system, comprising a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor. When the processor executes the computer program, the steps in the embodiment of the edge device behavior security detection method for a Harmony system are implemented as described above, for example Figure 1 or, the processor implements the functions of the modules in the above-mentioned system embodiments when executing the computer program.

[0104] Exemplarily, the computer program can be divided into one or more modules, which are stored in the memory and executed by the processor to complete the present invention. The one or more modules can be a series of computer program instruction segments that can perform specific functions, and the instruction segments are used to describe the execution process of the computer program in the edge device behavior security detection device for the Hongmeng system.

[0105] The edge device behavior security detection device for the Hongmeng system can be a computing device such as a desktop computer, a laptop, a PDA, and a cloud server. The edge device behavior security detection device for the Hongmeng system can include, but is not limited to, a processor and a memory. Those skilled in the art will understand that the edge device behavior security detection device for the Hongmeng system can also include input and output devices, network access devices, buses, etc.

[0106] The processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASAC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc. The processor is the control center of the edge device behavior security detection device for the Hongmeng system, and utilizes various interfaces and lines to connect the various parts of the entire edge device behavior security detection device for the Hongmeng system.

[0107] The memory can be used to store the computer programs and / or modules. The processor implements the various functions of the edge device behavior security detection device for the Hongmeng system by running or executing the computer programs and / or modules stored in the memory and calling the data stored in the memory. The memory may mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, at least one application required for a function, etc.; the data storage area can store data created according to the operation of the air conditioning controller, etc. In addition, the memory may include a high-speed random access memory and may also include a non-volatile memory, such as a hard disk, a memory, a plug-in hard disk, a smart memory card (SmartMedaaCard, SMC), a secure digital (Secure Digital, SD) card, a flash card (FlashCard), at least one disk storage device, a flash memory device, or other volatile solid-state storage device.

[0108] If the module integrated into the edge device behavior security detection device for the Hongmeng system is implemented as a software functional unit and sold or used as a standalone product, it can be stored in a computer-readable storage medium. Based on this understanding, the present invention can also implement all or part of the process steps in the above-mentioned method embodiments by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When executed by a processor, the computer program can implement the steps of each of the above-mentioned method embodiments. The computer program includes computer program code, which can be in source code form, object code form, executable file, or some intermediate form. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal, and software distribution medium.

[0109] Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments can be implemented by instructing related hardware through a computer program. The program can be stored in a computer-readable storage medium, and when executed, the program can include the processes in the above-described method embodiments. The storage medium can be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

[0110] The above is a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A method for edge device behavior security detection for Hongmeng system, characterized by: The method comprises: Extracting expected behavior data for each component from the source code or intermediate representation to construct an expected behavior graph, where the nodes of the expected behavior graph are composed of components, capabilities, and permissions, and the edges of the expected behavior graph are the dependencies between components, capabilities, and permissions; Collect behavioral data for each component and construct an actual behavior graph. The nodes of the actual behavior graph are composed of components, capabilities, and permissions, and the edges of the actual behavior graph are the dependencies between components, capabilities, and permissions. Comparing the actual behavior graph with the expected behavior graph, calculating the structural similarity between the actual behavior graph and the expected behavior graph, and marking nodes or behavior paths that deviate from expectations; the structural similarity calculation is based on node attributes, and when the structural similarity is lower than a preset threshold, it is marked as deviating from expectations; Compare the capabilities, permissions, and component call relationships of the nodes or behavior paths that deviate from the expected behavior graph with the expected behavior graph to obtain the source of the abnormal behavior, and take different levels of response measures based on the type, severity, and scope of impact of the deviation from the expected behavior path, and generate an abnormality report.

2. According to claim 1, a method for edge device behavior security detection for the Hongmeng system is characterized in that: The nodes of the expected behavior graph include component nodes, capability nodes and permission nodes. The component nodes represent functional modules in the system, the capability nodes represent the functional interfaces required by each component, and the permission nodes represent the operation permissions required by the components.

3. According to a method for edge device behavior security detection for Hongmeng system according to claim 1, it is characterized in that: The edges of the expected behavior graph include component-to-capability edges and component-to-permission edges. The component-to-capability edges represent the capabilities declared by the component, and the component-to-permission edges represent the permissions required by the component.

4. According to a method for edge device behavior security detection for Hongmeng system according to claim 1, it is characterized in that: The actual behavior graph is constructed using a sliding window mechanism, where the data in each time window is updated over time, with the latest data replacing the oldest data.

5. According to a method for edge device behavior security detection for Hongmeng system according to claim 1, it is characterized in that: A first regularization term is introduced when constructing the actual behavior graph. The first regularization term is used to control the weight of low-frequency behavior events and reduce the interference of low-frequency behaviors on the graph.

6. According to a method for edge device behavior security detection for Hongmeng system according to claim 1, it is characterized in that: The types of deviation from expectations include component deviation, permission abuse and unauthorized capability invocation. The component deviation refers to the calling relationship between components or the component itself not existing in the actual behavior graph, or its function does not conform to the definition of the expected behavior graph; the permission abuse refers to the permission request not existing in the expected behavior graph; the capability unauthorized invocation refers to the component calling an unauthorized capability in the actual behavior graph, or calling a capability that does not conform to the expected behavior graph.

7. The edge device behavior security detection method for the Hongmeng system according to claim 1 is characterized in that: In the process of comparing the actual behavior graph with the expected behavior graph, a second regularization term is also introduced. The second regularization term is used to adjust the node weights in the graph comparison process to suppress the interference of low-priority events on graph construction and comparison.

8. The edge device behavior security detection method for the Hongmeng system according to claim 1 is characterized in that: The different levels of response measures include: First-level response measures: Generate warning logs and record events, and continuously monitor abnormal behavior paths; Level 2 response: Pause the execution of the relevant component and prompt the user for confirmation or verification; Level 3 response measures: Isolate affected components, revoke sensitive permissions, trigger security recovery mechanisms, and lock the device to prevent further security risks.

9. The edge device behavior security detection method for the Hongmeng system according to claim 1 is characterized in that: The abnormal report includes the node or behavior path that deviates from the expected one, the source of the abnormal behavior, the attribution analysis results, and the response measures.

10. A method for edge device behavior security detection for Hongmeng system according to claim 9, characterized in that: The abnormality report also includes an abnormal behavior score, which is obtained by weighted calculation of the severity, frequency of occurrence, and impact of the abnormal behavior on the system.

Images