A terminal security protection system, method and server based on an intranet closed security decision server

Abstract

The application discloses a terminal security protection system and method based on an internal network closed security decision server and a server, and relates to the technical field of information security. The system comprises a terminal host, a closed security decision server and a cloud management center. The terminal host collects system behavior events, does not store security detection rules and does not run security decision logic. After receiving events through the internal network, the closed security decision server decrypts the security detection rules stored in ciphertext by using a decryption key in a security module, then performs real-time risk analysis based on the decrypted rules by using security decision logic, generates a security response instruction and returns the same to the terminal host for execution, and generates a trusted state report and reports the same to the cloud management center to verify whether firmware and configuration are tampered with. The center generates a detection rule update package and distributes the same to the server. In this way, the problems that detection rules are easy to be reversed and terminals are trapped in the traditional scheme, that is, detection is invalid, can be solved, and real-time decision capability can be ensured.

Description

Technical Field

[0001] This invention belongs to the field of information security technology, specifically relating to a terminal security protection system, method, and server based on an intranet-based closed security decision server. Background Technology

[0002] With the development and popularization of information technology, network attack methods are becoming increasingly diversified, and endpoint security protection has become an important issue in the field of information security.

[0003] Currently, endpoint security protection systems generally adopt an "endpoint-cloud" collaborative architecture. The endpoint deploys a security client containing an event collection module, a local detection engine, a feature rule base, and a response execution module. The cloud side is responsible for threat intelligence aggregation, malicious sample analysis, detection model updates, and policy management. Under this architecture, security detection rules and decision-making logic reside locally on the endpoint. The endpoint can perform real-time analysis of system behavior events based on the local rule base and respond accordingly, thereby meeting the millisecond-level timeliness requirements of attack scenarios such as ransomware encryption, memory injection, and process hijacking.

[0004] However, the existing architecture has a fundamental flaw: security detection rules and decision-making logic reside on the endpoint. Once an attacker compromises the endpoint through reverse engineering, memory analysis, or debugging, they can extract the detection rules and analysis logic, and then construct targeted bypass schemes. With the widespread adoption of automated analysis tools and the application of large language models in the field of network security attacks, attackers can use large language models to automatically analyze the binary structure of endpoint security clients, identify encryption algorithms, and extract keys, thereby obtaining detection rules in batches and significantly reducing reverse engineering costs. Once the endpoint is compromised, the local detection engine can be directly tampered with or disabled, rendering endpoint-side security protection ineffective.

[0005] While migrating the security detection decision-making logic entirely to the cloud can protect detection rules from reverse engineering on the terminal side to some extent, wide area network communication suffers from issues such as network jitter, bandwidth limitations, and routing latency, making it impossible for cloud-based decisions to meet millisecond-level real-time response requirements. Therefore, the traditional "end-cloud" collaborative architecture struggles to balance security and real-time performance.

[0006] In summary, there is an urgent need for a new endpoint security architecture that can protect security detection rules from being obtained by attackers while meeting the requirements for millisecond-level real-time response. Summary of the Invention

[0007] The application aims to provide a terminal security protection system and method based on an internal network closed security decision server and a closed security decision server, so as to solve the problems of the existing terminal security protection architecture, i.e., the security detection rules and decision logic residing in the terminal are easy to be attacked and / or the "end-cloud" collaborative architecture is difficult to balance between security and real-time performance.

[0008] In order to achieve the above-mentioned purpose, the application adopts the following technical solutions: In a first aspect, the application provides a terminal security protection system based on an internal network closed security decision server, which comprises a terminal host deployed on a user side, a closed security decision server provided by a vendor in a standardized hardware device and deployed in an internal network of the user, and a cloud management center deployed on a vendor side, wherein the closed security decision server is internally provided with a security module and only exposes a specified service interface, the security module is used to generate and manage a decryption key which cannot be exported from the module, and the user has no system login permission and data access permission for the closed security decision server through any way other than the specified service interface. The terminal host is configured to collect system behavior events and execute security response instructions, and does not store security detection rules and does not run security decision logic for performing risk analysis and response decision. The closed security decision server is configured to run a vendor-specific security operation code and the security decision logic above the security operation code, to decrypt the security detection rules stored in ciphertext form in the internal network through the specified service interface after receiving the system behavior events collected by the terminal host, to perform real-time risk analysis on the system behavior events based on the decrypted security detection rules through the security decision logic, to generate security response instructions and return them to the terminal host for execution, and to generate a trusted state report based on the state of the security operation code and the security decision logic and periodically report it to the cloud management center. The cloud management center is configured to receive the trusted state report and verify whether the firmware and configuration of the closed security decision server are tampered with, to generate a security detection rule update package and distribute it to the closed security decision server through a special management channel, so that the closed security decision server receives and updates the locally stored security detection rules.

[0009] Based on the above invention content, a new terminal security protection architecture is provided, that is, the system includes a terminal host, a closed security decision server and a cloud management center, wherein the closed security decision server is internally provided with a security module and only exposes a specified service interface, the security module is used to generate and manage a decryption key which cannot be exported from the module, and a user has no system login permission and data access permission for the closed security decision server; the terminal host collects system behavior events and executes security response instructions, does not store security detection rules and does not run security decision logic; the closed security decision server runs security operation code and security decision logic, after receiving events through an intranet, the security detection rules stored in ciphertext are decrypted by using the decryption key in the security module, then real-time risk analysis is performed based on the decrypted rules by the security decision logic, security response instructions are generated and returned to the terminal host for execution, and at the same time, a trusted state report is generated based on the state of the security operation code and the security decision logic and is periodically reported to the cloud management center; the cloud management center receives the trusted state report and verifies whether the firmware and configuration of the closed security decision server are tampered with, and generates a security detection rule update package and distributes it to the closed security decision server through a special management channel, so that by separating the security detection decision logic from the terminal host and encapsulating it in the intranet closed security decision server which is inaccessible to users, the problem of easy reverse of detection rules and terminal submersion in traditional solutions is solved, and at the same time, the millisecond-level real-time decision capability is ensured through intranet deployment, which is convenient for practical application and promotion.

[0010] In one possible design, the closed security decision server completely disables system-level operation and maintenance interfaces, wherein the system-level operation and maintenance interfaces include a secure shell protocol interface, a remote desktop protocol interface, a serial port, a remote login protocol interface, a file transfer protocol interface, a secure file transfer protocol interface and a local command line terminal. The specified service interface refers to a Web management interface whose function range is limited to network parameter configuration, network connectivity test and basic state viewing.

[0011] In one possible design, the login password of the Web management interface is generated by a cryptographic secure random number generator of the cloud management center every day, and is synchronized to the closed security decision server through an encrypted channel of two-way TLS authentication, wherein the validity period of the login password is a first preset time length, and the login password is automatically invalidated after the validity period. All login behaviors of the Web management interface are recorded in audit logs and uploaded to the cloud management center.

[0012] In a possible design, the closed security decision server is further provided with a network disconnection self-destruction mechanism, where the network disconnection self-destruction mechanism includes: the closed security decision server and the cloud management center perform a handshake every second preset time interval to verify the device identity and the synchronization state; when the closed security decision server fails to successfully perform the handshake with the cloud management center for more than a third preset time interval continuously, the closed security decision server automatically clears all the security detection rules and the decryption key stored locally, and enters a continuous reconnection state until the complete rule package is downloaded from the cloud management center after a successful rehandshake.

[0013] In a possible design, the closed security decision server is further provided with a geographic location exception self-destruction mechanism, where the geographic location exception self-destruction mechanism includes: real-time monitoring of geographic location information of a server out-of-network IP address; when a deviation of a current geographic location from a historical reference location is detected to be greater than a preset threshold, the closed security decision server automatically clears all the security detection rules stored locally and enters a security locking mode; in the security locking mode, any rule-related operation is prohibited until a manual review is passed.

[0014] In a possible design, the cloud management center is further configured to: when receiving an event notification sent by the closed security decision server when triggering a rule clearing event, or when determining that the closed security decision server triggers a rule clearing event, automatically sending an alarm email to a preset customer reservation mailbox, and pushing an emergency event notification to a vendor security operation center.

[0015] In a possible design, the closed security decision server is further configured to, after generating the trusted state report, sign the trusted state report by the security module, and send the signed trusted state report to the cloud management center, so that the cloud management center verifies the signature of the trusted state report, and confirms that the firmware and configuration of the closed security decision server are not tampered with after the verification is passed.

[0016] In a possible design, the closed security decision server is further configured to generate a security event by the security decision logic, and report the security event to the cloud management center. The cloud management center is further configured to receive the security event, and store and analyze the security event.

[0017] In a possible design, the security detection rule update package is distributed after being digitally signed by the cloud management center, and the closed security decision server verifies the digital signature after receiving the security detection rule update package, and updates the security detection rules stored locally only after the verification is passed.

[0018] In a possible design, the terminal host and the closed security decision server communicate through an intranet RPC, where the intranet RPC adopts an HTTPS protocol based on bidirectional TLS authentication, and data serialization adopts a Protocol Buffers protocol.

[0019] In a possible design, the decryption operation of the security detection rule is performed inside the security module, the decrypted plaintext security detection rule does not leave the security module, and real-time risk analysis based on the plaintext security detection rule is completed inside the security module through the security decision logic.

[0020] In a second aspect, the present application provides a terminal security protection method based on an intranet closed security decision server, which is applied to a terminal host deployed on a user side, a closed security decision server provided by a vendor in a standardized hardware device and deployed in an internal network of the user, and a cloud management center deployed on a vendor side, where the closed security decision server is internally provided with a security module and only exposes specified service interfaces, the security module is used to generate and manage a decryption key that cannot be exported from the module, and the user has no system login permission and data access permission for the closed security decision server through any way other than the specified service interfaces. The terminal security protection method includes the following steps: The terminal host collects system behavior events, and then sends the system behavior events to the closed security decision server through the specified service interfaces and an intranet, where the terminal host does not store security detection rules and does not run security decision logic used to perform risk analysis and response decision. After receiving the system behavior events, the closed security decision server first decrypts the security detection rules stored in a ciphertext form inside the security module by using the decryption key in the security module, and then performs real-time risk analysis on the system behavior events based on the decrypted security detection rules by using a vendor-specific security operation code and the security decision logic running on the security operation code, generates a security response instruction, and returns the security response instruction to the terminal host. The terminal host executes the security response instruction returned. The closed security decision server generates a trusted state report based on the state of the security operation code and the security decision logic, and periodically reports the trusted state report to the cloud management center. The cloud management center receives the trusted state report and verifies whether firmware and configuration of the closed security decision server are tampered. The cloud management center generates a security detection rule update package and distributes it to the closed security decision server through a special management channel; The closed security decision server updates the locally stored security detection rules according to the security detection rule update package after receiving the security detection rule update package.

