Equipment alarm method, electronic equipment, storage medium and program product

Abstract

The embodiment of the invention provides a device alarm method, an electronic device, a storage medium and a program product, and the method comprises the steps: receiving device data sent by a client terminal, the device data being obtained by encrypting one or more of a static feature or a dynamic feature by the client terminal; according to the terminal identifier of the client terminal, storing the equipment data in a container corresponding to the terminal identifier, the container corresponding to the client terminal; according to the device data and the pre-stored security threat database, whether the client terminal is a risk device is judged, the target security threat type of the client terminal is determined, the alarm information is determined according to the target security threat type, on-demand expansion and scene adaptation of the alarm content are realized, and encryption transmission and storage in the whole process are ensured at the same time. On the premise of not decrypting, the ciphertext feature uploaded by the client terminal is compared with the security threat database, the potential risk equipment is accurately identified, and the identification efficiency and accuracy of the security risk equipment are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of communication, in particular to a device alarm method, an electronic device, a storage medium and a program product. BACKGROUND

[0002] In the current field of network security and device management, a security device feature recognition and alarm system plays a vital role. At present, only a single feature is used to identify the risk of a device, and when a large-scale device network is processed, the security threat type of the device cannot be quickly identified, and there are problems of low recognition efficiency and inaccuracy. SUMMARY

[0003] Some embodiments of the present application aim to provide a device alarm method, an electronic device, a storage medium and a program product. Through the technical solutions of the embodiments of the present application, device data sent by a client terminal is received, wherein the device data is obtained by encrypting one or more of static features or dynamic features by the client terminal; the device data is stored in a container corresponding to a terminal identifier of the client terminal according to the terminal identifier, and the container corresponds to the client terminal; whether the client terminal is a risk device is judged according to the device data and a pre-stored security threat database, and a target security threat type of the client terminal is determined, and alarm information is determined according to the target security threat type, wherein the pre-stored security threat database at least includes a security threat type and a preset feature vector corresponding to the security threat type. In the embodiments of the present application, multi-dimensional data of each client terminal is obtained, and the multi-dimensional data is encrypted to obtain device data, and then the server performs similarity calculation on the device data and the feature vector in the pre-stored security threat database, judges whether the client terminal is a risk device according to the calculation result, breaks through the limitation of traditional fixed event type, realizes on-demand expansion and scene adaptation of alarm content, and at the same time ensures full encryption transmission and storage, supports comparison of ciphertext features uploaded by the client terminal and the security threat database without decryption, accurately identifies potential risk devices, and improves the identification efficiency and accuracy of security risk devices.

[0004] In a first aspect, some embodiments of the present application provide a device alarm method, comprising: receiving device data sent by a client terminal, wherein the device data is obtained by encrypting one or more of static features or dynamic features by the client terminal; storing the device data in a container corresponding to a terminal identifier of the client terminal according to the terminal identifier, and the container corresponds to the client terminal; Based on the device data and a pre-stored security threat database, it is determined whether the client terminal is a risky device, and the target security threat type of the client terminal is determined. Based on the target security threat type, an alarm message is determined. The pre-stored security threat database includes at least security threat types and preset feature vectors corresponding to the security threat types.

[0005] Some embodiments of this application obtain multi-dimensional data from various client terminals and encrypt the multi-dimensional data to obtain device data. The server then calculates the similarity between the device data and the feature vectors in the pre-stored security threat database. Based on the calculation results, it determines whether the client terminal is a risky device. This breaks through the limitations of traditional fixed event types, realizes on-demand expansion and scenario adaptation of alarm content, and ensures encrypted transmission and storage throughout the process. It supports comparing the encrypted features uploaded by the client terminal with the security threat database without decryption, accurately identifying potential risky devices and improving the efficiency and accuracy of identifying security risky devices.

[0006] Optionally, determining whether the client terminal is a risky device and identifying the target security threat type of the client terminal based on the device data and a pre-stored security threat database includes: Calculate the similarity based on the device data and the preset feature vector; Based on the similarity and similarity threshold, determine whether the client terminal is a risky device; If the client terminal is a risky device, determine the target security threat type of the client terminal.

[0007] Some embodiments of this application enable the comparison of device data uploaded by a client terminal with feature vectors in a security threat database without decryption, thereby accurately identifying potentially risky devices.

[0008] Optionally, calculating the similarity based on the device data and the preset feature vector includes: Calculate the cosine similarity between the encrypted feature vector of the device data and each preset feature vector in the security threat database. Some embodiments of this application calculate the cosine similarity between the encrypted feature vector of the client terminal and each preset feature vector in the security threat database, and determine whether the client terminal is a risky device based on the magnitude of the similarity.

[0009] Optionally, calculating the similarity based on the device data and the preset feature vector includes: Based on the locality-sensitive hashing algorithm, an initial vector set matching the device data is determined in the security threat database; Calculate the cosine similarity between the encrypted feature vector of the device data and each preset feature vector in the initial vector set.

[0010] Some embodiments of this application use vector indexing, such as LSH (Local Sensitive Hash), to select a portion of the initial vector set. Then, based on the small portion of the initial vector set, the cosine similarity between the encrypted feature vector of the device data and each preset feature vector in the initial vector set is calculated, thereby improving the similarity calculation efficiency. Optionally, determining whether the client terminal is a risky device based on the similarity and similarity threshold includes: If the similarity is greater than the similarity threshold, then the client terminal is determined to be a risky device; If the similarity is less than the similarity threshold, the client terminal is determined to be a security device.

