A terminal security protection method based on terminal operation self-explaining constraint verification

Abstract

The application provides a terminal security protection method based on terminal running self-explanation constraint verification, first constructs a terminal running constraint model, defines a legal running state and a state change path, and collects system state information of the terminal in real time. Whenever the terminal state changes, the system generates a self-explanation proof and performs consistency checking with the pre-defined model. When it is detected that the state change does not conform to the safety constraint, the system automatically triggers a security protection strategy, such as isolating a risk process, limiting operation or rolling back to a safe state, etc. The method can effectively prevent memory resident attacks, malicious code injection and advanced persistent threats (APT), and provide more accurate and real-time terminal security protection. The innovation of the application lies in that, through terminal self-explanation and state evolution consistency verification, the limitation of traditional detection methods is broken through, the defense capability against hidden attacks is enhanced, and the application has strong innovation and practical application value.

Description

Technical Field

[0001] This invention relates to the field of terminal security technology, and in particular to a terminal security protection method based on terminal operation self-explanatory constraint verification. Background Technology

[0002] With the widespread use of computer terminals, mobile devices, and servers in various fields, endpoint security has become one of the core challenges in information system security. Traditional endpoint security protection technologies mostly rely on attack detection based on virus signature matching, behavioral analysis, or signature recognition. While these methods can identify known malicious code and attack patterns, they often fail to identify new attacks, especially highly covert ones (such as memory-resident attacks, kernel-level rootkits, and malware injection), in a timely and effective manner.

[0003] Existing behavioral detection technologies typically focus on identifying single behavioral features or process behavior patterns, making them vulnerable to evasion by attackers. This is especially true for complex, long-term, advanced persistent threats (APTs), where traditional methods, relying on static rules and signature matching, fail to identify covert behaviors during the attack process. For example, attackers may modify system processes or tamper with data in memory without immediately exhibiting abnormal behavior, rendering traditional signature-based security measures ineffective.

[0004] Furthermore, most existing security protection methods rely on external detection and analysis, lacking the ability to self-verify the terminal's own operational logic and state changes. Attackers can inject malicious code or modify the system state, potentially causing abnormal changes in the terminal's operational state without attracting the attention of traditional detection tools. Therefore, a new method is needed to systematically analyze the evolution of the terminal's operational state, verifying whether the terminal's current operational state conforms to predefined security constraints, thereby improving the ability to protect against covert attacks.

[0005] To address the shortcomings of existing technologies, this invention proposes a security protection method based on terminal-run self-explanatory constraint verification, which can effectively identify and prevent covert attacks that are difficult to detect using traditional methods, thereby improving the security and anti-attack capabilities of the terminal system. Summary of the Invention

[0006] In view of this, the purpose of this invention is to provide a terminal security protection method based on self-explanatory constraint verification of terminal operation. This method clarifies the legitimate operating states of the terminal, the state change paths, and the evolution rules, and enables the terminal to self-prove the legitimacy of its current operating state through a "self-explanatory proof" mechanism. This method utilizes multi-dimensional state information collected in real time during system operation (such as process state, memory state, permission changes, resource access, etc.) and combines it with an operational constraint model to verify the state evolution path, thereby determining whether the terminal complies with security constraints.

[0007] To achieve the above objectives, the present invention adopts the following technical solution: a terminal security protection method based on terminal runtime self-explanatory constraint verification, comprising the following steps:

[0008] Step 1: Construct a terminal operation constraint model. The operation constraint model is used to describe the set of legal operating states of the terminal under normal operating conditions, the state transition relationships, and the security constraints that each state transition must satisfy.

[0009] Step 2: During terminal operation, continuously collect multi-dimensional system status information related to terminal operation, and construct the current operating status of the terminal based on the system status information;

[0010] Step 3: When the terminal's operating state changes, generate self-explanatory proof information to describe the rationality of the state change based on the correlation between the previous operating state and the current operating state;

[0011] Step 4: Perform consistency verification between the self-explanatory proof information and the terminal operation constraint model to determine whether the current operation state and its state evolution process conform to the predefined security constraints;