[0021] In a third aspect, the application provides a closed security decision server provided by a vendor in a standardized hardware device and deployed in a user's internal network, which is internally provided with a security module and only exposes a specified service interface, wherein the security module is used to generate and manage a decryption key that cannot be exported from the module, and the user has no system login permission and data access permission for the closed security decision server through any way other than the specified service interface; The closed security decision server is configured to: run a security operation code specific to the vendor and a security decision logic above the security operation code and used to perform risk analysis and response decision; After receiving a system behavior event collected by an external terminal host through the specified service interface and the internal network, the security detection rules stored in ciphertext form in the internal network are first decrypted using the decryption key in the security module, and then real-time risk analysis is performed on the system behavior event based on the decrypted security detection rules through the security decision logic, security response instructions are generated and returned to the terminal host for execution, wherein the terminal host is deployed on the user side and does not store security detection rules and does not run the security decision logic; A trusted state report is generated based on the state of the security operation code and the security decision logic and is periodically reported to an external cloud management center, so that the cloud management center receives the trusted state report and verifies whether the firmware and configuration of the closed security decision server are tampered with, wherein the cloud management center is deployed on the vendor side; After receiving a security detection rule update package generated by the cloud management center and distributed through a special management channel, the locally stored security detection rules are updated according to the security detection rule update package.

[0022] The above-mentioned scheme has the following beneficial effects: (1) This invention provides a novel terminal security protection architecture, namely, the system includes a terminal host, a closed security decision server, and a cloud management center. The closed security decision server has a security module inside and only exposes designated service interfaces. The security module is used to generate and manage decryption keys that cannot be exported. Users do not have system login permissions or data access permissions to the closed security decision server. The terminal host collects system behavior events and executes security response instructions, but does not store security detection rules or run security decision logic. The closed security decision server runs security operation code and security decision logic. After receiving events through the intranet, it uses the decryption key in the security module to decrypt the encrypted security detection rules, and then the security decision is executed. The logic performs real-time risk analysis based on decryption rules, generates security response instructions, and sends them back to the terminal host for execution. Simultaneously, it generates a trusted status report based on the status of the security operation code and security decision logic, and periodically reports it to the cloud management center. The cloud management center receives the trusted status report, verifies whether the firmware and configuration of the closed security decision server have been tampered with, and generates a security detection rule update package, which is then distributed to the closed security decision server through a dedicated management channel. By separating the security detection decision logic from the terminal host and encapsulating it within a closed security decision server on the internal network that is inaccessible to users, the problem of easily reverse-engineered detection rules and detection failure due to terminal compromise, found in traditional solutions, is solved. Furthermore, the internal network deployment ensures millisecond-level real-time decision-making capabilities. (2) By completely separating the security detection rules and security decision logic from the terminal host and encapsulating them in a closed security decision server on the internal network that is inaccessible to users, the terminal host is only used as an event sensor and response executor. Even if the terminal host is completely controlled by the attacker, the attacker cannot obtain any security detection rules or security decision logic through reverse analysis, memory extraction or file system scanning, which fundamentally solves the technical problem that the detection rules reside on the terminal in the traditional "end-cloud" collaborative architecture and are easily extracted by reverse engineering. (3) By using the hardware-level protection of the decryption key by the internal security module of the closed security decision server and the security boundary design of the internal decryption and analysis of the security module, the decryption key and the plaintext security detection rules after decryption never leave the hardware protection boundary of the security module. Even if the attacker gains physical control of the closed security decision server and disassembles the storage medium, he will not be able to extract the key or plaintext rules, thus realizing the non-extraction of security detection rules and the non-tamperability of security decision logic. (4) By deploying the closed security decision server in the user's internal network and communicating with the terminal host through the internal network, the security detection decision process does not depend on the wide area network, and the internal network communication delay can be controlled within the millisecond level. While ensuring the security of the detection rules and decision logic, the millisecond-level real-time response requirement of ransomware encryption, memory injection and other attack scenarios is met, and the fundamental contradiction between security and real-time performance in the traditional architecture is solved; (5) By implementing user zero permission management for the closed security decision server - completely disabling all system-level operation and maintenance interfaces and exposing only a function-limited Web management interface, the possibility of user-side personnel accessing, extracting or tampering with internal security data and logic of the server is eliminated from the management level, making the closed security decision server a secure decision hub that is physically and logically inviolable, and even if the internal personnel with legal physical access rights cannot obtain or tamper with the detection rules; (6) Through the dual defense of the network self-destruction mechanism and the geographical location abnormal self-destruction mechanism, when the closed security decision server is disconnected from the cloud or the device is physically moved out of the authorized area, the local security detection rules and decryption keys are automatically emptied, extending the security protection from the network level to the physical level and the supply chain security dimension, so that sensitive data is automatically destroyed when the device is stolen, illegally transferred or subjected to extreme network attacks, effectively preventing offline attacks and physical theft; (7) Through the digital signature verification mechanism of the security detection rule update package and the security module signature verification mechanism of the trusted state report, the authenticity of the rule update package source and the integrity of the content, the authenticity of the trusted state report and the unforgeability are ensured, preventing man-in-the-middle attacks and data tampering in the rule distribution and remote proof process, and building an end-to-end trusted chain from the cloud to the server end; (8) By generating security events based on risk analysis results and reporting them to the cloud management center for centralized storage and analysis, manufacturers and customers can be informed of the security threats that have occurred or are occurring in a timely manner, realizing a closed loop from single-point real-time protection to global security operation, and providing data support for deep investigation, traceability analysis and emergency response decision of security events; (9) Through the continuous verification of the closed security decision server trusted state report by the cloud management center and the double-path alarm notification mechanism of the rule emptying event - including the closed security decision server actively reporting event notification and the cloud self-determining two paths - a complete security operation closed loop of "event triggering → sensing reporting → alarm notification → manual intervention → event disposal" is formed, ensuring that security events are perceptible, responsive and traceable; (10) The terminal host and the closed security decision server adopt the HTTPS protocol based on two-way TLS authentication and the Protocol Buffers serialization protocol for intranet RPC communication, which ensures the communication link two-way identity authentication and transmission data encryption, and reduces the serialization overhead in the form of binary efficient coding, ensuring the communication delay requirement of millisecond-level real-time detection response; (11) Since the closed security decision server is operated by the manufacturer and has no user permission, the update of the security detection rule, the upgrade of the security decision logic, and the adjustment of the security policy are all initiated by the manufacturer through the cloud management center and the special management channel, and the whole update process is transparent to the user, and the user cannot intervene or block, realizing the continuous evolution and centralized control of the detection capability; (12) Through the stateless design of the terminal host, which does not store security detection rules and does not run security decision logic, the security agent program on the terminal host can remain standardized and lightweight, without frequent changes due to rule updates, reducing the operation complexity and performance overhead on the terminal side, and the compromise of the terminal host only affects the event collection and execution of a single point, without causing global transparency of the detection system, facilitating practical application and promotion. BRIEF DESCRIPTION OF DRAWINGS

[0023] In order to more clearly illustrate the technical solutions of the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or the prior art description. Obviously, the drawings in the following description only constitute some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor on the basis of these drawings.

[0024] Figure 1 The structure schematic diagram of the terminal security protection system based on the intranet closed security decision server provided by the embodiments of the present application.

[0025] Figure 2 The flowchart of the terminal security protection method based on the intranet closed security decision server provided by the embodiments of the present application. DETAILED DESCRIPTION

[0026] In order to more clearly illustrate the technical solutions of the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or the prior art description. Obviously, the drawings in the following description only constitute some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor on the basis of these drawings.

[0027] It should be understood that, although the terms first and second, etc. can be used herein to describe various objects, these objects should not be limited by these terms. These terms are only used to distinguish one object from another. For example, a first object can be referred to as a second object, and similarly, a second object can be referred to as a first object, without departing from the scope of the example embodiments of the present application.

[0028] It should be understood that, for the term "and / or" which can appear in the present text, it is only a description of the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B, which can represent three cases of A alone, B alone, or A and B together; for example, A, B and / or C, which means that any one of A, B and C or any combination thereof exists; for the term " / and" which can appear in the present text, it is another description of the relationship of another associated object, which means that there can be two relationships, for example, A / and B, which can represent two cases of A alone or A and B together; in addition, for the character " / " which can appear in the present text, it generally represents an "or" relationship between the associated objects before and after it.

[0029] Embodiment one As Figure 1 shown, the terminal security protection system based on the internal network closed security decision server provided by the embodiment includes, but is not limited to, a terminal host deployed on the user side, a closed security decision server provided by the manufacturer in a standardized hardware device and deployed in the internal network of the user, and a cloud management center deployed on the manufacturer side.

[0030] The terminal host can be, but is not limited to, a personal computer, a server, a virtual machine or other terminal device with computing ability on the user side, and its hardware platform at least includes a processor, a memory and a network interface, which are used to run an operating system and an application program. A lightweight security agent program is installed on the terminal host, which is only responsible for the collection of system behavior events and the execution of security response instructions, and does not contain any security detection rule library or security decision logic engine.

[0031] The closed security decision server is a core security decision node of the terminal security protection system, and a hardware platform of the closed security decision server at least includes a processor, a memory, a network interface, a security module and the like. The security module can be but is not limited to a Trusted Platform Module (TPM) security chip or a Trusted Execution Environment (TEE) based on a processor security extension and the like hardware security technology. The closed security decision server runs a proprietary security operation code customized and hardened by a vendor, and the security operation code provides basic operating system level functions for the closed security decision server, and at the same time completely disables all user-oriented system level operation and maintenance interfaces from a software level. The closed security decision server only exposes a specified service interface for intranet communication with the terminal host.

[0032] A hardware platform of the cloud management center can be but is not limited to a standalone physical server, a server cluster or a cloud service platform. The cloud management center is responsible for generation and management of security detection rules, distribution of security detection rule update packages, and verification of trusted state reports reported by the closed security decision server. The cloud management center and the closed security decision server communicate through a dedicated management channel, which is independent of the specified service interface exposed by the closed security decision server to the terminal host, for ensuring security and independence of data interaction at a management level.