[0011] Some embodiments of this application accurately identify potentially risky devices by comparing similarity and similarity thresholds.

[0012] Optionally, if the client terminal is a risky device, determining the target security threat type of the client terminal includes: If the client terminal is a risky device, then according to the preset feature vector corresponding to the similarity; Based on the security threat database, the security threat type corresponding to the preset feature vector is determined, and the security threat type is determined as the target security threat type.

[0013] Optionally, the static features include at least one or more of the following: device identifier, hardware model, firmware version, operating system version, geographical location, or MAC address hash; the dynamic features include at least one or more of the following: network behavior patterns, CPU utilization, and memory utilization within a preset time period.

[0014] Some embodiments of this application dynamically define and encrypt the reporting of multi-dimensional security features (such as behavioral fingerprints, environmental variables, abnormal indicators, etc.) on the device side, breaking through the limitations of traditional fixed event types, realizing on-demand expansion and scenario adaptation of alarm content, while ensuring encrypted transmission and storage throughout the process.

[0015] Optionally, the device data is obtained in the following manner: The client terminal uses a preset encryption algorithm to encrypt one or more of the static features or the dynamic features to obtain the device data. The preset encryption algorithm includes at least a homomorphic encryption algorithm, a symmetric algorithm, or an asymmetric algorithm.

[0016] Some embodiments of this application encrypt multi-dimensional data to achieve "data usable but not visible," thus eliminating the risk of plaintext leakage at the source.

[0017] Optionally, the method further includes: For each container, an encrypted feature index table is established, wherein the encrypted feature index table includes at least the client terminal's terminal identifier, the container identifier, the device data, and the timestamp.

[0018] Optionally, the method further includes: The alarm information is returned to the client terminal, wherein the alarm information includes at least the client terminal's terminal identifier, the target security threat type, and the handling measures.

[0019] Secondly, some embodiments of this application provide a device alarm apparatus, including: A receiving module is used to receive device data sent by a client terminal, wherein the device data is obtained by the client terminal encrypting one or more of static features or dynamic features; The storage module is used to store the device data into a container corresponding to the terminal identifier of the client terminal, wherein the container corresponds to the client terminal. The alarm module is used to determine whether the client terminal is a risky device based on the device data and a pre-stored security threat database, determine the target security threat type of the client terminal, and determine alarm information based on the target security threat type. The pre-stored security threat database includes at least security threat types and preset feature vectors corresponding to the security threat types.

[0020] Some embodiments of this application obtain multi-dimensional data from various client terminals and encrypt the multi-dimensional data to obtain device data. The server then calculates the similarity between the device data and the feature vectors in the pre-stored security threat database. Based on the calculation results, it determines whether the client terminal is a risky device. This breaks through the limitations of traditional fixed event types, realizes on-demand expansion and scenario adaptation of alarm content, and ensures encrypted transmission and storage throughout the process. It supports comparing the encrypted features uploaded by the client terminal with the security threat database without decryption, accurately identifying potential risky devices and improving the efficiency and accuracy of identifying security risky devices.

[0021] Optionally, the alarm module is used to: Calculate the similarity based on the device data and the preset feature vector; Based on the similarity and similarity threshold, determine whether the client terminal is a risky device; If the client terminal is a risky device, determine the target security threat type of the client terminal.

[0022] Some embodiments of this application enable the comparison of device data uploaded by a client terminal with feature vectors in a security threat database without decryption, thereby accurately identifying potentially risky devices.

[0023] Optionally, the alarm module is used to: Calculate the cosine similarity between the encrypted feature vector of the device data and each preset feature vector in the security threat database. Some embodiments of this application calculate the cosine similarity between the encrypted feature vector of the client terminal and each preset feature vector in the security threat database, and determine whether the client terminal is a risky device based on the magnitude of the similarity.

[0024] Optionally, the alarm module is used to: Based on the locality-sensitive hashing algorithm, an initial vector set matching the device data is determined in the security threat database; Calculate the cosine similarity between the encrypted feature vector of the device data and each preset feature vector in the initial vector set.

[0025] Some embodiments of this application use vector indexing, such as LSH (Local Sensitive Hash), to select a portion of the initial vector set. Then, based on the small portion of the initial vector set, the cosine similarity between the encrypted feature vector of the device data and each preset feature vector in the initial vector set is calculated, thereby improving the similarity calculation efficiency. Optionally, the alarm module is used to: If the similarity is greater than the similarity threshold, then the client terminal is determined to be a risky device; If the similarity is less than the similarity threshold, the client terminal is determined to be a security device.

[0026] Some embodiments of this application accurately identify potentially risky devices by comparing similarity and similarity thresholds.

[0027] Optionally, the alarm module is used to: If the client terminal is a risky device, then according to the preset feature vector corresponding to the similarity; Based on the security threat database, the security threat type corresponding to the preset feature vector is determined, and the security threat type is determined as the target security threat type.