[0012] Step 5: When the consistency verification result shows that the current running state does not meet the security constraints, it is determined that the terminal has a security risk, and the corresponding security protection strategy is automatically triggered according to the risk type.

[0013] In a preferred embodiment, the set of legal operating states refers to the set of states in which the current operating state of the terminal satisfies predefined security constraints and is verified by the model; legal states are not equivalent to the normal operating state of the terminal, but rather constitute the basic state units of the normal operating process; the normal operating state of the terminal is composed of a series of legal states and their legal state transition paths.

[0014] In a preferred embodiment, the multidimensional system state information includes one or more of the following: terminal process running state, system call behavior, memory usage state, file and device access behavior, permission changes, and system resource scheduling information; each state is represented as a state vector. ,in:

[0015]

[0016] in, It is in time The collected multidimensional state information vector; subscript An index representing a state object, used to distinguish different processes, threads, or monitored entities; Indicates the first Each process in time The running status characteristics include the process lifecycle state, its scheduling, and resource usage; Indicates the first Each process in time The memory usage characteristics, including memory allocation scale and access behavior; Indicates the first Each process in time The usage status characteristics of system resources, including the usage of CPU, file system, or other system resources.

[0017] In a preferred embodiment, the terminal operation constraint model is constructed by analyzing the historical normal operation data of the terminal. The model is used to characterize the typical state distribution characteristics and state evolution path of the terminal under the condition of no security threat.

[0018] In a preferred embodiment, the self-explanatory proof information includes state transition path information, state change triggering conditions, and corresponding constraint satisfaction information to explain the source of the current running state, and to prove that the generation process of the current running state is interpretable and traceable.

[0019] In a preferred embodiment, the self-explanatory proof generation includes: assuming the current state is The previous legal state was Self-explanatory proof Represented as:

[0020]

[0021] in, The conditions that indicate a change in state; Indicates the previous legal state The process behavior, system event, or external operation that occurs and triggers a state change; the preceding valid state serves as a prerequisite for the state change, used to limit the runtime context in which the triggering behavior occurs;

[0022] Based on the terminal operation constraint model, the system checks whether state changes satisfy predefined state transition conditions. The state transition conditions are used to describe the permission, resource, and time constraints that must be met to allow a state change to occur under a specific legal state.

[0023] The system ultimately forms a self-explanatory state transition proof that includes the preceding legal state, the triggering reason, and the verification results of the transition conditions, which is used to characterize the verifiable evolution process of the terminal's operating state.

[0024] In a preferred embodiment, the consistency verification process is represented by the following formula:

[0025]

[0026] in, The previously established operational constraint model serves as a reference benchmark for the legal operation of the terminal and includes a predefined set of legal states, state transition paths, and corresponding evolution rules. The consistency verification includes at least one of the following: 1) verifying whether the current operating state belongs to the set of legal states; 2) verifying whether the state transition path conforms to the predefined evolution rules; 3) verifying whether the security constraints are satisfied during the state change process.

[0027] In a preferred embodiment, when the consistency check result indicates an anomaly, the security protection strategy includes one or more of the following:

[0028] 1) Restrict system resource access permissions for abnormal processes;

[0029] 2) Isolate operational entities that pose a risk;

[0030] 3) Prevent the abnormal state from evolving further;

[0031] 4) Roll back the terminal's operating state to the most recent trusted state;

[0032] 5) Trigger further security detection and analysis mechanisms.

[0033] In a preferred embodiment, the terminal operation constraint model is initialized during the terminal startup phase and dynamically updated according to the trusted operating state during terminal operation to enhance the model's adaptability to changes in the operating environment.

[0034] In a preferred embodiment, the protection strategy specifically includes the following:

[0035] Isolate abnormal processes: If an abnormal process is detected, the system will forcibly stop or isolate the abnormal process to prevent it from further compromising system security;

[0036] Resource access restrictions: For processes that pose a risk, the system will restrict their access to specific system resources;

[0037] Rollback to a safe state: If the abnormal behavior has a significant impact, the system will restore the terminal to a safe operating state by restoring backups or using snapshot technology;

[0038] Deep detection: The system initiates a further deep detection mechanism to analyze the root cause of the abnormal state and further determine whether there is a covert attack.