[0033] The closed security decision server is internally provided with the security module and only exposes the specified service interface. The security module is used to generate and manage a decryption key that cannot be exported from the module, and a user has no system login permission and data access permission for the closed security decision server through any way other than the specified service interface. Under the above hardware architecture, the security module is internally provided with independent key generation and management logic, and the decryption key can be generated when the closed security decision server is started for the first time or in a vendor initialization phase. A private key part of the decryption key is only stored in a protected storage area inside the security module, and is invisible, unreadable and unexportable to the outside. Even if physical control of the closed security decision server is obtained and a storage medium is disassembled, the decryption key cannot be extracted. The security module only provides a decryption service interface to a specified process inside the closed security decision server, and does not expose the key itself, thereby realizing hardware level protection of the key.

[0034] The specified service interface refers to a network service port that is uniquely opened by the closed security decision server to the user side, and is used to receive security detection requests from the terminal host. The closed security decision server completely disables all system-level operation and maintenance interfaces, including but not limited to Secure Shell protocol interface, Remote Desktop Protocol interface, serial port, Remote Login Protocol interface, File Transfer Protocol interface, Secure File Transfer Protocol interface, and local command line terminal, etc., from the software level by running the vendor's proprietary security operation code, so that the user cannot log in to the operating system of the closed security decision server through any remote or local way, nor can access the file system or memory space thereof. The closed security decision server only retains a function-limited Web management interface, the function range of which is strictly limited to network parameter configuration, network connectivity test, and basic state viewing, etc., without providing any operation options related to security detection rules or security decision logic. Through the above-mentioned "user zero permission" design, the possibility of user-side personnel accessing, extracting or tampering with server internal security data and logic is eliminated from the management level, so that the closed security decision server becomes a secure decision hub that is physically and logically inviolable in the user network.

[0035] The terminal host is configured to collect system behavior events and execute security response instructions, and does not store security detection rules and does not run security decision logic for performing risk analysis and response decision. Specifically, a lightweight security agent program is installed on the terminal host. In the event collection layer, the security agent program can achieve comprehensive collection of system behavior events through, but not limited to, the following ways (A1) and (A2): (A1) At the kernel level, process creation and exit behaviors and their context information (including process identification, parent process identification, command line parameters, user token, and permission level, etc.) are captured in real time through a process callback function (such as PsSetCreateProcessNotifyRoutineEx provided by Windows operating system); registry item and key value creation, modification, deletion, and renaming operations are captured through a registry callback function (such as CmRegisterCallbackEx); file opening, reading, writing, deleting, and renaming operations in the file system are captured based on a file system micro-filter driver framework (such as Minifilter); Transmission Control Protocol / User Datagram Protocol (TCP / UDP) network connection behaviors and Domain Name System (DNS) query requests are captured through a network filter driver or a network event monitoring mechanism; (A2) At the user state level, the call behavior of sensitive application programming interface (API) is monitored through the Inline Hook technology.

[0036] The combination of the above collection methods enables the security agent to obtain multi-dimensional system behavior events on the terminal host, including process behavior, registry operation, file system operation, network connection behavior, and API call behavior. At the response execution level, the security agent receives security response instructions from the closed security decision server and executes corresponding handling actions according to the instruction type, including but not limited to: terminating a specified process, isolating a specified file, blocking a specified network connection, alerting, or recording audit logs.

[0037] The core feature of the terminal host distinguished from the terminal security client in the traditional "end-cloud" collaborative architecture is that the terminal host does not store any form of security detection rules (including but not limited to characteristic code rule library, YARA rule set, and behavior detection rule library, etc.), nor does it run security decision logic (including but not limited to local detection engine, heuristic analysis module, and machine learning detection model, etc.) for risk analysis and response decision. In other words, the security agent on the terminal host only acts as an event sensor and response executor, and does not have any independent security analysis and judgment capability. Even if the terminal host is completely controlled by an attacker, the attacker cannot obtain any security detection rules or security decision logic from the terminal host through reverse analysis, memory extraction, or file system scanning.

[0038] The closed security decision server is configured to run vendor-specific security operation code and the security decision logic above the security operation code. After receiving the system behavior events collected by the terminal host through the specified service interface and the internal network, the security module is used to decrypt the security detection rules stored in ciphertext form, and then the security decision logic is used to perform real-time risk analysis on the system behavior events based on the decrypted security detection rules, generate security response instructions, and return them to the terminal host for execution. Based on the state of the security operation code and the security decision logic, a trusted state report is generated and periodically reported to the cloud management center.

[0039] Specifically, at the software architecture level, the closed security decision server adopts a layered design. The bottom layer is the vendor-specific security operation code, which is an operating system level software customized and hardened by the vendor, only retaining the core functional modules related to security detection and communication, removing all unnecessary system services and applications, thereby reducing the attack surface at the source. On top of the security operation code runs the security decision logic, which is the core application layer component that performs risk analysis and response decision, based on the received system behavior events and security detection rules, it conducts comprehensive analysis and threat determination on the system behavior events. The security operation code provides a protected running environment for the security decision logic, ensuring the code integrity and execution process of the security decision logic are not tampered with.

[0040] Specifically, at the level of real-time detection process, the terminal host and the closed security decision server communicate through the designated service interface and via the intranet, which can be implemented by Hypertext Transfer Protocol Secure (HTTPS) based on two-way Transport Layer Security (TLS) authentication, and the data serialization adopts Protocol Buffers (Protobuf) protocol, so as to ensure the communication security while taking into account the transmission efficiency, and ensure that the intranet communication delay can be controlled within the range that meets the millisecond-level real-time response requirement. When the closed security decision server receives the system behavior event collected by the terminal host through the designated service interface, it first reads the security detection rule stored in the form of ciphertext from the internal storage. The security detection rule always exists in the form of ciphertext on the static storage medium (such as hard disk or solid state disk) inside the closed security decision server, and is encrypted and protected by symmetric encryption algorithm such as Advanced Encryption Standard (AES). The closed security decision server calls the decryption service interface provided by the security module, and transmits the security detection rule in the form of ciphertext into the security module; the security module uses the decryption key stored in the internal storage to decrypt the security detection rule in the protected area inside the security module, and retains the decrypted plaintext security detection rule inside the security module. Subsequently, the security decision logic running on the security operation code is called, and the system behavior event is analyzed in real time based on the decrypted security detection rule. The process of real-time risk analysis includes but is not limited to: matching the system behavior event with the behavior characteristics in the security detection rule, determining whether there is malicious behavior or abnormal behavior according to the matching result, and generating corresponding security response instructions. The type of security response instruction is determined according to the analysis result, which can include but is not limited to: pass instruction (when the event is determined to be a safe behavior), blocking instruction (when the event is determined to be a malicious behavior), isolation instruction (when the event is determined to be a suspicious behavior) or alarm instruction (when the administrator needs to be notified). The closed security decision server returns the generated security response instruction to the terminal host through the designated service interface and via the intranet, and the security agent program on the terminal host is responsible for execution.

[0041] Preferably, in order to realize centralized management of security incidents and global security situation awareness, the closed security decision server is further configured to generate a security incident based on the real-time risk analysis result of the system behavior event by the security decision logic, and report the security incident to the cloud management center; the cloud management center is further configured to receive the security incident and store and analyze the security incident. Specifically, when the security decision logic determines that a system behavior event or a sequence of events constitutes a security threat (such as detecting malicious software execution, vulnerability exploitation attempt, data leakage behavior or internal abnormal operation, etc.), a structured security incident record is generated. The security incident record can include but is not limited to the following information: event identification, event type (such as malware, intrusion attempt, data leakage, policy violation, etc.), threat level (such as severe, high risk, medium risk, low risk), system behavior event details triggering the event, affected host identification, event generation timestamp, and recommended handling measures, etc. The closed security decision server reports the generated security incident to the cloud management center in real time or quasi-real time through the dedicated management channel. The cloud management center centrally stores the security incidents received from each closed security decision server, and displays the overall security situation of the internal network to the manufacturer security operation team and / or the customer through correlation analysis, trend statistics and visual dashboard, etc. Through the foregoing security incident reporting and centralized management mechanism, the manufacturer and the customer can timely learn about the security threats that have occurred or are occurring, and provide data support for in-depth investigation, traceability analysis and emergency response decision of security incidents.

[0042] Specifically, at the remote attestation level, the closed security decision server is configured to periodically generate and report a trusted state report to the cloud management center. The generation basis of the trusted state report includes the state of the security operation code and the security decision logic, i.e. integrity measurement of the code segment of the security operation code, the key configuration file and the code segment of the security decision logic. Specifically, the security module can measure the security operation code and the security decision logic during the startup process of the closed security decision server, and store the measurement value in the platform configuration register (PCR) inside the security module; when reporting, the security module signs the trusted state report containing the measurement value to generate a signed trusted state report. The closed security decision server periodically reports the signed trusted state report to the cloud management center, and the reporting period can be configured according to the security policy, for example, reporting once every 60 seconds. After the cloud management center receives the trusted state report, it first verifies the signature, and after the signature verification is passed, it compares the measurement value in the report with the known trusted baseline value; if the comparison is consistent, it is confirmed that the firmware and configuration of the closed security decision server have not been tampered with, and the trust relationship with the closed security decision server is maintained; if the comparison is inconsistent, it indicates that the closed security decision server may have been tampered with, triggering the corresponding security alarm.

[0043] The cloud management center is configured to receive the trusted state report and verify whether the firmware and configuration of the closed security decision server have been tampered with; generate a security detection rule update package and distribute it to the closed security decision server through a dedicated management channel, so that the closed security decision server receives and updates the locally stored security detection rule.

[0044] Specifically, at the level of trusted state verification, the cloud management center receives the trusted state report signed by the closed security decision server periodically. The cloud management center maintains the device certificate and the corresponding public key infrastructure (PKI) trust chain of the closed security decision server. First, the signature of the trusted state report is verified by the public key to confirm that the trusted state report indeed comes from the legitimate closed security decision server and has not been tampered with during transmission. After the signature verification passes, the cloud management center compares the measurement value contained in the trusted state report with the trusted baseline value stored in the cloud management center database; the trusted baseline value is the baseline measurement value generated by the manufacturer when the closed security decision server is shipped or in a trusted state and uploaded to the cloud management center; if the measurement value is consistent with the trusted baseline value, it is confirmed that the security operation code, the security decision logic and the key configuration file of the closed security decision server have not been tampered with, and the trust relationship with the closed security decision server is maintained; if the comparison is inconsistent, it indicates that the closed security decision server may have been tampered with, and the cloud management center triggers a corresponding security alarm and can send an alarm email to a pre-set customer reservation mailbox or push an emergency event notification to the manufacturer's security operation center.