[0028] Optionally, the static features include at least one or more of the following: device identifier, hardware model, firmware version, operating system version, geographical location, or MAC address hash; the dynamic features include at least one or more of the following: network behavior patterns, CPU utilization, and memory utilization within a preset time period.

[0029] Some embodiments of this application dynamically define and encrypt the reporting of multi-dimensional security features (such as behavioral fingerprints, environmental variables, abnormal indicators, etc.) on the device side, breaking through the limitations of traditional fixed event types, realizing on-demand expansion and scenario adaptation of alarm content, while ensuring encrypted transmission and storage throughout the process.

[0030] Optionally, the device data is obtained in the following manner: The client terminal uses a preset encryption algorithm to encrypt one or more of the static features or the dynamic features to obtain the device data. The preset encryption algorithm includes at least a homomorphic encryption algorithm, a symmetric algorithm, or an asymmetric algorithm.

[0031] Some embodiments of this application encrypt multi-dimensional data to achieve "data usable but not visible," thus eliminating the risk of plaintext leakage at the source.

[0032] Optionally, the alarm module is used to: For each container, an encrypted feature index table is established, wherein the encrypted feature index table includes at least the client terminal's terminal identifier, the container identifier, the device data, and the timestamp.

[0033] Optionally, the alarm module is used to: The alarm information is returned to the client terminal, wherein the alarm information includes at least the client terminal's terminal identifier, the target security threat type, and the handling measures.

[0034] Thirdly, some embodiments of this application provide an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, can implement the device alarm method as described in any embodiment of the first aspect.

[0035] Fourthly, some embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, can implement the device alarm method as described in any embodiment of the first aspect.

[0036] Fifthly, some embodiments of this application provide a computer program product, the computer program product including a computer program, wherein when the computer program is executed by a processor, it can implement the device alarm method as described in any embodiment of the first aspect. Attached Figure Description

[0037] To more clearly illustrate the technical solutions of some embodiments of this application, the accompanying drawings used in some embodiments of this application will be briefly described below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0038] Figure 1 A flowchart illustrating a device alarm method provided in an embodiment of this application; Figure 2 A flowchart illustrating yet another device alarm method provided in this application embodiment; Figure 3 This is a schematic diagram of the structure of a device alarm device provided in an embodiment of this application; Figure 4 This is a schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0039] The technical solutions of some embodiments of this application will now be described with reference to the accompanying drawings.

[0040] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0041] In the current field of network security and device management, security device feature identification and alarm systems play a crucial role. Currently, identifying device risks solely through a single feature is insufficient for quickly identifying the type of security threat when dealing with large-scale device networks, resulting in low identification efficiency and inaccuracy. Therefore, some embodiments of this application provide a device alarm method. This method includes receiving device data sent by a client terminal, wherein the device data is obtained by encrypting one or more static or dynamic features by the client terminal; storing the device data in a container corresponding to the client terminal's identifier, with the container corresponding to the client terminal; determining whether the client terminal is a risky device based on the device data and a pre-stored security threat database, identifying the target security threat type of the client terminal, and determining an alarm based on the target security threat type. The alarm information, wherein the pre-stored security threat database includes at least security threat types and preset feature vectors corresponding to the security threat types, is obtained by acquiring multi-dimensional data from each client terminal and encrypting the multi-dimensional data to obtain device data. The server then calculates the similarity between the device data and the feature vectors in the pre-stored security threat database. Based on the calculation results, it determines whether the client terminal is a risky device. This breaks through the limitations of traditional fixed event types, realizes on-demand expansion and scenario adaptation of alarm content, and ensures encrypted transmission and storage throughout the process. It supports comparing the encrypted features uploaded by the client terminal with the security threat database without decryption, accurately identifying potential risky devices and improving the efficiency and accuracy of identifying security risky devices.

[0042] like Figure 1 As shown, an embodiment of this application provides a device alarm method, the method comprising: S101. Receive device data sent by the client terminal, wherein the device data is obtained by the client terminal encrypting one or more of static or dynamic features; Specifically, this application embodiment is applied to a server connected to client terminals. The number of client terminals is not specifically limited in this application. The client terminals send device data to the server at preset time intervals. The client terminals acquire one or more static features or dynamic data, and then use a preset encryption algorithm to encrypt the static features or dynamic features to obtain device data, i.e., encrypted feature vectors. Static features include at least one or more of the following: device identifier, hardware model, firmware version, operating system version, geographical location, or MAC address hash. Dynamic features include at least one or more of the following: network behavior patterns, CPU usage, and memory usage within a preset time period. By dynamically defining and encrypting multi-dimensional security features (such as behavioral fingerprints, environmental variables, abnormal indicators, etc.) through the client terminals, the limitations of traditional fixed event types are broken, and the alarm content can be expanded on demand and adapted to different scenarios, while ensuring encrypted transmission and storage throughout the process.

[0043] Specifically, the client terminal uses a preset encryption algorithm to encrypt one or more of the static or dynamic features to obtain device data. The preset encryption algorithm includes at least homomorphic encryption algorithm, symmetric algorithm, or asymmetric algorithm. By encrypting multi-dimensional data, the system achieves "data usable but not visible," eliminating the risk of plaintext leakage at the source.