[0039] Compared with the prior art, the present invention has the following beneficial effects:

[0040] 1) Security protection based on self-explanatory constraint verification: This invention proposes a method for terminals to verify the legality of their current operating state through self-explanatory proof. Unlike traditional detection methods based on feature matching and behavior analysis, this invention can dynamically generate proofs that explain the legality of the current state from the terminal's own operating state, which greatly enhances the protection against covert attacks.

[0041] 2) Consistency verification of state evolution path: This invention constructs a terminal operation constraint model and performs consistency verification on the evolution path of the terminal state to ensure that each state change has a clear legal basis, effectively preventing attackers from tampering with the system state or injecting malicious code through covert means.

[0042] 3) Dynamic protection and adaptive security strategy: Unlike the traditional method of static rule matching, this invention performs real-time monitoring and verification during terminal operation. Once an anomaly is detected, the system automatically triggers targeted protection measures to ensure the continuity and efficiency of terminal system security.

[0043] 4) No need to rely on known attack characteristics: The security detection method of the present invention does not rely on known malicious code characteristics or behavior patterns, and can effectively identify new and variant attacks, especially suitable for defending against complex attacks such as advanced persistent threats (APTs). Attached Figure Description

[0044] Figure 1 This is a flowchart of a terminal security protection method based on terminal operation self-explanatory constraint verification, which is a preferred embodiment of the present invention. Detailed Implementation

[0045] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0046] It should be noted that the following detailed descriptions are illustrative and intended to provide further explanation of this application. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains.

[0047] It should be noted that the terminology used herein is for the purpose of describing particular implementations only and is not intended to limit the exemplary implementations according to this application; as used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise; furthermore, it should be understood that when the terms “comprising” and / or “including” are used in this specification, they indicate the presence of features, steps, operations, devices, components and / or combinations thereof.

[0048] A terminal security protection method based on terminal runtime self-explanatory constraint verification, referenced Figure 1 This includes the following steps:

[0049] Step 1: Construction of Terminal Operation Constraint Model

[0050] A terminal operation constraint model is constructed in the terminal system to formally describe and constrain the terminal operation process. This model defines the legal operating states allowed during terminal operation, the state transition paths between these legal states, and the safety constraints that each state transition must satisfy.

[0051] In this context, a legal operating state refers to the set of states in which the terminal's current operating state meets predefined security constraints and can be verified through a model. A legal state is not equivalent to the terminal's normal operating state, but rather constitutes the basic state unit of the normal operating process. The terminal's normal operating state is composed of a series of legal states and their legal state transition paths.

[0052] 1) Normal state definition: Define the legal state of each process, system resource, and permission based on historical data. For example, the legal state of a process may be "running" or "paused," but should not be in an "abnormal" or "unresponsive" state.

[0053] Process legal state: The process is in its allowed lifecycle stage and its running behavior conforms to predefined constraints. For example, the process only enters the running state after obtaining the corresponding resources and permissions, and there is no abnormal self-starting, self-injection or unauthorized execution behavior.

[0054] System resource legal status: The terminal's use of system resources is within the permitted range. For example, the process's access to memory, CPU, files or devices does not exceed the set threshold, and the resource access behavior complies with the authorization rules.

[0055] Permission legality status: The terminal process or user permissions comply with the principle of least privilege, the permission change process meets the predefined authorization and audit rules, and there is no unauthorized privilege escalation or privilege abuse.

[0056] 2) State transition path:

[0057] Each legal state transition path must meet certain conditions. For example, for a process to change from a "standby" state to a "running" state, the condition of "resource request successful" must be met.

[0058] Let the state transition relationship be: Its legality can be expressed by the following formula:

[0059]

[0060] in, The trigger function for state transition depends on resource availability, timing conditions, and permission checks.

[0061] 3) Evolutionary rules:

[0062] Define the rules for each state transition. A state transition is a model that describes the actual state changes that occur during terminal operation, used to characterize the evolutionary relationship between legal states. Each state transition must satisfy the corresponding evolution rules, including but not limited to allowed time windows, system resource usage conditions, and permission constraints, to ensure that the evolution of the terminal's operating state always conforms to security constraints.