[0045] Specifically, at the rule update level, the cloud management center undertakes the centralized generation, management, and distribution of security detection rules. The cloud management center gathers the latest threat information from threat intelligence platforms, malicious sample sandbox analysis systems, and security research teams, continuously generating and updating the security detection rules. When a new security detection rule is generated, the cloud management center packages the updated security detection rule into a security detection rule update package and digitally signs the package to ensure the source authentication and content integrity of the rule package. The cloud management center distributes the digitally signed security detection rule update package to the closed security decision server through the dedicated management channel. The dedicated management channel is independent of the designated service interface exposed by the closed security decision server to the terminal host. It can be established based on, but is not limited to, the HTTPS protocol with bidirectional TLS authentication, and can be used in conjunction with hardware isolation devices such as physical one-way optical gates to ensure the physical or logical one-wayness and isolation of the management channel, preventing lateral penetration of the management channel via the terminal network side. Upon receiving the security detection rule update package, the closed-loop security decision server first verifies its digital signature. If the verification is successful, it uses the decryption key in the security module to decrypt the encrypted rules in the security detection rule update package and updates the decrypted security detection rules to local storage, completing the rule replacement. The entire rule update process is transparent to the user, who cannot interfere or block it.

[0046] Based on the aforementioned detailed description of the endpoint security protection system, a new endpoint security protection architecture is provided. The system includes a terminal host, a closed security decision server, and a cloud management center. The closed security decision server contains a security module that exposes only designated service interfaces. This security module generates and manages decryption keys that cannot be exported. Users do not have system login or data access permissions to the closed security decision server. The terminal host collects system behavior events and executes security response instructions, but does not store security detection rules or run security decision logic. The closed security decision server runs security operation code and security decision logic. After receiving events via the intranet, it uses the decryption key in the security module to decrypt the encrypted security detection rules, which are then processed by the security system. The decision-making logic performs real-time risk analysis based on decryption rules, generates security response instructions, and sends them back to the terminal host for execution. Simultaneously, it generates a trusted status report based on the security operation code and the state of the security decision-making logic, and periodically reports it to the cloud management center. The cloud management center receives the trusted status report, verifies whether the firmware and configuration of the closed security decision server have been tampered with, and generates a security detection rule update package, which is then distributed to the closed security decision server through a dedicated management channel. By separating the security detection decision-making logic from the terminal host and encapsulating it within a closed security decision server on an internal network inaccessible to users, the traditional solution solves the problems of easily reverse-engineered detection rules and detection failure due to terminal compromise. Furthermore, the internal network deployment ensures millisecond-level real-time decision-making capabilities, facilitating practical application and promotion.

[0047] Preferably, in order to prevent unauthorized access to the Web management interface, the login password for the Web management interface is generated daily by the cloud management center using a cryptographically secure random number generator and synchronized to the closed security decision server through a two-way TLS-certified encrypted channel. The login password is valid for a first preset period of time and automatically expires upon expiration. All login activities on the Web management interface are recorded in audit logs and uploaded to the cloud management center.

[0048] Specifically, at the password generation level, the cloud management center is equipped with a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG). This CSPRNG automatically generates a set of random strings with sufficient entropy (e.g., at least 128 bits) daily at a set time (e.g., midnight) as the login password for the web management interface. Using a Cryptographically Secure Pseudo-Random Number Generator instead of a regular pseudo-random number generator ensures the generated password is unpredictable and can resist predictive attacks targeting the password generation algorithm.

[0049] Specifically, at the password synchronization level, the cloud management center and the closed security decision server synchronize passwords via a bidirectional TLS-certified encrypted channel. This bidirectional TLS authentication requires both parties—the cloud management center and the closed security decision server—to each present a valid device certificate issued by the manufacturer. An encrypted communication link is established only after both parties verify the validity of each other's certificates. This mechanism effectively prevents man-in-the-middle attacks, ensuring that passwords are not stolen or tampered with during transmission from the cloud management center to the closed security decision server. After password synchronization is complete, the closed security decision server stores the login password for the day in the protected storage area of ​​the security module, which is inaccessible externally.

[0050] Specifically, regarding password usage and expiration, the login password is valid for a first preset duration, which can be configured according to security policies, such as 12 hours, 24 hours, or 48 hours, with a default of 24 hours. Within the validity period, users can perform basic operations such as network parameter configuration by entering the daily login password through the web management interface. After the validity period expires, the login password automatically becomes invalid, and even if the correct password for the day is entered, login will not be possible. After the password expires, users must wait for the cloud management center to generate and synchronize a new login password the following day before they can log in again. The password synchronization process is automatically completed by the cloud management center, requiring no manual operation from the user. Through the mechanism of automatically rotating passwords daily, even if a login password for a particular day is accidentally leaked, the leaked password will become invalid within a maximum of 24 hours, thereby controlling the security risk window caused by password leakage within a very short time frame.

[0051] Specifically, at the access audit level, all login behaviors on the web management interface—including but not limited to login time, login source Internet Protocol (IP) address, login success or failure status, and performed operations—are recorded as audit logs by the closed security decision server. These audit logs are uploaded to the cloud management center in real-time or near real-time for centralized storage and analysis. The cloud management center can monitor abnormal login behaviors (such as multiple consecutive login failures, logins at unusual times, or logins from unusual IP addresses) based on the audit logs and trigger security alerts when abnormal behavior is detected. Through the above audit and alert mechanisms, even if an attacker obtains a valid login password for the day through some means, their login behavior will be fully recorded and traceable, thus providing data support for post-event security audits and source tracing analysis.

[0052] Through the coordinated efforts of the four stages of password generation, password synchronization, password validity management, and access auditing, refined access control of the Web management interface is achieved, ensuring that the only user-accessible entry point of the closed security decision server is always under the dynamic control of the cloud management center, and users cannot log in or operate the closed security decision server without authorization from the cloud.

[0053] Preferably, to prevent the theft or misuse of sensitive data on the server after losing connection with the cloud, the closed security decision server is also equipped with a self-destruct mechanism for network disconnection. The self-destruct mechanism for network disconnection includes, but is not limited to: the closed security decision server and the cloud management center perform a handshake every second preset time interval to verify the device identity and synchronization status; when the closed security decision server fails to successfully handshake with the cloud management center for more than a third preset time interval, it automatically clears all the security detection rules and decryption keys stored locally and enters a continuous reconnection state until the handshake is successfully re-established and the complete rule package is downloaded again from the cloud management center.

[0054] Specifically, under normal communication conditions, the closed-loop security decision server and the cloud management center maintain periodic handshake interactions. The handshake occurs every second preset time interval, which can be configured according to network security environment and management needs, such as 30 seconds, 60 seconds, or 120 seconds, with a default setting of 60 seconds. During each handshake, the closed-loop security decision server sends a handshake request to the cloud management center. This request carries the closed-loop security decision server's device certificate, device fingerprint, the version number of the currently stored security detection rules, and device operating status information (including processor usage, memory usage, disk usage, and network connection status). The cloud management center receives and verifies the handshake request. After confirming that the closed-loop security decision server's device identity is legitimate and its status is normal, it returns a handshake success response. Through this periodic handshake mechanism, the cloud management center can continuously monitor the online status and operational health of the closed-loop security decision server.

[0055] Specifically, at the network outage determination level, the closed security decision server is equipped with a handshake timeout timer. Whenever the closed security decision server successfully completes a handshake with the cloud management center, the handshake timeout timer automatically resets and restarts. If, due to network link interruption, unreachability of the cloud management center, or network failure of the closed security decision server itself, the closed security decision server fails to successfully handshake with the cloud management center for more than a third preset time period—that is, the handshake timeout timer exceeds the third preset time period—then a network outage self-destruct condition is triggered. The third preset time period can be configured according to security policies, such as 15 minutes, 30 minutes, or 60 minutes, with a default setting of 30 minutes. The setting of the third preset time period must balance security and availability: setting it too short may lead to frequent self-destruction due to temporary network fluctuations, affecting normal business operations; setting it too long may leave a long window for physical attacks.

[0056] Specifically, at the self-destruct execution level, when the network disconnection self-destruction condition is triggered, the closed security decision server automatically performs the following self-destruction actions: First, it calls the file system interface to clear all the security detection rules on the local storage medium using a secure erasure method (such as multiple overwrites followed by deletion), ensuring that the deleted rule files cannot be recovered through data recovery methods; second, it calls the key destruction interface provided by the security module to permanently clear the decryption key stored internally by the security module, so that even if any residual encrypted rule data remains, it becomes invalid data that cannot be decrypted due to the unrecoverable decryption key; third, it clears any temporary data related to security detection that may be cached in memory. After completing the above clearing actions, the closed security decision server enters a "rule vacuum" state. In this state, the closed security decision server only retains basic network communication capabilities and the listening function of the specified service interface, and no longer has any security detection and analysis capabilities.

[0057] Specifically, at the recovery level, after entering a "rule vacuum" state, the closed security decision server continuously attempts to re-establish communication with the cloud management center and initiates handshake requests. Since the closed security decision server has no security detection rules or decryption keys locally at this time, even if an attacker gains physical or network control of the closed security decision server during the network outage, they cannot extract valid security data. When the network is restored or the fault is resolved, the closed security decision server successfully re-handshakes with the cloud management center. After verifying the device identity of the closed security decision server, the cloud management center reissues the complete rule package to the closed security decision server through the dedicated management channel. After receiving and verifying the signature of the rule package, the closed security decision server encrypts and stores it on local storage media, and re-requests the security module to generate or restore the decryption key, thereby restoring complete security detection capabilities. Through the above closed-loop mechanism of "network outage detection → self-destruction and clearing → continuous reconnection → rule restoration," the security of sensitive data in extreme situations is ensured while achieving automatic network recovery without manual on-site intervention.

[0058] Preferably, to prevent the theft of sensitive data on the server after the device is physically moved out of the authorized area, the closed security decision server is also equipped with a geolocation anomaly self-destruct mechanism. The geolocation anomaly self-destruct mechanism includes, but is not limited to: real-time monitoring of the geolocation information of the server's outgoing IP address; when the deviation between the current geolocation and the historical reference location exceeds a preset threshold, automatically clearing all the security detection rules stored locally and entering a security lock mode; in the security lock mode, any operation related to the rules is prohibited until manual review and approval.