[0044] S102. Based on the terminal identifier of the client terminal, store the device data in the container corresponding to the terminal identifier, and the container corresponds to the client terminal; After receiving device data sent by the client terminal, the server obtains the terminal identifier of the client terminal. At the same time, the server creates one or more containers and associates each container with a client terminal, storing the received device data in the corresponding container.

[0045] S103. Based on the device data and the pre-stored security threat database, determine whether the client terminal is a risky device, determine the target security threat type of the client terminal, and determine the alarm information based on the target security threat type. The pre-stored security threat database includes at least the security threat type and the preset feature vector corresponding to the security threat type.

[0046] Specifically, the server pre-establishes a security threat database based on different security threat types and corresponding preset feature vectors. These security threat types include at least Trojans, brute-force attacks, and lateral movement within an intranet. Upon receiving device data from a client terminal, the server calculates the similarity between this data and the pre-stored security threat database. Based on this similarity score, the server determines whether the client terminal is a risky device and, using the security threat database, identifies the target security threat type for the client terminal.

[0047] Some embodiments of this application obtain multi-dimensional data from various client terminals and encrypt the multi-dimensional data to obtain device data. The server then calculates the similarity between the device data and the feature vectors in the pre-stored security threat database. Based on the calculation results, it determines whether the client terminal is a risky device. This breaks through the limitations of traditional fixed event types, realizes on-demand expansion and scenario adaptation of alarm content, and ensures encrypted transmission and storage throughout the process. It supports comparing the encrypted features uploaded by the client terminal with the security threat database without decryption, accurately identifying potential risky devices and improving the efficiency and accuracy of identifying security risky devices.

[0048] Another embodiment of this application further supplements the device alarm method provided in the above embodiments.

[0049] This application proposes a device linkage alarm method and system based on encrypted feature similarity. By introducing privacy computing, encrypted feature matching and containerized isolation mechanisms, it realizes secure reporting of device features, server-side anonymized storage, rapid matching of accident features and linkage of privacy notifications.

[0050] The overall system architecture is as follows Figure 2 As shown, it specifically includes the following modules: Device-side privacy computation reporting module: The feature data (static features and dynamic features) is first obfuscated locally on the device, and then the obfuscated data is encrypted, for example, by homomorphic encryption or secure multi-party computation (SMPC) technology, to ensure that the uploaded data is "usable but not visible".

[0051] Server-side containerized feature-isolated storage: The server adopts a multi-container architecture, with each container handling only the device features of a specific device or tenant, preventing lateral data leakage.

[0052] Encryption Feature Incident Matching Engine: Constructs a security threat database based on encrypted data, supporting rapid comparison of encrypted device features with the security threat database (pre-set and saved feature vectors of various security threats) to identify potentially risky devices.

[0053] Privacy notification and alert linkage container: Design an independent notification service container that supports encrypted notification delivery. The recipient can decrypt the notification locally and then execute a linkage response (such as isolation, offline, log upload, etc.).

[0054] In this process, the client terminal performs feature data collection, encrypts the data, and then uploads the encrypted data to the server.

[0055] The device collects the following features through the privacy proxy module: Static characteristics: Device ID, hardware model, firmware version, operating system version, geographic location (latitude and longitude hash), MAC address hash, etc. Dynamic characteristics: Network behavior patterns (such as connection frequency and protocol distribution) and CPU / memory usage trends in the past 24 hours.

[0056] The above features are encrypted using the national cryptographic standard SM4-CBC, and the key is derived from the device certificate and uploaded to the server.

[0057] The server is equipped with an extensible encryption feature template, which supports the dynamic definition and encrypted reporting of multi-dimensional security features (such as behavioral fingerprints, environmental variables, and abnormal indicators) on the device side. This breaks through the limitations of traditional fixed event types, enables on-demand expansion and scenario adaptation of alarm content, and ensures encrypted transmission and storage throughout the process.

[0058] On the client terminal, sensitive features (device ID, geographical location, hardware fingerprint, etc.) are homomorphically encrypted or subjected to secure multi-party computation to generate ciphertext feature vectors, achieving "data usable but not visible" and eliminating the risk of plaintext leakage at the source.

[0059] Optionally, the method further includes: For each container, an encrypted feature index table is established, which includes at least the client terminal's terminal identifier, container identifier, device data, and timestamp.

[0060] Specifically, the server-side configuration includes multiple containers that store device data received from client terminals. Each receiving container verifies the device's identity (based on a certificate chain) and writes the encrypted device data to the corresponding storage container according to the tenant ID. Each container maintains an encryption feature index table for client terminals, with fields including: Encrypted device ID (SM4 encryption), encrypted feature vector (homomorphic encrypted numerical vector), timestamp, container ID, tenant ID (plaintext, used for routing).

[0061] By adopting an isolation architecture of "one device, one container" or "one tenant, one container", combined with client-side encrypted storage and RBAC fine-grained access control, the server cannot decrypt the original data, preventing internal leakage and unauthorized access.

[0062] Optionally, based on device data and a pre-stored security threat database, it can be determined whether the client terminal is a risky device and the target security threat type of the client terminal can be identified, including: Calculate similarity based on device data and preset feature vectors; Based on similarity and similarity threshold, determine whether the client terminal is a risky device; If the client terminal is a risky device, determine the type of target security threat to the client terminal.