[0063] For example, a process state transition can be defined as:

[0064] .

[0065] Step 2: Multi-dimensional terminal status acquisition

[0066] The system collects multi-dimensional status information from the terminal in real time, including data sources such as process status, memory usage, and resource access. The status information is organized in time sequence, and the current running status is generated for each point in time.

[0067] 1) Status Acquisition: The system periodically obtains status information about processes, memory, file access, resource usage, etc. from the terminal.

[0068] Process status collection includes process ID, CPU utilization, memory usage, etc.

[0069] Memory status includes memory allocation and access patterns for each process.

[0070] This includes a process's access behavior to files or directories, such as file reading, writing, creation, or deletion operations, and whether the accessed object is a sensitive file, system file, or protected directory.

[0071] This includes the terminal's usage of system resources, such as the utilization of CPU, disk, network interface, or device resources, and whether resource usage exceeds preset thresholds.

[0072] 2) State Representation: Each acquired state can be represented as a state vector. ,in:

[0073]

[0074] in, It is in time The collected multidimensional state information vector. (Index) An index representing a state object, used to distinguish different processes, threads, or monitored entities. Indicates the first Each process in time The running status characteristics include the process lifecycle state, its scheduling, and resource usage; Indicates the first Each process in time The memory usage characteristics, including memory allocation scale and access behavior; Indicates the first Each process in time The usage status characteristics of system resources, including the usage of CPU, file system, or other system resources.

[0075] Step 3: Generation of self-explanatory proof

[0076] Whenever the state of a terminal changes, the system generates a "self-explanatory proof," which describes how the current state transitioned from a valid previous state. The self-explanatory proof is used to ensure the causal validity of state changes.

[0077] 1) Proof generation: Assume the current state is The previous legal state was Self-explanatory proof It can be represented as:

[0078]

[0079] in, This indicates the triggering reason for the current state change. The condition indicating a state change. Specifically,

[0080] in, Indicates the previous legal state The process behavior, system event, or external operation that occurs and triggers a state change; the preceding valid state serves as a prerequisite for the state change, used to limit the runtime context in which the triggering behavior occurs.

[0081] Meanwhile, based on the terminal operation constraint model, the system checks whether the state changes meet the predefined state transition conditions. The verification process is performed, and the state transition conditions are used to describe the permissions, resources, and time constraints that must be met to allow a state change to occur under a specific legal state.

[0082] The system ultimately forms a self-explanatory state transition proof that includes the preceding legal state, the triggering reason, and the verification results of the transition conditions, which is used to characterize the verifiable evolution process of the terminal's operating state.

[0083] 2) Example of a state change proof: For example, if a process transitions from "waiting" to "running", the self-explanatory proof can be expressed as:

[0084]

[0085] This proof explains why the transition of a process from the "waiting" state to the "running" state depends on the condition that "resources are ready".

[0086] Step 4: Consistency Check

[0087] The system performs consistency verification between the currently generated self-explanatory proof and the terminal running constraint model to verify whether the current state and its transition path are legal.

[0088] 1) Verification process: The consistency verification process can be represented by the following formula:

[0089]

[0090] in, The previously established operational constraint model serves as a reference benchmark for the legal operation of the terminal and includes a predefined set of legal states, state transition paths, and corresponding evolution rules.

[0091] During the consistency verification process, the system compares the state transition proof obtained in step three with the constraint information in the runtime constraint model, specifically including:

[0092] 1. Verify whether the current terminal state falls within the legal state range defined in the runtime constraint model;

[0093] 2. Verify whether the actual state transition path exists in the predefined set of valid state transition paths;

[0094] 3. Verify whether the state change process meets the constraints of permissions, resources, and time specified in the corresponding state transition rules.

[0095] When the state transition proof simultaneously meets the above consistency verification conditions, the system determines that the terminal's operation process conforms to the expected operating constraints; otherwise, it determines that there is a consistency deviation in the state evolution process, providing a basis for subsequent anomaly identification and security handling.

[0096] 2) Verification Indicators: The verification results include three aspects:

[0097] State validity: Whether the current state belongs to the set of valid states;