[0059] Specifically, the geolocation anomaly self-destruct mechanism is used to defend against the risk of data theft that may occur if the closed-loop security decision server is physically moved to an unauthorized geographical area by an attacker. Under normal operating conditions, whenever the closed-loop security decision server communicates with the cloud management center or accesses the external network through other means, its outbound traffic undergoes network address translation (NAT) via the gateway device of the user's internal network, using the public IP address assigned by the gateway device as the outbound IP address. The closed-loop security decision server maps the outbound IP address to corresponding geographical location information by calling the GeoIP geolocation database or requesting a geolocation resolution service from the cloud management center. The geographical location information may include information of different granularities, such as country, province / state, city, or latitude and longitude coordinates, and the specific granularity can be configured according to security requirements.

[0060] Specifically, at the baseline location establishment level, after the closed-loop security decision server is first deployed and completes the initial handshake with the cloud management center, it uses the first successfully acquired geographic location information as the historical baseline location. This historical baseline location is securely stored in the protected storage area of ​​the security module to prevent malicious tampering. During subsequent operation, the closed-loop security decision server calculates the deviation between the current geographic location and the historical baseline location each time it acquires new geographic location information. The method for calculating the deviation can be selected using an appropriate algorithm based on the granularity of the geographic location information. For example, when using city-level granularity, it determines whether the current city is consistent with the baseline city; when using latitude and longitude coordinates, it calculates the spherical distance or straight-line distance between the two points.

[0061] Specifically, at the anomaly detection level, when the calculated deviation exceeds a preset threshold, a self-destruct condition due to geographic location anomaly is triggered. The preset threshold can be flexibly configured according to security policies and deployment scenarios. For example, for high-security scenarios requiring strict restrictions on device movement, the preset threshold can be set to "the current city is inconsistent with the base city" or "the straight-line distance between the current latitude and longitude and the base latitude and longitude exceeds 50 kilometers"; for scenarios allowing movement over a larger geographical area (such as cross-regional branch offices), the preset threshold can be set to "the current country is inconsistent with the base country" or "the straight-line distance between the current latitude and longitude and the base latitude and longitude exceeds 500 kilometers". Through this configurable threshold design, the geographic location anomaly self-destruct mechanism can adapt to the needs of users with different security levels.

[0062] Specifically, at the self-destruct and lock-up execution level, when the abnormal geographical location self-destruction condition is triggered, the closed security decision server automatically performs the following actions: First, it clears all the security detection rules stored locally, using the same clearing method as the security erasure method in the aforementioned network disconnection self-destruction mechanism, ensuring that the rule data is unrecoverable; second, the closed security decision server enters a security lock-up mode. Unlike the "rule vacuum" state in the aforementioned network disconnection self-destruction mechanism, in the security lock-up mode, the closed security decision server not only clears all security detection rules but also prohibits any rule-related operations—including but not limited to prohibiting the receipt of new security detection rule update packages, prohibiting the execution of rule decryption operations, and prohibiting the response to security detection requests from the terminal host. The security lock-up mode is a more stringent protection state than the "rule vacuum" state. Even if network communication is normal and the closed security decision server can access the cloud management center normally, it will not automatically restore security detection capabilities and must be manually reviewed and approved before the lock can be released.

[0063] Specifically, at the recovery level, when the closed-loop security decision server enters security lock mode, the cloud management center receives a corresponding status report or automatically determines an anomaly through handshake timeout, triggering a security alarm. The vendor's security operations team intervenes to investigate and verify whether the closed-loop security decision server has indeed undergone unauthorized physical movement. If manual review confirms it as a legitimate movement (e.g., a data center relocation reported to the vendor by the user in advance), the reviewer sends a lock release command to the closed-loop security decision server through the cloud management center and reissues the complete security detection rule package to restore the normal security detection function of the closed-loop security decision server. If manual review confirms it as an unauthorized movement or the legitimacy of the movement cannot be confirmed, the security lock mode is maintained, and a decision is made based on the security policy regarding whether to take further action (such as remotely erasing all firmware or permanently disabling the device). Through the closed-loop mechanism of "geographic location monitoring → anomaly determination → self-destruction and locking → manual review and recovery," the geographic location anomaly self-destruction mechanism provides the closed-loop security decision server with physical location-based security protection capabilities, effectively defending against the risk of data leakage that may result from physical theft or illegal transfer of the device.

[0064] Preferably, in order to ensure that rule clearing events are perceptible and responsive, and to form a closed loop of security operations, the cloud management center is also configured to: when it receives an event notification issued by the closed security decision server when it triggers a rule clearing event, or when it determines that the closed security decision server has triggered a rule clearing event, automatically send an alarm email to a preset customer-reserved email address and push an emergency event notification to the vendor's security operations center.

[0065] Specifically, the rule clearing event refers to the event in which the closed security decision server performs a security detection rule clearing operation due to triggering a network disconnection self-destruct mechanism or a geographical location anomaly self-destruct mechanism. Since rule clearing means that the closed security decision server has completely lost its security detection capabilities, it belongs to the highest level of security event and requires immediate notification to relevant parties for timely response and handling.

[0066] Specifically, in the first path of event notification, when the closed security decision server triggers a rule clearing event and network communication is normal at this time (e.g., self-destruction triggered due to abnormal geographical location but the device is still online), the closed security decision server immediately generates an event notification message at the same time as or after clearing the local security detection rules, and sends it to the cloud management center through the dedicated management channel. The event notification message includes, but is not limited to, the following information: event type (network disconnection self-destruction or geographical location self-destruction), event trigger time, trigger reason (handshake timeout duration or geographical location deviation details), device identifier (device certificate or device fingerprint), and current device status, etc. After receiving the event notification message, the cloud management center first verifies the legality and integrity of the message source, confirms that the event notification does indeed originate from the legitimate closed security decision server and has not been tampered with during transmission, and then enters the alarm response process.

[0067] Specifically, in the second path of event notification, when the closed security decision server triggers a rule clearing event due to network outage and is unable to send an event notification to the cloud management center, the cloud management center automatically determines that the closed security decision server has triggered a rule clearing event through its own handshake timeout monitoring mechanism. Specifically, the cloud management center maintains an independent handshake timeout timer for each closed security decision server. When a closed security decision server fails to successfully handshake for more than the third preset timeout consecutively, the cloud management center determines that the closed security decision server has triggered a network outage self-destruction, and the internally stored security detection rules and decryption keys have been cleared, subsequently entering the alarm response process. The aforementioned self-determination mechanism ensures that even in the extreme case where the closed security decision server is completely disconnected and unable to actively report, the cloud management center can still promptly detect the occurrence of the event.

[0068] Specifically, at the alarm response level, regardless of which path the alarm response process is initiated through, the cloud management center automatically performs the following alarm actions: First, it sends an alarm email to a pre-registered customer email address. The alarm email content includes, but is not limited to: event type, event trigger time, the identifier of the affected closed security decision server, a brief description of the event, and suggested remedial measures. The pre-registered customer email address is one or more email addresses pre-registered by the customer with the cloud management center during the deployment of the closed security decision server, used to receive important security notifications related to the closed security decision server. Second, it pushes an emergency event notification to the vendor's Security Operations Center (SOC). The emergency event notification is pushed through the internal security interface between the cloud management center and the vendor's security operations center, containing detailed technical information about the event, including but not limited to: the device identifier of the closed security decision server, historical handshake records, last online time, last known outbound IP address and corresponding geographical location information, and specific parameters triggering self-destruction. The emergency event notification is automatically marked as "most urgent event" to ensure that the on-duty security analyst at the vendor's security operations center can pay attention and intervene in the investigation immediately.

[0069] Through the aforementioned dual-path event perception mechanism and automatic alarm response mechanism, the cloud management center can learn about the event and notify relevant parties in the shortest possible time after the closed security decision server triggers the rule clearing event. This enables the vendor's security team to quickly intervene in the investigation, determine the cause of the event (network failure, equipment theft or illegal movement, etc.), and take corresponding measures (assist in restoring the network, remotely locking the equipment, or coordinating on-site investigation, etc.), forming a complete security operation closed loop of "event triggering → perception and reporting → alarm notification → manual intervention → event handling".

[0070] Preferably, to ensure the authenticity and non-forgeability of the trusted status report, the closed security decision server is further configured to have the security module sign the trusted status report after it is generated, and send the signed trusted status report to the cloud management center so that the cloud management center can verify the signature of the trusted status report and confirm that the firmware and configuration of the closed security decision server have not been tampered with after the verification is successful.

[0071] Specifically, the security module internally stores a signature private key uniquely bound to the closed security decision server. This signature private key is either burned into the closed security decision server by the manufacturer at the time of manufacture or automatically generated by the security module upon initial startup, and it cannot be exported. After the closed security decision server generates the trusted status report, the security module uses the signature private key to digitally sign the trusted status report, generating a signed trusted status report. The closed security decision server periodically reports the signed trusted status report to the cloud management center through the dedicated management channel. After receiving the signed trusted status report, the cloud management center verifies the signature of the trusted status report using the signature public key corresponding to the closed security decision server. If the signature verification passes, it confirms that the trusted status report has not been tampered with during transmission and indeed originates from the legitimate closed security decision server; if the signature verification fails, it indicates that the trusted status report may have been tampered with or its source is untrustworthy, triggering a security alarm.

[0072] Preferably, to ensure the source verifiability and content integrity of the security detection rule update package, the security detection rule update package is digitally signed by the cloud management center before being distributed. After receiving the security detection rule update package, the closed security decision server first verifies the digital signature, and only updates the locally stored security detection rules after the verification is successful.

[0073] Specifically, after generating the security detection rule update package, the cloud management center digitally signs the security detection rule update package using its private signing key. Upon receiving the digitally signed security detection rule update package, the closed security decision server first verifies the digital signature using the pre-stored public signing key of the cloud management center. If the verification passes, it confirms that the security detection rule update package originates from the legitimate cloud management center and has not been tampered with during transmission. Then, it uses the decryption key in the security module to decrypt the encrypted rules in the rule package and update them to local storage. If the verification fails, the security detection rule update package is discarded, and optionally, a verification failure event is reported to the cloud management center.

[0074] Preferably, in order to ensure the security and transmission efficiency of communication between the terminal host and the closed security decision server, the terminal host and the closed security decision server communicate through an intranet remote procedure call (RPC), wherein the intranet RPC adopts the HTTPS protocol based on bidirectional TLS authentication, and the data serialization adopts the Protocol Buffers protocol.