[0063] Specifically, when a new security threat occurs, the server can automatically extract the encrypted feature vector of the new security threat and store it in the security threat database, supporting incremental updates and version rollback, and realizing continuous evolution of the feature database under privacy protection.

[0064] Some embodiments of this application enable the comparison of device data uploaded by a client terminal with feature vectors in a security threat database without decryption, thereby accurately identifying potentially risky devices.

[0065] Optionally, similarity is calculated based on device data and preset feature vectors, including: Calculate the cosine similarity between the encrypted feature vector of the device data and each preset feature vector in the security threat database. Some embodiments of this application calculate the cosine similarity between the encrypted feature vector of the client terminal and each preset feature vector in the security threat database, and determine whether the client terminal is a risky device based on the magnitude of the similarity.

[0066] Optionally, similarity is calculated based on device data and preset feature vectors, including: Based on the locality-sensitive hashing algorithm, an initial vector set matching the device data is determined in the security threat database; Calculate the cosine similarity between the encrypted feature vector of the device data and each preset feature vector in the initial vector set.

[0067] Some embodiments of this application use vector indexing, such as LSH (Local Sensitive Hash), to select a portion of the initial vector set. Then, based on the small portion of the initial vector set, the cosine similarity between the encrypted feature vector of the device data and each preset feature vector in the initial vector set is calculated, thereby improving the similarity calculation efficiency. Optionally, based on similarity and a similarity threshold, it can be determined whether a client terminal is a risky device, including: If the similarity is greater than the similarity threshold, the client terminal is determined to be a risky device. If the similarity is less than the similarity threshold, the client terminal is determined to be a security device.

[0068] Some embodiments of this application accurately identify potentially risky devices by comparing similarity and similarity thresholds.

[0069] Optionally, if the client terminal is a risky device, determine the type of target security threat to the client terminal, including: If the client terminal is a risky device, then it is based on the preset feature vector corresponding to the similarity. Based on the security threat database, determine the security threat type corresponding to the preset feature vector, and identify the security threat type as the target security threat type.

[0070] Specifically, when a security threat occurs on the server (such as a device being confirmed to be infected with a Trojan), the encrypted feature vector of the security threat is extracted and added to the "incident feature library container," i.e., the security threat database. The feature library supports incremental updates and version rollback, and records the event type (such as: Trojan, brute force, lateral movement within the intranet).

[0071] When the server receives device data sent by the client terminal, it stores the device data in the corresponding container to enable rapid response to important external events.

[0072] The encryption feature matching engine module on the server periodically (e.g., every 5 minutes) scans the encryption features of all devices and calculates ciphertext similarity with the security threat database. Using the Homomorphic Cosine Similarity algorithm, it can determine whether the feature vector similarity exceeds a threshold (e.g., 0.85) without decryption. If a match is successful, the client terminal is marked as a "potentially risky device," and an encryption alarm record is generated.

[0073] The alarm fields are shown below: Encrypt device ID, match event type, similarity score, and suggest response actions (isolation / observation / notification).

[0074] The server constructs an encrypted feature similarity calculation model, which supports millisecond-level comparison of encrypted features uploaded by devices with security incident feature databases without decryption, accurately identifying potentially risky devices and breaking through the bottleneck of traditional "plaintext analysis".

[0075] Optionally, the method further includes: The alarm information is returned to the client terminal, which includes at least the client terminal's terminal identifier, the type of target security threat, and the handling measures.

[0076] In this embodiment, after determining that the client terminal is a risky device and identifying the target security threat type of the client terminal, the server notifies the container to send encrypted notifications to the following objects based on the alarm records: On the device side (client terminal): an encrypted command (such as "Isolate the network immediately") is sent, and the device decrypts and executes it locally; Administrator: Send alarm summaries (excluding sensitive plaintext) via SM2 encrypted email / SMS. Emergency Response System: Pushes encrypted JSON messages via Webhook, supporting linkage with firewalls, EDR, and SOC platforms.

[0077] The notification content adopts a one-time key mechanism, with the key dynamically negotiated through DH key exchange to prevent man-in-the-middle attacks. An "encrypted notification channel" is designed to issue "one-time key encrypted instructions" (such as isolation, offline, and evidence collection) to risky devices or administrators. The recipient decrypts the instructions locally and executes a linked response to avoid leakage of the notification content during transmission or storage.

[0078] The embodiments of this application can be applied to devices that require status monitoring and network protection, and to security operations centers that need to manage daily and sensitive data of the devices.

[0079] For example, the server implements a multi-container architecture, where each container only handles specific types or tenant device characteristics to prevent lateral data leaks. The specific process is as follows: 1. Container partitioning: Start an independent container Pod for each tenant (client terminal): The mapping between Pod container name, feature storage, and tenant identifier A-001; Internally, only one SQLite-encrypted instance runs, located at: / data / tenantA_enc.db; 2. Data writing: The encrypted feature (Enc_Feature) uploaded by the client terminal is directly written to the DB database in the container Pod via the gRPC gateway, based on the tenant ID="tenant A"; Other tenant container Pods do not mount this path, and processes are isolated through Linux Namespaces to achieve "one tenant, one container; one container, one encrypted library," thus blocking lateral reads.