[0098] Path validity: Whether the state transition path conforms to the evolution rules;

[0099] Constraint satisfaction: Whether all safety constraints are satisfied during the state change process.

[0100] Step 5: Security protection strategy triggered

[0101] When consistency verification fails, the system will trigger corresponding security protection policies. These policies specifically include the following:

[0102] 1) Isolate abnormal processes: If an abnormal process is detected, the system will forcibly stop or isolate the abnormal process to prevent it from further compromising system security.

[0103] 2) Resource access restrictions: For processes that pose a risk, the system will restrict their access to specific system resources (such as files, memory, etc.).

[0104] 3) Rollback to a safe state: If the abnormal behavior has a significant impact, the system will restore the terminal to a safe operating state by restoring backups or using snapshot technology.

[0105] 4) Deep detection: The system initiates a further deep detection mechanism to analyze the root cause of the abnormal state and further determine whether there is a covert attack.

[0106] Step 6: Status Recording and Auditing

[0107] All terminal state changes, self-explanatory proof generation, verification results, and security protection measures will be recorded in the security audit log. These logs are used for subsequent event backtracking and security analysis, providing a basis for system optimization and attack attribution.

[0108] This invention achieves full-process automation and dynamism in terminal security protection by constructing a terminal operation constraint model, generating self-explanatory proofs, and performing consistency verification on state evolution paths. Compared with traditional security solutions based on feature matching or single behavior analysis, this invention has the following innovations and advantages:

[0109] 1. Innovation: For the first time, the "terminal self-explanatory constraint verification" mechanism is proposed, which enables the terminal to prove the legitimacy of its current operating state, fundamentally improving the ability to identify unknown attacks, covert attacks and advanced persistent threats (APTs).

[0110] 2. Dynamic protection capability: This invention achieves continuous monitoring and dynamic protection of the entire terminal operation process by collecting multi-dimensional state information in real time, generating state evolution proof, and performing consistency verification, which can promptly detect and prevent abnormal behavior.

[0111] 3. High security and trustworthiness: Through state evolution path verification, this invention can ensure that each state change conforms to predefined constraints, making it difficult for attackers to forge legitimate state paths, thereby significantly increasing the cost of attacks and improving the overall security and trustworthiness of the system.

[0112] 4. Engineering Applicability: This invention can be deployed on a variety of terminal devices, including personal computers, servers and various terminal systems. It can dynamically update the constraint model according to the actual operating status, and has both high applicability and scalability.

[0113] 5. Breaking through traditional limitations: Compared with existing technologies, this invention does not rely on known attack characteristics or static rules, but starts from the terminal's own operating logic to build an interpretable and verifiable security mechanism, providing a brand-new technical approach for terminal security protection.

[0114] In summary, this invention not only enhances the terminal system's ability to defend against complex attacks, but also introduces a novel self-explanatory constraint verification method in the field of terminal security technology, demonstrating significant innovation and practical application value.

Claims

1. A terminal security protection method based on terminal runtime self-explanatory constraint verification, characterized in that, Includes the following steps: Step 1: Construct a terminal operation constraint model. The operation constraint model is used to describe the set of legal operating states of the terminal under normal operating conditions, the state transition relationships, and the security constraints that each state transition must satisfy. Step 2: During terminal operation, continuously collect multi-dimensional system status information related to terminal operation, and construct the current operating status of the terminal based on the system status information; Step 3: When the terminal's operating state changes, generate self-explanatory proof information to describe the rationality of the state change based on the correlation between the previous operating state and the current operating state; Step 4: Perform a consistency check between the self-explanatory proof information and the terminal operation constraint model to determine whether the current operation state and its state evolution process conform to the predefined security constraints; Step 5: When the consistency verification result shows that the current running state does not meet the security constraints, it is determined that the terminal has a security risk, and the corresponding security protection strategy is automatically triggered according to the risk type.

2. The terminal security protection method based on self-explanatory constraint verification during terminal operation according to claim 1, characterized in that, The set of legal operating states refers to the set of states in which the current operating state of the terminal meets predefined security constraints and is verified by the model. A legal state is not the same as the normal operating state of a terminal, but rather the basic state unit that constitutes the normal operating process; the normal operating state of a terminal is composed of a series of legal states and their legal state transition paths.