[0075] Specifically, the two-way TLS authentication requires both the terminal host and the closed security decision server to present legitimate device certificates issued by the manufacturer. An encrypted communication link can only be established after both parties verify the validity of each other's certificates, thereby preventing man-in-the-middle attacks and access by forged terminals or servers. The Protocol Buffers protocol uses a binary encoding format, which has higher serialization and deserialization efficiency compared to text-based serialization protocols. It can reduce the amount of data transmitted while ensuring strict data structure type constraints, thus meeting the millisecond-level real-time detection response communication latency requirements between the terminal host and the closed security decision server.

[0076] Preferably, to ensure the absolute security of the security detection rules during decryption and use, the decryption operation of the security detection rules is performed inside the security module. The decrypted plaintext security detection rules do not leave the security module and are completed inside the security module through the security decision logic and real-time risk analysis based on the plaintext security detection rules.

[0077] Specifically, the security module contains a protected execution environment. Core components of the security decision-making logic, at least those related to rule analysis and threat assessment, are loaded and run within this protected execution environment. When real-time risk analysis of system behavior events is required, the security module uses the internally stored decryption key to decrypt the encrypted security detection rules. The decrypted plaintext security detection rules exist only in the protected memory area within the security module. Subsequently, the core components of the security decision-making logic running within the security module directly perform feature matching and threat assessment on the system behavior events based on the plaintext security detection rules, generating analysis results. Throughout this process, the plaintext security detection rules remain within the hardware-level protection boundary of the security module. Even if the operating system layer or other application layer components of the closed security decision server are compromised, attackers cannot obtain the plaintext security detection rules through memory dumping or debugging.

[0078] Example 2 This embodiment, based on the technical solution of Embodiment 1, provides a terminal security protection system based on a cluster architecture for large-scale terminal deployment scenarios. The main difference from Embodiment 1 is that this embodiment deploys multiple closed security decision servers, which form a decision cluster to provide higher processing power and availability.

[0079] Specifically, in this embodiment, the terminal security protection system based on an intranet-based closed security decision server includes several terminal hosts deployed on the user side, multiple closed security decision servers provided by the manufacturer with standardized hardware and deployed on the user's internal network, and a cloud management center deployed on the manufacturer's side. The multiple closed security decision servers are interconnected via a network to form a decision cluster, jointly undertaking security detection and decision-making tasks. A load balancer may be configured at the front end of the decision cluster. The load balancer distributes security detection requests from each terminal host to different closed security decision server nodes in the cluster according to a preset load balancing strategy (such as round-robin, minimum connection count, or weighted allocation), thereby achieving reasonable distribution of the detection load and avoiding single-point overload.

[0080] Specifically, within the cluster, the closed security decision server nodes synchronize the state of security detection rules through a consistency protocol (such as the Raft consistency protocol). Specifically, when the cloud management center distributes a security detection rule update package to the master node in the decision cluster through the dedicated management channel, the master node, after completing its local rule update, synchronizes the updated security detection rules to all slave nodes in the cluster through the consistency protocol, ensuring that the security detection rules of all closed security decision server nodes within the entire cluster remain completely consistent. If the master node fails, the remaining nodes in the cluster automatically elect a new master node through the leader election mechanism of the consistency protocol. The new master node takes over the communication responsibilities with the cloud management center. The entire process is transparent to the terminal host and does not affect the continuity of the security detection service.

[0081] Specifically, at the security detection processing level, when the load balancer distributes a security detection request from a terminal host to a closed security decision server node in the cluster, that node executes the security detection process in the same manner as in Embodiment 1: it decrypts the security detection rules stored in encrypted form within its security module using the decryption key in its security module, and then performs real-time risk analysis of system behavior events based on the decrypted security detection rules using its security decision logic, generates a security response instruction, and sends it back to the corresponding terminal host for execution. Since the security detection rule versions are consistent across all nodes in the cluster, consistent detection results are obtained regardless of which node the terminal host's request is distributed to.

[0082] Specifically, at the trusted status reporting level, each closed security decision server node in the cluster independently generates a trusted status report, which is then signed by its respective security module and periodically reported to the cloud management center. The cloud management center verifies the trusted status report of each closed security decision server node, thereby achieving centralized monitoring of the firmware and configuration integrity of all nodes in the cluster.

[0083] Specifically, at the self-destruct mechanism level, each closed security decision server node in the cluster independently runs a network outage self-destruct mechanism and a geographical location anomaly self-destruct mechanism. If a node triggers self-destruction due to network failure or physical movement, only that node clears its locally stored security detection rules and decryption keys; the remaining normal nodes in the cluster continue to provide security detection services, without affecting the overall detection capability. After detecting that a node is unavailable, the load balancer automatically distributes subsequent detection requests to the remaining normal nodes, achieving automatic fault isolation. After the node that triggered self-destruction restores communication and successfully re-shakes with the cloud management center, it downloads the complete rule package from the cloud management center again and synchronizes the latest rule status from the current master node of the cluster through the consistency protocol. After completing the rule reconstruction, it rejoins the cluster to provide services.

[0084] Through the above cluster architecture, this embodiment can achieve the following technical effects while ensuring all the security features in embodiment one: (1) Horizontal expansion of processing capacity - by increasing the number of cluster nodes, the throughput of security detection can be linearly increased to meet the real-time detection needs of thousands or even tens of thousands of terminals; (2) Automatic switching of single point of failure - when any node fails or triggers self-destruction, the remaining nodes in the cluster automatically take over, and the terminal security detection service is not interrupted; (3) Operation and maintenance flexibility - individual nodes in the cluster can be maintained, replaced or expanded without interrupting the service, reducing the impact of system operation and maintenance on business.

[0085] Example 3 Based on the technical solutions of Embodiment 1 or Embodiment 2, this embodiment provides a terminal security protection system based on multi-site deployment for scenarios where users have multiple geographically dispersed campuses or branches, and each campus needs to conduct security testing independently. The main difference from the aforementioned embodiments is that in this embodiment, each campus independently deploys a closed security decision server (or decision cluster), and is centrally managed through a unified cloud management center.

[0086] Specifically, in this embodiment, the user owns multiple geographically dispersed campuses (e.g., branches located in different cities or countries), each campus deploying several terminal hosts and at least one closed-loop security decision server. Each campus's closed-loop security decision server independently handles the security detection tasks for the terminal hosts within its campus. This involves receiving system behavior events collected by the terminal hosts within its campus, decrypting the internally stored security detection rules (in encrypted form) using the decryption key in the security module, and then performing real-time risk analysis based on the decrypted security detection rules through security decision logic. Finally, it generates security response instructions and sends them back to the terminal hosts for execution. Communication between the terminal hosts within each campus and the closed-loop security decision server occurs through the campus's internal network, ensuring millisecond-level real-time detection and response capabilities, unaffected by cross-campus wide area network communication latency.

[0087] Specifically, at the cloud management layer, the vendor deploys a unified cloud management center to centrally manage all closed-loop security decision servers within each campus. Regarding rule updates, after generating security detection rule update packages, the cloud management center distributes them in parallel to the closed-loop security decision servers in each campus via a dedicated management channel. Each closed-loop security decision server verifies the signature of the rule package and updates its local security detection rules upon successful verification, ensuring that the security detection capabilities of each campus are synchronized with cloud-based threat intelligence. For remote authentication, each closed-loop security decision server independently generates a trusted status report, which is signed by its respective security module and periodically reported to the cloud management center. The cloud management center verifies the trusted status report of each closed-loop security decision server, achieving centralized monitoring of the firmware and configuration integrity of all closed-loop security decision servers across geographical regions.

[0088] Specifically, at the self-destruct mechanism level, each park's closed security decision server independently operates a network disconnection self-destruction mechanism and a geolocation anomaly self-destruction mechanism. For the network disconnection self-destruction mechanism, each park's closed security decision server independently communicates with the cloud management center. If a park's closed security decision server triggers network disconnection self-destruction due to a network exit failure in that park or the cloud management center being unreachable, only that park's closed security decision server clears its local security detection rules and decryption keys and enters a continuous reconnection state. The closed security decision servers in other parks are unaffected and continue to provide security detection services to the terminal hosts in their respective parks. For the geolocation anomaly self-destruction mechanism, each park's closed security decision server independently monitors the geolocation information of its outgoing IP address. Since the closed security decision servers in different parks are located in different authorized geographical areas, the historical reference locations of each park's closed security decision server are configured independently. If a park's closed security decision server is illegally moved out of its authorized area, only that closed security decision server triggers geolocation self-destruction and enters a security lockout mode, without affecting the normal security detection functions of other parks. When the cloud management center receives a rule clearing event notification from a closed-loop security decision server in a certain park or determines that a closed-loop security decision server in a certain park has triggered a rule clearing event, it sends an alarm email to the customer's reserved email address and pushes an emergency event notification to the vendor's security operations center according to the alarm notification mechanism in Implementation Example 1, and clearly identifies the affected parks and devices in the notification.

[0089] Through the above multi-site deployment architecture, this embodiment can achieve the following technical effects while ensuring all the security features in embodiment one: (1) Independence of security detection in each park - each park has an independent security decision node, the security detection delay within the park is not affected by the cross-park network conditions, and the failure or self-destruction of the closed security decision server of a single park will not affect the normal security protection of other parks; (2) Consistency of global management - the cloud management center ensures that the security detection rule version and trusted status baseline of each park are consistent through unified rule distribution and status monitoring, avoiding inconsistencies or delays that may be caused by decentralized management; (3) Site-level differentiation of geographical location self-destruction - each park can independently set the geographical location benchmark according to its own authorized area. When the device is illegally transferred across parks, even if it is still in the authorized area of ​​another legal park, it will trigger self-destruction due to geographical location deviation, thereby preventing the device from being stolen by internal personnel across parks.

[0090] Example 4 This embodiment, based on the system described in any of the embodiments one to three, provides a terminal security protection method based on an intranet-based closed security decision server. The method is applied to a terminal host deployed on the user side, a closed security decision server provided by the manufacturer using standardized hardware and deployed within the user's internal network, and a cloud management center deployed on the manufacturer's side. The closed security decision server has a security module internally and exposes only designated service interfaces. This security module generates and manages decryption keys that cannot be exported. Users have no system login permissions or data access permissions to the closed security decision server through any means other than the designated service interfaces.

[0091] like Figure 2 As shown, the terminal security protection method includes, but is not limited to, the following steps S10 to S70.