[0080] Furthermore, this embodiment of the application achieves second-level isolation of the "Cobalt Strike" Trojan, establishing a closed loop from encrypted features to coordinated response. The specific process is as follows: 1. Security event triggered; Device A (IP 192.168.10.15) has been identified as a CS Trojan, and its beacon heartbeat ciphertext feature vector Enc(vA) has been added to the database.

[0081] 2. Device B periodically submits encrypted reports; Device B (192.168.10.38) performs the following steps within the TEE: a) Collect the heart rate interval sequence of the most recent 30 minutes of behavior [302 s, 301 s, 299 s, 300 s]; b) Generate a 256-dimensional feature vector vB (including beacon mode frequency band energy). c) Calculate Enc(vB) using the homomorphic public key pk, and append a 128-bit MD5 random salt to prevent cross-time association; d) The packet size was 1.8 kB, and no plaintext was uploaded to the “Tenant-001” encrypted feature container (Container-F) via the TLS 1.3 channel.

[0082] 1. Online ciphertext similarity calculation Execute within the cryptographic signature matching engine container: cosθ = Enc(vA)·Enc(vB) / (||Enc(vA)||× ||Enc(vB)||); Using the CKKS scheme, a single homomorphic multiplication takes less than 18 ms, and the cosine result Enc(cosθ) = 0.89; the dynamic threshold δ is generated by feedback from the false alarm rate of the previous 7 days, with a value of δ = 0.85; since 0.89 > 0.85, risk marking is triggered, generating Risk-ID = 202507151005-B; The entire process is undecrypted, and the server cannot obtain any plaintext information of vA or vB.

[0083] 2. Issuance of one-time contactless isolation instructions The corresponding container "Tenant-001" of device B is notified to perform the following steps. a) Notify B to use the one-time key derived from B's device certificate public key pk_B; k = HKDF(pk_B || r, 256), where r is a 256-bit random number; b) Construct the JSON command: {"cmd":"network_isolate","ttl":300,"log":true} c) After SM2 encryption, Enc_pk_B(cmd) is obtained and pushed to B's privacy agent via gRPC; d) Simultaneously write to the encrypted audit log for retrospective review (decryption requires a judge's key).

[0084] 3. Device B decrypts and responds locally, with the following steps: a) Decrypt using the private key sk_B → Obtain the plaintext cmd; b) Call the netlink API to shut down all network interfaces except the management port; c) Generate an isolation report log_B.gz, encrypt it with the audit public key pk_audit, and upload it to the evidence container; 4. Closed loop between administrator and Security Operations Center (SOC): a) The administrator's email address received an SM2 encrypted email; Subject: [Automatic Handling] Suspected CS Trojan has been quarantined; The main text contains only the encrypted device ID and Risk-ID, with no sensitive plaintext. b) The SOC platform receives data via encrypted webhooks; POST / api / v1 / case Body: Enc_SK({"event":"cs_beacon","risk_id":"202507151005-B","evidence_container":"case-2025-0715-003"}) c) The SOC automatically launches the forensic Pod, mounts the evidence container, and begins a deep memory / disk scan → a cleanup report is generated after 30 minutes.

[0085] In one embodiment, this application provides a process for emergency response to public emergencies: 1. A security incident occurs: Event: 2025-08-03 06:12 (Beijing Time), issued a global alert for "MOVEit SQL injection" 0-day vulnerability, SHA-256 malicious sample hash: d14a2020…8f2e (abbreviated as H_mv); 2. Event Input (06:12:30) a) The SOC administrator pushes H_mv to the "accident signature database container" with one click through the "emergency interface"; b) The system automatically generates a homomorphic feature vector Enc(v_mv) (256 dimensions), writes it into the "Global Emergency" sub-database, version number T20250803-V1.0, and makes it available in a gray-scale version.

[0086] 3. Comparison of encrypted text across the entire network (06:12:45): a) The matching engine performs homomorphic cosine calculations on the most recently uploaded Enc(v_dev) and Enc(v_mv) of all online devices; b) If 17 devices are found to have cosθ ≥ 0.92, immediately generate an encrypted alarm record (containing only Enc(DeviceID), cosθ, and event number).

[0087] 4. One-time key group sending command (06:13:00) a) Instruct the container to use a one-time key derived from each device certificate and issue a "temporary network disconnection + snapshot" encryption command; b) Simultaneously push encrypted Webhook to domestic / overseas branch SOCs to trigger the local firewall to block MOVEit ports (443 / 9443).

[0088] 5. Device local response (06:13:15): a) The commands are decrypted within the TEE on 17 devices, the MOVEit service process is automatically shut down, and the virtual network card is isolated; b) The encrypted snapshot package is sent back to the evidence container, case number: MOVEit-20250803-CN.

[0089] 6. Administrator closed loop (06:17:00) The administrator received an SM2 encrypted email: Global MOVEit 0-day emergency response: 17 devices have been automatically isolated, and the evidence fingerprint SM3=abc123… can be audited without plaintext.

[0090] In the embodiments of this application, the encryption matching engine completes a ciphertext feature similarity calculation in the same experimental environment in no more than 1 / 10 of the traditional "decrypt-then-compare" process, and can be further linearly shortened with hardware acceleration (GPU / FPGA) to achieve near real-time response.