3. The terminal security protection method based on terminal runtime self-explanatory constraint verification according to claim 1, characterized in that, The multidimensional system state information includes one or more of the following: terminal process running state, system call behavior, memory usage state, file and device access behavior, permission changes, and system resource scheduling information; each state is represented as a state vector. ,in: in, It is in time The collected multidimensional state information vector; subscript An index representing a state object, used to distinguish different processes, threads, or monitored entities; Indicates the first Each process in time The running status characteristics include the process lifecycle state, its scheduling, and resource usage; Indicates the first Each process in time The memory usage characteristics, including memory allocation scale and access behavior; Indicates the first Each process in time The usage status characteristics of system resources, including the usage of CPU, file system, or other system resources.

4. The terminal security protection method based on terminal runtime self-explanatory constraint verification according to claim 1, characterized in that, The terminal operation constraint model is constructed by analyzing historical normal operation data of the terminal. The model is used to characterize the typical state distribution characteristics and state evolution path of the terminal under the condition of no security threat.

5. The terminal security protection method based on terminal operation self-explanatory constraint verification according to claim 1, characterized in that, The self-explanatory proof information includes state transition path information, state change triggering conditions, and corresponding constraint satisfaction information used to explain the source of the current operating state, and is used to prove that the generation process of the current operating state is interpretable and traceable.

6. The terminal security protection method based on terminal operation self-explanatory constraint verification according to claim 5, characterized in that, Self-explanatory proof generation includes: assuming the current state is... The previous legal state was Self-explanatory proof Represented as: in, The conditions that indicate a change in state; Indicates the previous legal state The process behavior, system event, or external operation that occurs and triggers a state change; the preceding valid state serves as a prerequisite for the state change, used to limit the runtime context in which the triggering behavior occurs; Based on the terminal operation constraint model, the system checks whether state changes satisfy predefined state transition conditions. The state transition conditions are used to describe the permission, resource, and time constraints that must be met to allow a state change to occur under a specific legal state. The system ultimately forms a self-explanatory state transition proof that includes the preceding legal state, the triggering reason, and the verification results of the transition conditions, which is used to characterize the verifiable evolution process of the terminal's operating state.

7. The terminal security protection method based on terminal operation self-explanatory constraint verification according to claim 1, characterized in that, The consistency verification process is represented by the following formula: in, The previously established operational constraint model serves as a reference benchmark for the legal operation of the terminal and includes a predefined set of legal states, state transition paths, and corresponding evolution rules. The consistency verification includes at least one of the following: 1) verifying whether the current operating state belongs to the set of legal states; 2) verifying whether the state transition path conforms to the predefined evolution rules; 3) verifying whether the security constraints are satisfied during the state change process.

8. The terminal security protection method based on terminal runtime self-explanatory constraint verification according to claim 1, characterized in that, When the consistency check result indicates an anomaly, the security protection strategy includes one or more of the following: 1) Restrict system resource access permissions for abnormal processes; 2) Isolate operational entities that pose a risk; 3) Prevent the abnormal state from evolving further; 4) Roll back the terminal's operating state to the most recent trusted state; 5) Trigger further security detection and analysis mechanisms.

9. The terminal security protection method based on terminal operation self-explanatory constraint verification according to claim 1, characterized in that, The terminal operation constraint model is initialized during the terminal startup phase and dynamically updated during terminal operation based on the trusted operating state to enhance the model's adaptability to changes in the operating environment.

10. A terminal security protection method based on terminal operation self-explanatory constraint verification according to claim 1, characterized in that, The protection strategy specifically includes the following: Isolate abnormal processes: If an abnormal process is detected, the system will forcibly stop or isolate the abnormal process to prevent it from further compromising system security; Resource access restrictions: For processes that pose a risk, the system will restrict their access to specific system resources; Rollback to a safe state: If the abnormal behavior has a significant impact, the system will restore the terminal to a safe operating state by restoring backups or using snapshot technology; Deep detection: The system initiates a further deep detection mechanism to analyze the root cause of the abnormal state and further determine whether there is a covert attack.

Images