[0092] S10. The terminal host collects system behavior events, and then sends the system behavior events to the closed security decision server through the designated service interface and the intranet. The terminal host does not store security detection rules and does not run security decision logic for performing risk analysis and response decisions.

[0093] In step S10, the lightweight security agent program installed on the terminal host collects multi-dimensional system behavior events in real time by using kernel-level process callback functions, registry callback functions, file system micro-filter driver framework and network filter driver, as well as user-space inline hook technology. This data includes process behavior, registry operations, file system operations, network connection behavior, and application programming interface (API) call behavior. After collecting these system behavior events, the terminal host sends them to the closed security decision server via the designated service interface and the intranet. Communication between the terminal host and the closed security decision server can be implemented using a Hypertext Transfer Protocol (HTTP) based on bidirectional transport layer security protocol authentication, and data serialization uses a protocol buffer protocol to ensure both communication security and transmission efficiency. In step S10, the security agent program on the terminal host acts only as an event sensor and does not possess any independent security analysis and judgment capabilities. It does not store any form of security detection rules locally, nor does it run any security decision logic.

[0094] S20. After receiving the system behavior event, the closed security decision server first uses the decryption key in the security module to decrypt the security detection rules stored in encrypted form inside. Then, based on the decrypted security detection rules, it performs real-time risk analysis on the system behavior event through vendor-specific security operation code and the security decision logic running on the security operation code, generates a security response command, and sends it back to the terminal host.

[0095] In step S20, after receiving the system behavior event through the designated service interface, the closed security decision server first reads the security detection rule stored in encrypted form from its internal storage. The security detection rule always exists in encrypted form on the static storage medium inside the closed security decision server. The closed security decision server calls the decryption service interface provided by the security module to pass the encrypted security detection rule to the security module. The security module uses the decryption key stored internally to decrypt the security detection rule in a protected area within the security module and retains the decrypted plaintext security detection rule within the security module. Subsequently, the security decision logic running on the security operation code performs real-time risk analysis on the system behavior event based on the decrypted security detection rule. The real-time risk analysis includes matching the system behavior event with the behavioral characteristics in the security detection rule and determining whether malicious or abnormal behavior exists based on the matching result. The closed security decision server generates corresponding security response instructions based on the analysis results. The security response instructions include a allow instruction (when the event is determined to be a safe behavior), a block instruction (when the event is determined to be a malicious behavior), an isolation instruction (when the event is determined to be a suspicious behavior), or an alarm instruction (when it is necessary to notify the administrator). The generated security response instructions are then transmitted back to the terminal host through the designated service interface and via the intranet.

[0096] S30. The terminal host executes the security response command obtained via feedback.

[0097] In step S30, the security agent program on the terminal host receives the security response instruction from the closed security decision server and executes corresponding actions based on the instruction type: when a permit instruction is received, the corresponding system behavior is allowed to continue; when a block instruction is received, the corresponding process is terminated or the corresponding network connection is blocked; when an isolation instruction is received, the corresponding file is moved to the isolation area and its execution permissions are restricted; when an alarm instruction is received, a security alarm notification is sent to the user or administrator. The execution results of the above actions can be recorded as an audit log and optionally reported to the closed security decision server or the cloud management center.

[0098] S35. The closed-loop security decision server generates a security event based on the real-time risk analysis results of the system behavior events through the security decision logic, and reports the security event to the cloud management center so that the cloud management center can receive the security event and store and analyze it.

[0099] In step S35, when the security decision logic determines that a certain system behavior event or event sequence constitutes a security threat, a structured security event record is generated and reported to the cloud management center through the dedicated management channel. The cloud management center centrally stores, analyzes, and displays the received security events, providing data support for security operations.

[0100] S40. The closed security decision server generates a trusted status report based on the status of the security operation code and the security decision logic, and periodically reports it to the cloud management center.

[0101] In step S40, during the startup process of the closed-loop security decision server, the security module performs integrity measurements on the code segments of the security operation code, key configuration files, and the code segments of the security decision logic, and stores the measurement values ​​in the platform configuration register within the security module. During reporting, the security module signs the trusted status report containing the measurement values, generating a signed trusted status report. The closed-loop security decision server periodically reports the signed trusted status reports to the cloud management center; the reporting period can be configured according to the security policy.

[0102] S50. The cloud management center receives the trusted status report and verifies whether the firmware and configuration of the closed security decision server have been tampered with.

[0103] In step S50, after receiving the signed trusted status report, the cloud management center first verifies the signature of the trusted status report using the public key corresponding to the closed security decision server to confirm that the trusted status report indeed originates from the legitimate closed security decision server and has not been tampered with during transmission. After the signature verification is successful, the cloud management center compares the metric value contained in the trusted status report with the trusted benchmark value stored in the cloud management center's database. If the comparison matches, it confirms that the firmware and configuration of the closed security decision server have not been tampered with, maintaining the trust relationship with the closed security decision server; if the comparison does not match, it indicates that the closed security decision server may have been tampered with, and the cloud management center triggers a corresponding security alarm.

[0104] S60. The cloud management center generates a security detection rule update package and distributes it to the closed security decision server through a dedicated management channel.

[0105] In step S60, the cloud management center gathers the latest threat information from the threat intelligence platform, the malicious sample sandbox analysis system, and the security research team, continuously generating and updating the security detection rules. When a new security detection rule is generated, the cloud management center packages the updated security detection rule into a security detection rule update package and digitally signs the security detection rule update package to ensure the source authentication and content integrity of the rule package. The cloud management center distributes the digitally signed security detection rule update package to the closed security decision server through the dedicated management channel. The dedicated management channel is independent of the designated service interface exposed by the closed security decision server to the terminal host, can be established based on the Hypertext Transfer Protocol (HTTP) authentication, and can be used in conjunction with hardware isolation devices such as physical one-way optical shutters.

[0106] S70. After receiving the security detection rule update package, the closed security decision server updates the locally stored security detection rules according to the security detection rule update package.

[0107] In step S70, after receiving the digitally signed security detection rule update package, the closed-loop security decision server first verifies the digital signature. If the verification is successful, it uses the decryption key in the security module to decrypt the encrypted rules in the security detection rule update package and updates the decrypted security detection rules to local storage, completing the rule replacement. The entire rule update process is transparent to the user, who cannot interfere or block it. If the digital signature verification fails, the security detection rule update package is discarded, and a verification failure event can be reported to the cloud management center.

[0108] It should be noted that steps S10 to S30 constitute the real-time detection closed loop of the terminal security protection method, steps S40 to S50 constitute the remote authentication closed loop of the terminal security protection method, and steps S60 to S70 constitute the rule update closed loop of the terminal security protection method. These three closed loops can be executed in parallel in time without blocking each other. For example, while executing the real-time detection process (S10-S30), the closed security decision server can simultaneously execute the reporting of the trusted state report (S40) and the reception and updating of the rule update package (S70). Each step of the terminal security protection method is applicable in the single-server deployment scenario described in Embodiment 1, the cluster deployment scenario described in Embodiment 2, and the multi-site deployment scenario described in Embodiment 3.

[0109] In a preferred embodiment of this example, the terminal security protection method may further include additional steps, such as: dynamic password management and auditing steps, network disconnection self-destruction and recovery steps, geographic location monitoring and self-destruction locking steps, self-destruction event alarm notification steps, trusted status report signature verification steps, rule update packet signature verification steps, intranet secure communication establishment steps, and hardware security boundary decryption and analysis steps. The specific implementation methods of the above additional steps have been described in detail in Embodiments 1 to 3, and will not be repeated in this embodiment.

[0110] Example 5 This embodiment provides a closed security decision server, which can be independently implemented as the core security decision node in any of the terminal security protection systems described in embodiments one to three above. The closed security decision server is provided by the manufacturer using standardized hardware and deployed within the user's internal network. It has an internal security module and exposes only designated service interfaces. The security module is used to generate and manage decryption keys that cannot be exported. Users have no system login or data access permissions to the closed security decision server through any means other than the designated service interfaces.

[0111] At the hardware level, the hardware platform of the closed-loop security decision server includes at least a processor, memory, network interface, and security module. The security module may be implemented using, but is not limited to, a Trusted Platform Module (TPM) security chip or a Trusted Execution Environment (TEE) based on processor security extensions. The security module has independent key generation and management logic, capable of generating the decryption key upon the first startup of the closed-loop security decision server or during the vendor initialization phase. The private key portion of the decryption key is stored only in a protected storage area within the security module, and is invisible, unreadable, and non-exportable externally; even if physical control of the closed-loop security decision server is gained and the storage medium is disassembled, the decryption key cannot be retrieved. The security module only provides a decryption service interface to designated processes within the closed-loop security decision server, without exposing the key itself, thereby achieving hardware-level protection of the key.

[0112] At the interface and access control level, the closed security decision server completely disables all system-level operation and maintenance interfaces at the software level by running vendor-specific security operation code. This includes, but is not limited to, Secure Shell protocol interfaces, Remote Desktop protocol interfaces, serial ports, remote login protocol interfaces, file transfer protocol interfaces, Secure File Transfer Protocol interfaces, and local command-line terminals. This prevents users from logging into the closed security decision server's operating system or accessing its file system or memory space via any remote or local method. The closed security decision server only exposes the designated service interface, which is the only network service port open to the user side, used to receive security detection requests from external terminal hosts. Furthermore, the closed security decision server retains only a limited web management interface. The functionality of this interface is strictly limited to network parameter configuration, network connectivity testing, and basic status viewing, without providing any operation options related to security detection rules or security decision logic. Through this design, the closed security decision server becomes a physically and logically inaccessible security decision-making center within the user network.

[0113] At the functional configuration level, the closed security decision server is configured as the following components (B1) to (B4).

[0114] (B1) The system runs vendor-specific security operation code and security decision logic running on top of this security operation code, used to perform risk analysis and response decisions. Specifically, the closed security decision server adopts a layered software architecture: the bottom layer is the security operation code, which is a vendor-customized and security-hardened operating system-level software that retains only core functional modules related to security detection and communication, removing all unnecessary system services and applications, thereby reducing the attack surface at the source; the security decision logic runs on top of the security operation code, and this security decision logic is the core application layer component for performing risk analysis and response decisions. The security operation code provides a protected operating environment for the security decision logic, ensuring that the code integrity and execution process of the security decision logic are not tampered with.