[0091] Linkage accuracy: Based on multi-dimensional encrypted feature matching, it can make full use of all the information in the original vector; under the same dataset and evaluation criteria, its false alarm rate is no higher than 1 / 4 of that of traditional rule engines, and it can continue to decrease as the incident database learns, significantly reducing invalid alarms.

[0092] Highly scalable: The containerized architecture supports millions of devices, as well as horizontal scaling and multi-tenant isolation.

[0093] It should be noted that each of the implementable methods in this embodiment can be implemented individually or in any combination without conflict. This application does not limit this.

[0094] Another embodiment of this application provides a device alarm apparatus for executing the device alarm method provided in the above embodiments.

[0095] like Figure 3 The diagram shown is a structural schematic of the device alarm device provided in this embodiment of the application. The device alarm device includes a receiving module 301, a storage module 302, and an alarm module 303, wherein: The receiving module 301 is used to receive device data sent by the client terminal, wherein the device data is obtained by the client terminal encrypting one or more of static features or dynamic features; The storage module 302 is used to store device data into a container corresponding to the terminal identifier based on the terminal identifier of the client terminal, and the container corresponds to the client terminal; The alarm module 303 is used to determine whether a client terminal is a risky device based on device data and a pre-stored security threat database, determine the target security threat type of the client terminal, and determine alarm information based on the target security threat type. The pre-stored security threat database includes at least security threat types and preset feature vectors corresponding to the security threat types.

[0096] Regarding the apparatus in this embodiment, the specific manner in which each module performs its operations has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0097] Some embodiments of this application obtain multi-dimensional data from various client terminals and encrypt the multi-dimensional data to obtain device data. The server then calculates the similarity between the device data and the feature vectors in the pre-stored security threat database. Based on the calculation results, it determines whether the client terminal is a risky device. This breaks through the limitations of traditional fixed event types, realizes on-demand expansion and scenario adaptation of alarm content, and ensures encrypted transmission and storage throughout the process. It supports comparing the encrypted features uploaded by the client terminal with the security threat database without decryption, accurately identifying potential risky devices and improving the efficiency and accuracy of identifying security risky devices.

[0098] Another embodiment of this application further supplements the description of the device alarm device provided in the above embodiments.

[0099] Optionally, the alarm module is used for: Calculate similarity based on device data and preset feature vectors; Based on similarity and similarity threshold, determine whether the client terminal is a risky device; If the client terminal is a risky device, determine the type of target security threat to the client terminal.

[0100] Some embodiments of this application enable the comparison of device data uploaded by a client terminal with feature vectors in a security threat database without decryption, thereby accurately identifying potentially risky devices.

[0101] Optionally, the alarm module is used for: Calculate the cosine similarity between the encrypted feature vector of the device data and each preset feature vector in the security threat database. Some embodiments of this application calculate the cosine similarity between the encrypted feature vector of the client terminal and each preset feature vector in the security threat database, and determine whether the client terminal is a risky device based on the magnitude of the similarity.

[0102] Optionally, the alarm module is used for: Based on the locality-sensitive hashing algorithm, an initial vector set matching the device data is determined in the security threat database; Calculate the cosine similarity between the encrypted feature vector of the device data and each preset feature vector in the initial vector set.

[0103] Some embodiments of this application use vector indexing, such as LSH (Local Sensitive Hash), to select a portion of the initial vector set. Then, based on the small portion of the initial vector set, the cosine similarity between the encrypted feature vector of the device data and each preset feature vector in the initial vector set is calculated, thereby improving the similarity calculation efficiency. Optionally, the alarm module is used for: If the similarity is greater than the similarity threshold, the client terminal is determined to be a risky device. If the similarity is less than the similarity threshold, the client terminal is determined to be a security device.

[0104] Some embodiments of this application accurately identify potentially risky devices by comparing similarity and similarity thresholds.

[0105] Optionally, the alarm module is used for: If the client terminal is a risky device, then it is based on the preset feature vector corresponding to the similarity. Based on the security threat database, determine the security threat type corresponding to the preset feature vector, and identify the security threat type as the target security threat type.

[0106] Optionally, static features include at least one or more of the following: device identifier, hardware model, firmware version, operating system version, geographical location, or MAC address hash; dynamic features include at least one or more of the following: network behavior patterns, CPU utilization, and memory utilization over a preset time period.

[0107] Some embodiments of this application dynamically define and encrypt the reporting of multi-dimensional security features (such as behavioral fingerprints, environmental variables, abnormal indicators, etc.) on the device side, breaking through the limitations of traditional fixed event types, realizing on-demand expansion and scenario adaptation of alarm content, while ensuring encrypted transmission and storage throughout the process.

[0108] Optionally, device data can be obtained in the following ways: The client terminal uses a preset encryption algorithm to encrypt one or more of the static or dynamic features to obtain device data. The preset encryption algorithm includes at least a homomorphic encryption algorithm, a symmetric algorithm, or an asymmetric algorithm.

[0109] Some embodiments of this application encrypt multi-dimensional data to achieve "data usable but not visible," thus eliminating the risk of plaintext leakage at the source.

[0110] Optionally, the alarm module is used for: For each container, an encrypted feature index table is established, which includes at least the client terminal's terminal identifier, container identifier, device data, and timestamp.