[0115] (B2) After receiving system behavior events collected by an external terminal host through the designated service interface and the intranet, the security detection rules stored internally in ciphertext form are first decrypted using the decryption key in the security module. Then, based on the decrypted security detection rules, the security decision logic performs real-time risk analysis on the system behavior events, generates a security response command, and sends it back to the external terminal host for execution. The external terminal host is deployed on the user side and does not store security detection rules or run the security decision logic. Specifically, the security detection rules are always stored in ciphertext form on the static storage medium inside the closed security decision server and are protected by symmetric encryption algorithms such as Advanced Encryption Standard (AES). The closed security decision server calls the decryption service interface provided by the security module to pass the ciphertext rules to the security module, where they are decrypted in the protected area inside the security module. The decrypted plaintext security detection rules are then retained within the security module. Subsequently, the security decision logic performs feature matching and threat assessment on the events based on the decrypted rules. Based on the assessment results, it generates security response commands such as allow commands, block commands, isolation commands, or alarm commands, and sends them back to the external terminal host for execution. Additionally, the security decision logic can generate security events and report them to the external cloud management center. Specifically, when the security decision logic determines that a system behavior event or event sequence constitutes a security threat, it generates a structured security event record and reports it to the external cloud management center through a dedicated management channel for centralized storage and security posture analysis.

[0116] (B3) Based on the status of the security operation code and the security decision logic, a trusted status report is generated and periodically reported to an external cloud management center. This external cloud management center receives the trusted status report and verifies whether the firmware and configuration of the closed security decision server have been tampered with. The external cloud management center is deployed on the vendor's side. Specifically, during the startup process of the closed security decision server, the security module performs integrity measurements on the code segments of the security operation code, key configuration files, and the code segments of the security decision logic, storing the measurement values ​​in the platform configuration register within the security module. During reporting, the security module uses its internally stored signing private key to sign the trusted status report containing the measurement values, generating a signed trusted status report, which is periodically reported to the external cloud management center. After verifying the signature, the external cloud management center compares the measurement values ​​with a trusted benchmark value to confirm whether the firmware and configuration of the closed security decision server have been tampered with.

[0117] (B4) Upon receiving a security detection rule update package generated by the external cloud management center and distributed through a dedicated management channel, the security detection rules stored locally are updated according to the security detection rule update package. Specifically, after receiving the digitally signed security detection rule update package, the closed security decision server first verifies the digital signature. After successful verification, it uses the decryption key in the security module to decrypt the encrypted rules in the rule package and updates the decrypted security detection rules to the local storage, thus completing the rule replacement.

[0118] In summary, the closed-loop security decision server provided in this embodiment achieves the non-extraction of security detection rules and the immutability of security decision logic through a layered architecture of hardware security modules and dedicated security operation code, as well as a closed design with zero user permissions. This closed-loop security decision server can be deployed as an independent, standardized hardware product in various user internal networks, working in conjunction with external terminal hosts and external cloud management centers to form a complete terminal security protection system. Its implementation can refer to the single-server deployment scenario, cluster deployment scenario, and multi-site deployment scenario described in Embodiments 1 to 3.

[0119] Finally, it should be noted that the above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A terminal security protection system based on an intranet-based closed security decision server, characterized in that, It includes a terminal host deployed on the user side, a closed security decision server provided by the manufacturer with standardized hardware and deployed on the user's internal network, and a cloud management center deployed on the manufacturer side. The closed security decision server has a security module inside and only exposes designated service interfaces. The security module is used to generate and manage decryption keys that cannot be exported. Users have no system login permissions or data access permissions to the closed security decision server through any means other than the designated service interfaces. The terminal host is configured to: collect system behavior events and execute security response instructions, and not store security detection rules or run security decision logic for performing risk analysis and response decisions; The closed-loop security decision server is configured to: run vendor-specific security operation code and the security decision logic running on top of that security operation code; after receiving system behavior events collected by the terminal host through the designated service interface and the intranet, it first uses the decryption key in the security module to decrypt the security detection rules stored internally in encrypted form; then, through the security decision logic, it performs real-time risk analysis on the system behavior events based on the decrypted security detection rules, generates security response instructions, and sends them back to the terminal host for execution; and generates a trusted status report based on the status of the security operation code and the security decision logic, and periodically reports it to the cloud management center. The cloud management center is configured to: receive the trusted status report and verify whether the firmware and configuration of the closed security decision server have been tampered with; generate a security detection rule update package and distribute it to the closed security decision server through a dedicated management channel, so that the closed security decision server can receive and update the security detection rules stored locally.

2. The terminal security protection system as described in claim 1, characterized in that, The closed security decision server completely disables system-level operation and maintenance interfaces, which include Secure Shell protocol interface, Remote Desktop protocol interface, serial port, Remote Login protocol interface, File Transfer Protocol interface, Secure File Transfer Protocol interface and local command line terminal; The specified service interface refers to a web management interface whose functional scope is limited to network parameter configuration, network connectivity testing, and basic status viewing.

3. The terminal security protection system as described in claim 2, characterized in that, The login password for the web management interface is generated daily by the cloud management center using a cryptographically secure random number generator and synchronized to the closed security decision server through a two-way TLS-certified encrypted channel. The login password is valid for a first preset duration and automatically expires upon expiration. All login activities on the web management interface are recorded in audit logs and uploaded to the cloud management center.

4. The terminal security protection system as described in claim 1, characterized in that, The closed-loop security decision server also has a self-destruct mechanism for network disconnection. The self-destruct mechanism includes: the closed-loop security decision server and the cloud management center perform a handshake every second preset time interval to verify the device identity and synchronization status; if the closed-loop security decision server fails to successfully handshake with the cloud management center for more than a third preset time interval, it automatically clears all the security detection rules and decryption keys stored locally and enters a continuous reconnection state until the handshake is successfully re-established and the complete rule package is downloaded again from the cloud management center. And / or, the closed security decision server is also equipped with a geolocation anomaly self-destruct mechanism, wherein the geolocation anomaly self-destruct mechanism includes: real-time monitoring of the geolocation information of the server's outgoing IP address; when the deviation between the current geolocation and the historical reference location is detected to exceed a preset threshold, automatically clearing all the security detection rules stored locally and entering a security lock mode; in the security lock mode, any operation related to the rules is prohibited until manual review is approved; And / or, the cloud management center is further configured to: when it receives an event notification issued by the closed security decision server when a rule clearing event is triggered, or when it determines that the closed security decision server has triggered a rule clearing event, automatically send an alarm email to a preset customer-reserved email address and push an emergency event notification to the vendor's security operations center.

5. The terminal security protection system as described in claim 1, characterized in that, The closed security decision server is also used to have the security module sign the trusted status report after it is generated, and send the signed trusted status report to the cloud management center so that the cloud management center can verify the signature of the trusted status report and confirm that the firmware and configuration of the closed security decision server have not been tampered with after the verification is successful. And / or, the closed security decision server is further configured to generate security events through the security decision logic and report the security events to the cloud management center; The cloud management center is also configured to receive the security events and store and analyze them.

6. The terminal security protection system as described in claim 1, characterized in that, The security detection rule update package is distributed by the cloud management center after being digitally signed. After receiving the security detection rule update package, the closed security decision server first verifies the digital signature, and only updates the security detection rules stored locally after the verification is successful.

7. The terminal security protection system as described in claim 1, characterized in that, The terminal host communicates with the closed security decision server via intranet RPC, wherein the intranet RPC uses the HTTPS protocol based on two-way TLS authentication, and the data serialization uses the Protocol Buffers protocol.

8. The terminal security protection system as described in claim 1, characterized in that, The decryption operation of the security detection rule is performed inside the security module. The decrypted plaintext security detection rule does not leave the security module and is completed inside the security module through the security decision logic and real-time risk analysis based on the plaintext security detection rule.

9. A terminal security protection method based on an intranet-based closed security decision server, characterized in that, It is applied to terminal hosts deployed on the user side, closed security decision servers provided by manufacturers with standardized hardware devices and deployed in the user's internal network, and cloud management centers deployed on the manufacturer side. The closed security decision server has a security module inside and only exposes designated service interfaces. The security module is used to generate and manage decryption keys that cannot be exported. Users have no system login permissions or data access permissions to the closed security decision server through any means other than the designated service interfaces. The terminal security protection method includes the following steps: The terminal host collects system behavior events, and then sends the system behavior events to the closed security decision server through the designated service interface and via the intranet. The terminal host does not store security detection rules and does not run security decision logic for performing risk analysis and response decisions. After receiving the system behavior event, the closed security decision server first uses the decryption key in the security module to decrypt the security detection rules stored in encrypted form inside. Then, through the vendor-specific security operation code and the security decision logic running on the security operation code, it performs real-time risk analysis on the system behavior event based on the decrypted security detection rules, generates a security response command, and sends it back to the terminal host. The terminal host executes the security response command that has been transmitted back. The closed-loop security decision server generates a trusted status report based on the status of the security operation code and the security decision logic, and periodically reports it to the cloud management center. The cloud management center receives the trusted status report and verifies whether the firmware and configuration of the closed security decision server have been tampered with. The cloud management center generates a security detection rule update package and distributes it to the closed security decision server through a dedicated management channel; Upon receiving the security detection rule update package, the closed security decision server updates the locally stored security detection rules according to the security detection rule update package.

10. A closed-loop security decision server, characterized in that, Provided by the manufacturer with standardized hardware devices and deployed in the user's internal network, the security module is internally equipped and only exposes designated service interfaces. The security module is used to generate and manage decryption keys that cannot be exported. Users have no system login permissions or data access permissions to the closed security decision server through any means other than the designated service interfaces. The closed-loop security decision server is configured as follows: Run vendor-specific security operation code and security decision logic that sits on top of that security operation code and is used to perform risk analysis and response decisions; After receiving system behavior events collected by an external terminal host through the designated service interface and the intranet, the security detection rules stored internally in encrypted form are first decrypted using the decryption key in the security module. Then, based on the decrypted security detection rules, the security decision logic performs real-time risk analysis on the system behavior events, generates a security response instruction, and sends it back to the terminal host for execution. The terminal host is deployed on the user side and does not store security detection rules or run the security decision logic. Based on the state of the security operation code and the security decision logic, a trusted state report is generated and periodically reported to an external cloud management center, so that the cloud management center can receive the trusted state report and verify whether the firmware and configuration of the closed security decision server have been tampered with. The cloud management center is deployed on the vendor side. Upon receiving a security detection rule update package generated by the cloud management center and distributed through a dedicated management channel, the security detection rules stored locally are updated according to the security detection rule update package.

Images