[0111] Optionally, the alarm module is used for: The alarm information is returned to the client terminal, which includes at least the client terminal's terminal identifier, the type of target security threat, and the handling measures.

[0112] Regarding the apparatus in this embodiment, the specific manner in which each module performs its operations has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0113] It should be noted that each of the implementable methods in this embodiment can be implemented individually or in any combination without conflict. This application does not limit this.

[0114] This application also provides a computer-readable storage medium storing a computer program thereon. When the program is executed by a processor, it can perform the operation of any of the methods corresponding to the device alarm methods provided in the above embodiments.

[0115] This application also provides a computer program product, which includes a computer program, wherein when the computer program is executed by a processor, it can implement the operation of any of the methods corresponding to the embodiments of the device alarm methods provided above.

[0116] like Figure 4 As shown, some embodiments of this application provide an electronic device 400, which includes a memory 410, a processor 420, and a computer program stored in the memory 410 and executable on the processor 420. When the processor 420 reads the program from the memory 410 via a bus 430 and executes the program, it can implement any of the methods included in the above-described device alarm method.

[0117] Processor 420 can process digital signals and may include various computing architectures. For example, it may be a complex instruction set computer architecture, a reduced instruction set computer architecture, or an architecture that implements multiple instruction set combinations. In some examples, processor 420 may be a microprocessor.

[0118] Memory 410 can be used to store instructions executed by processor 420 or data related to the execution of instructions. These instructions and / or data may include code for implementing some or all of the functions of one or more modules described in the embodiments of this application. The processor 420 of this disclosure embodiment can be used to execute instructions in memory 410 to implement the methods shown above. Memory 410 includes dynamic random access memory, static random access memory, flash memory, optical memory, or other memories well known to those skilled in the art.

[0119] The above are merely embodiments of this application and are not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application. It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0120] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0121] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Claims

1. A device alarm method, characterized in that, The method includes: The device receives device data sent by a client terminal, wherein the device data is obtained by the client terminal encrypting one or more of static or dynamic features; Based on the terminal identifier of the client terminal, the device data is stored in a container corresponding to the terminal identifier, and the container corresponds to the client terminal; Based on the device data and a pre-stored security threat database, it is determined whether the client terminal is a risky device, and the target security threat type of the client terminal is determined. Based on the target security threat type, an alarm message is determined. The pre-stored security threat database includes at least security threat types and preset feature vectors corresponding to the security threat types.

2. The equipment alarm method according to claim 1, characterized in that, The step of determining whether the client terminal is a risky device and identifying the target security threat type of the client terminal based on the device data and a pre-stored security threat database includes: Calculate the similarity based on the device data and the preset feature vector; Based on the similarity and similarity threshold, determine whether the client terminal is a risky device; If the client terminal is a risky device, determine the target security threat type of the client terminal.

3. The equipment alarm method according to claim 2, characterized in that, The step of calculating similarity based on the device data and the preset feature vector includes: Calculate the cosine similarity between the encrypted feature vector of the device data and each preset feature vector in the security threat database.

4. The equipment alarm method according to claim 2, characterized in that, The step of calculating similarity based on the device data and the preset feature vector includes: Based on the locality-sensitive hashing algorithm, an initial vector set matching the device data is determined in the security threat database; Calculate the cosine similarity between the encrypted feature vector of the device data and each preset feature vector in the initial vector set.

5. The equipment alarm method according to claim 2, characterized in that, The step of determining whether the client terminal is a risky device based on the similarity and similarity threshold includes: If the similarity is greater than the similarity threshold, then the client terminal is determined to be a risky device; If the similarity is less than the similarity threshold, the client terminal is determined to be a security device.

6. The equipment alarm method according to claim 5, characterized in that, If the client terminal is a risky device, determining the target security threat type of the client terminal includes: If the client terminal is a risky device, then according to the preset feature vector corresponding to the similarity; Based on the security threat database, the security threat type corresponding to the preset feature vector is determined, and the security threat type is determined as the target security threat type.

7. The equipment alarm method according to claim 1, characterized in that, The static features include at least one or more of the following: device identifier, hardware model, firmware version, operating system version, geographical location, or MAC address hash; the dynamic features include at least one or more of the following: network behavior pattern within a preset time period, CPU usage, and memory usage; the client terminal uses a preset encryption algorithm to encrypt one or more of the static features or the dynamic features to obtain the device data, wherein the preset encryption algorithm includes at least a homomorphic encryption algorithm, a symmetric algorithm, or an asymmetric algorithm.

8. The equipment alarm method according to claim 4, characterized in that, The method further includes: For each container, an encrypted feature index table is established, wherein the encrypted feature index table includes at least the client terminal's terminal identifier, the container identifier, the device data, and the timestamp.

9. The equipment alarm method according to claim 1, characterized in that, The method further includes: The alarm information is returned to the client terminal, wherein the alarm information includes at least the client terminal's terminal identifier, the target security threat type, and the handling measures.

10. An electronic device, characterized in that, The device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the device alarm method according to any one of claims 1-9.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, characterized in that, when the program is executed by a processor, it can implement the device alarm method according to any one of claims 1-9.

12. A computer program product, said computer program product comprising a computer program, wherein, When the computer program is executed by a processor, it can implement the device alarm method according to any one of claims 1-9.

Images