A method and related device for behavior anomaly detection based on cryptographic accumulators

Abstract

The present application relates to a kind of behavior anomaly detection method based on cryptography accumulator and related equipment.Method includes: to behavior log data execution standardization processing, extract behavior characteristics, execute cryptography hash operation, generate behavior element;Determine sparse behavior element, construct sparse behavior set;Determine first normal behavior element, execute cryptography hash operation to known normal behavior and generate second normal behavior element, construct normal behavior element set;Based on each behavior element and its weight, construct frequency weighted cryptography accumulator, obtain normal behavior accumulator;Sparse behavior element in sparse behavior set is as to-be-detected behavior element, based on normal behavior accumulator, generate the membership proof or non-membership proof of to-be-detected behavior element;According to the verification result of membership proof or non-membership proof, determine whether to-be-detected behavior is abnormal behavior.The method improves detection accuracy, enhances the credibility of detection result, reduces storage overhead.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method and related equipment for detecting behavioral anomalies based on cryptographic accumulators. Background Technology

[0002] A cryptographic accumulator is a cryptographic primitive capable of compressing a dataset of arbitrary size into a single short value and efficiently generating membership or non-membership proofs for any element in the dataset. User and Entity Behavior Analytics (UEBA) is an important technology in the field of cybersecurity. It establishes behavioral patterns and identifies anomalous activities that deviate from the norm by collecting and analyzing behavioral logs of entities such as users, devices, and applications.

[0003] In related technologies, existing UEBA systems typically employ the following methods for anomaly detection: rule-based behavior matching methods, statistical model-based anomaly scoring methods, machine learning or deep learning-based behavior clustering and classification methods, and graph-based attack path analysis methods. Furthermore, some solutions utilize data structures such as Bloom filters, Merkle trees, hash indexes, and Sketch structures to accelerate queries.

[0004] However, the aforementioned related technologies have at least the following problems: First, UEBA systems require continuous modeling of long-term historical behavioral data to establish behavioral baselines. These technologies generally employ full log storage, inverted indexes, and graph databases for data storage and retrieval, requiring the preservation of large amounts of raw behavioral data and frequent log traversal, feature comparison, and graph path search operations during detection, resulting in high storage overhead and low query efficiency. Second, abnormal behaviors in actual attack scenarios typically exhibit significant sparsity and long-tail characteristics, such as rarely occurring IP address access, logins from unconventional regions, low-frequency domain name access, and rare API (Application Program Interface) call combinations. These behaviors account for a very small percentage of the overall logs but are often strongly correlated with attack activities. The related technologies rely on large samples for statistical modeling or model training, making it difficult to effectively identify such low-frequency behaviors. Third, existing UEBA systems typically output statistical results such as risk scores, anomaly probabilities, and cluster deviations, which are essentially probabilistic inferences or model predictions. The detection basis is unclear, interpretability is weak, and it is difficult to independently verify the detection results afterward, leading to insufficient credibility in high-security scenarios. Fourth, Bloom filters suffer from false positives; the proof path length of Merkle trees increases with the data size; existing data structures are mainly used for data integrity verification or hash indexing, lacking a dedicated modeling mechanism for membership relationships in behavioral sets.

[0005] There are currently no effective solutions to the problems of insufficient detection accuracy, lack of verifiability of detection results, difficulty in balancing storage efficiency and detection reliability, and limited applicability of behavioral anomaly detection schemes in related technologies. Summary of the Invention

[0006] The present invention provides a method and related equipment for detecting behavioral anomalies based on cryptographic accumulators, which at least partially solves the problems of insufficient detection accuracy, lack of verifiability of detection results, difficulty in balancing storage efficiency and detection reliability, and limited applicable scenarios in related technologies.

[0007] To address the aforementioned problems, one aspect of this invention provides a method for detecting behavioral anomalies based on a cryptographic accumulator, comprising: Obtain user or entity behavior log data, perform standardization processing on the behavior log data, extract behavior features from the obtained standardized behavior data, perform cryptographic hash operation on the behavior features, and generate behavior elements; The occurrence frequency of each behavioral element within a preset time window is counted. Behavioral elements whose occurrence frequency is less than or equal to a preset sparse threshold are identified as sparse behavioral elements, and a sparse behavioral set is constructed. Behavioral elements whose occurrence frequency is greater than the sparse threshold are identified as first normal behavioral elements. The cryptographic hash operation is performed on the pre-configured known normal behaviors to generate second normal behavioral elements. A normal behavioral element set is constructed based on the first normal behavioral elements and the second normal behavioral elements. The frequency of occurrence of each behavior element in the set of normal behavior elements is used as the weight of the corresponding behavior element, and the frequency of occurrence of the second normal behavior element is a pre-configured number; a frequency-weighted cryptographic accumulator is constructed based on each behavior element and its weight to obtain a normal behavior accumulator; wherein, the normal behavior accumulator compresses the set of normal behavior elements into a single accumulated value. The sparse behavior elements in the sparse behavior set are taken as the behavior elements to be detected. Membership proof or non-membership proof of the behavior elements to be detected is generated based on the normal behavior accumulator. The detection result of the membership proof or the non-membership proof is used to determine whether the behavior to be detected corresponding to the behavior element to be detected is an abnormal behavior, and the abnormal detection result is output. When the verification result indicates that the behavior element to be detected does not belong to the normal behavior element set, the behavior to be detected is determined to be an abnormal behavior.

[0008] In some embodiments, the step of constructing a frequency-weighted cryptographic accumulator based on each behavioral element and its weight to obtain a normal behavioral accumulator includes: For each behavior element in the set of normal behavior elements, calculate the weighted value of the behavior element and the preset private parameter, and use the weight of the behavior element as the exponent to exponentiate the weighted value to obtain the weighted exponent term corresponding to the behavior element. Multiply the weighted exponent terms corresponding to all behavioral elements in the set of normal behavioral elements to obtain an exponential product; use the exponential product as the exponent of the generator to perform an exponentiation operation to obtain the accumulated value of the normal behavioral accumulator; wherein, the generator is the generator in the algebraic group on which the frequency-weighted cryptographic accumulator is based.

[0009] In some of these embodiments, a distributed collaborative verification step is also included: Multiple security nodes maintain their own local behavior log data. Each security node constructs a corresponding local normal behavior accumulator based on its local behavior log data. The local normal behavior accumulator adopts the construction method of the frequency-weighted cryptographic accumulator. Moreover, the local normal behavior accumulator of each security node uses its own corresponding independent behavior domain parameters. The independent behavior domain parameters enable the same behavior element to have different accumulation expressions in the accumulators of different security nodes. When any security node determines a behavior element to be detected, the security node generates a local behavior proof of the behavior element to be detected based on its local normal behavior accumulator, and sends the local behavior proof, the node identifier of the security node and the accumulator digest of its local normal behavior accumulator to the central verification node. The central verification node determines the corresponding security node based on the node identifier, verifies the behavior element to be detected based on the local normal behavior accumulator of the security node, and determines whether the behavior to be detected is abnormal based on the verification result.

[0010] In some embodiments, the method further includes: When a new behavior element is obtained, the weighted result of the new behavior element and the preset private parameter is used as the exponent to perform an exponentiation operation on the current accumulated value of the normal behavior accumulator to obtain the updated accumulated value. When it is necessary to delete a behavior element from the set of normal behavior elements, the modulo inverse of the weighted result of the deleted behavior element and the preset private parameter is used as the exponent to perform an exponentiation operation on the current accumulated value of the normal behavior accumulator to obtain the updated accumulated value; wherein, the deleted behavior elements include behavior elements that are eliminated as the time window slides.

[0011] In some embodiments, the preset sparsity threshold is determined in the following ways: Set a fixed value as the preset sparsity threshold; Alternatively, the preset sparsity threshold can be dynamically determined according to the statistical distribution of the occurrence frequency of the behavioral elements and a pre-configured dynamic threshold rule.

[0012] In some embodiments, the step of counting the number of occurrences of each behavioral element within a preset time window includes: Based on the time information of the behavior log data, the time interval between each behavior element and the current time is determined. The occurrence count is then reduced using a time decay function to obtain the decayed count. The time decay function decreases as the time interval increases, so that behavior elements closer to the current time correspond to a larger decayed count, and behavior elements farther from the current time correspond to a smaller decayed count. The decayed count is taken as the occurrence count of the corresponding behavioral element.

[0013] In some embodiments, the frequency-weighted cryptographic accumulator is constructed using a bilinear mapping-based cryptographic accumulator method, wherein the bilinear mapping employs bilinear pairing operations corresponding to the BLS12-381 curve or the BN254 curve.

[0014] In some embodiments, the step of constructing a frequency-weighted cryptographic accumulator based on each behavioral element and its weight to obtain a normal behavioral accumulator further includes: The occurrence count of each behavioral element in the set of normal behavioral elements is compressed using a preset mapping function, mapping the original occurrence count to a preset numerical range to obtain a compressed weight value. The compressed weight value is then used to replace the original occurrence count in the construction of the frequency-weighted cryptographic accumulator.

[0015] To address the aforementioned problems, one aspect of this invention provides a behavior anomaly detection device based on a cryptographic accumulator, comprising: The behavior element generation module is used to acquire user or entity behavior log data, perform standardization processing on the behavior log data, extract behavior features from the obtained standardized behavior data, perform cryptographic hash operation on the behavior features, and generate behavior elements. The behavior set construction module is used to count the number of times each behavior element appears within a preset time window, determine the behavior elements whose number of occurrences is less than or equal to a preset sparse threshold as sparse behavior elements, and construct a sparse behavior set; determine the behavior elements whose number of occurrences is greater than the sparse threshold as first normal behavior elements, and perform the cryptographic hash operation on the pre-configured known normal behaviors to generate second normal behavior elements, and construct a normal behavior element set based on the first normal behavior elements and the second normal behavior elements; An accumulator construction module is used to use the occurrence frequency of each behavior element in the set of normal behavior elements as the weight of the corresponding behavior element, and the occurrence frequency of the second normal behavior element is a pre-configured number; a frequency-weighted cryptographic accumulator is constructed based on each behavior element and its weight to obtain a normal behavior accumulator; wherein, the normal behavior accumulator compresses the set of normal behavior elements into a single accumulated value. An anomaly detection module is used to take sparse behavior elements in the sparse behavior set as behavior elements to be detected, generate membership proof or non-member proof of the behavior elements to be detected based on the normal behavior accumulator, determine whether the behavior to be detected corresponding to the behavior element to be detected is an anomalous behavior based on the verification result of the membership proof or the non-member proof, and output the anomaly detection result; wherein, when the verification result indicates that the behavior element to be detected does not belong to the normal behavior element set, the behavior to be detected is determined to be an anomalous behavior.

[0016] To address the aforementioned problems, one aspect of this invention provides a non-transitory machine-readable medium storing computer instructions for causing a computer to execute any of the aforementioned cryptographic accumulator-based behavior anomaly detection methods.

[0017] The beneficial effects of this invention are as follows: By acquiring user or entity behavior log data, performing standardization processing on the behavior log data, extracting behavior features from the obtained standardized behavior data, performing cryptographic hash operations on the behavior features to generate behavior elements; counting the occurrence frequency of each behavior element within a preset time window, determining behavior elements with an occurrence frequency less than or equal to a preset sparse threshold as sparse behavior elements, and constructing a sparse behavior set; determining behavior elements with an occurrence frequency greater than the sparse threshold as first normal behavior elements, and performing cryptographic hash operations on pre-configured known normal behaviors to generate second normal behavior elements, based on the first and second normal behavior elements... Construct a set of normal behavior elements; use the frequency of occurrence of each behavior element in the set as the weight of the corresponding behavior element, and the frequency of occurrence of the second normal behavior element is a pre-configured number; construct a frequency-weighted cryptographic accumulator based on each behavior element and its weight to obtain the normal behavior accumulator; wherein, the normal behavior accumulator compresses the set of normal behavior elements into a single accumulated value; take the sparse behavior elements in the sparse behavior set as the behavior elements to be detected, and generate membership proofs or non-member proofs for the behavior elements to be detected based on the normal behavior accumulator; determine whether the behavior to be detected corresponding to the behavior element to be detected is an abnormal behavior based on the verification result of the membership proof or non-member proof, and output the result. Anomaly detection results; specifically, when the verification result indicates that the behavior to be detected does not belong to the set of normal behavior elements, the technical means of determining the behavior to be detected as an anomaly; overcoming the problems of insufficient detection accuracy, lack of verifiability of detection results, difficulty in balancing storage efficiency and detection reliability, and limited applicable scenarios in related technologies; by standardizing behavior log data, extracting behavior features, and generating unified behavior elements through cryptographic hash mapping, a data foundation for frequency statistics and set operations is provided; then, frequency statistics and sparse threshold division are performed on the behavior elements, accurately converging the detection focus from massive behavior logs to low-frequency behaviors, and using pre-configured hash fusion of known normal behaviors. The system ensures the integrity of the set of normal behavior elements. Then, the frequency of each behavior element in the set is embedded as a weight into the exponential structure of the cryptographic accumulator, compressing the set of normal behavior elements into a single accumulated value. This preserves both the membership and frequency information of the elements within constant-level storage space. Finally, the accumulator's membership and non-membership proof mechanisms are used to verify the sparse behavior elements. This achieves compressed storage of the behavior element set, targeted detection of sparse behavior elements, and verifiable confirmation of the detection results. The technical effects of this approach are improved detection accuracy, enhanced reliability of detection results, reduced storage overhead, and expanded applicability of the solution.

[0018] Details of one or more embodiments of the present invention are set forth in the following drawings and description, so that other features, objects and advantages of the invention will be more readily understood. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other embodiments can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a schematic diagram of the main flow of a behavior anomaly detection method based on a cryptographic accumulator, according to one embodiment of the present invention. Figure 2 This is a schematic diagram of the main modules of a behavior anomaly detection device based on a cryptographic accumulator according to one embodiment of the present invention; Figure 3 This is a schematic diagram of the electronic device of the present invention. Detailed Implementation

[0021] Embodiments of the present invention will now be described in more detail with reference to the accompanying drawings. While some embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the invention. It should be understood that the accompanying drawings and embodiments are for illustrative purposes only and are not intended to limit the scope of protection of the invention.

[0022] To more clearly illustrate the solutions of the embodiments of the present invention, the main technical terms involved in the embodiments of the present invention are briefly explained as follows: Behavioral element: refers to a fixed-length hash value obtained by performing a cryptographic hash operation on the behavioral features extracted from behavioral log data. It is used to uniquely and irreversibly identify a specific behavioral feature in cryptographic operations.

[0023] Sparse behavioral elements: These are behavioral elements that appear less than or equal to a preset sparse threshold number of times within a preset time window. They correspond to behaviors that have low frequency characteristics in statistics and are the focus of anomaly detection.

[0024] The first normal behavior element refers to the behavior element that appears more often than the preset sparsity threshold within the preset time window. It corresponds to behaviors that have high frequency characteristics in statistics and represents the normal operation mode of users or entities.

[0025] The second normal behavior element refers to the behavior element generated after performing a cryptographic hash operation on pre-configured known normal behaviors (including historical stable behaviors, whitelisted behaviors, legitimate business behaviors, and known trusted behaviors), which is used to incorporate externally known normal behavior patterns into the normal behavior baseline.

[0026] Frequency-weighted cryptographic accumulator: A cryptographic accumulator that uses the frequency of occurrence of elements in a set as weights to embed into the mathematical structure of the accumulator.

[0027] Membership proof: Cryptographic evidence generated by a cryptographic accumulator to prove that a particular element belongs to the set represented by the accumulator. The verifier can use this evidence to confirm that the element does indeed belong to the set.

[0028] Non-membership proof: Cryptographic evidence generated by a cryptographic accumulator to prove that a specific element does not belong to the set represented by the accumulator. The verifier can use this evidence to confirm that the element does not belong to the set.

[0029] Normal Behavior Accumulator: A frequency-weighted cryptographic accumulator constructed based on the frequency weights of each behavior element in the set of normal behavior elements. It compresses the set of normal behavior elements into a single accumulated value, which serves as the benchmark for subsequent anomaly detection.

[0030] Security nodes refer to independent security components or devices in large enterprise networks or cloud environments that are responsible for collecting and analyzing behavioral logs within a specific scope, such as VPN (Virtual Private Network) gateway nodes, endpoint detection and response nodes, database audit nodes, cloud workload nodes, etc.

[0031] Independent behavior domain parameters: These are the private parameters that each security node uses when constructing its local normal behavior accumulator, and are unique to that node. The independent behavior domain parameters for different security nodes are different. That is, for any two different security nodes, the corresponding independent behavior domain parameters are different, so as to ensure that the accumulator of each security node has a unique mathematical structure and accumulation expression.

[0032] Local Normal Behavior Accumulator: This refers to a frequency-weighted cryptographic accumulator built by a secure node based on its local behavior log data, used to compress and express the set of normal behavior elements within the scope of the secure node.

[0033] Accumulator digest: refers to the single accumulated value output by the frequency-weighted cryptographic accumulator, that is, the compressed expression of the accumulator, which is used as a benchmark value in the verification calculation of membership proof or non-member proof during the verification process.

[0034] Local behavior proof: refers to the membership or non-membership proof generated by a secure node for a behavior element to be detected based on its local normal behavior accumulator. It is used to prove the set membership of the behavior element to the central verification node without transmitting the original behavior log data.

[0035] Central Verification Node: A centralized verification component responsible for receiving behavioral proofs, node identifiers, and accumulator digests sent by each security node, and for completing the verification and judgment of abnormal behavior based on the above information.

[0036] To address the aforementioned problems, embodiments of the present invention provide a method for detecting behavioral anomalies based on cryptographic accumulators, such as... Figure 1 As shown, this behavior anomaly detection method based on cryptographic accumulators mainly includes: Step S101: Obtain user or entity behavior log data, perform standardization processing on the behavior log data, extract behavior features from the obtained standardized behavior data, perform cryptographic hash operation on the behavior features, and generate behavior elements; Step S102: Count the number of occurrences of each behavior element within a preset time window, determine the behavior elements whose occurrence count is less than or equal to a preset sparse threshold as sparse behavior elements, and construct a sparse behavior set; determine the behavior elements whose occurrence count is greater than the sparse threshold as first normal behavior elements, and perform cryptographic hash operation on the pre-configured known normal behaviors to generate second normal behavior elements, and construct a normal behavior element set based on the first normal behavior elements and the second normal behavior elements. Step S103: The frequency of occurrence of each behavior element in the set of normal behavior elements is used as the weight of the corresponding behavior element, and the frequency of occurrence of the second normal behavior element is a pre-configured number; a frequency-weighted cryptographic accumulator is constructed based on each behavior element and its weight to obtain the normal behavior accumulator; wherein, the normal behavior accumulator compresses the set of normal behavior elements into a single accumulated value. Step S104: Take the sparse behavior elements in the sparse behavior set as the behavior elements to be detected, and generate the membership proof or non-member proof of the behavior elements to be detected based on the normal behavior accumulator; determine whether the behavior to be detected corresponding to the behavior element to be detected is an abnormal behavior based on the verification result of the membership proof or non-member proof, and output the abnormal detection result; wherein, when the verification result indicates that the behavior element to be detected does not belong to the normal behavior element set, the behavior to be detected is determined to be an abnormal behavior.

[0037] Based on the above setup, a unified set of behavioral elements is generated by standardizing behavioral log data, extracting behavioral features, and performing cryptographic hash mapping, providing a data foundation for frequency statistics and set operations. Then, frequency statistics and sparse thresholding are applied to the behavioral elements, precisely converging the detection focus from massive behavioral logs to low-frequency behaviors. The integrity of the normal behavioral element set is ensured by hash fusion of pre-configured known normal behaviors. Next, the frequency of each behavioral element in the normal behavioral element set (i.e., the number of times it appears within a preset time window) is embedded as a weight into the exponential structure of the cryptographic accumulator, compressing the normal behavioral element set into a single accumulated value. This preserves both the element's membership and frequency information within constant-level storage space. Finally, the accumulator's membership and non-membership proof mechanisms are used to verify the sparse behavioral elements. This achieves compressed storage of the behavioral element set, targeted detection of sparse behavioral elements, and verifiable confirmation of detection results, thereby improving detection accuracy, enhancing the credibility of detection results, reducing storage overhead, and expanding the applicability of the solution.

[0038] Specifically, in enterprise network environments, behavior logs come from diverse sources, including user login logs, network connection logs, file access logs, API call logs, database access logs, and process startup logs. Logs from different sources differ in field definitions, time formats, and entity identification methods, making it impossible to directly perform unified frequency statistics and aggregator operations on this heterogeneous data. In this embodiment of the invention, based on the aforementioned step S101, heterogeneous behavior log data from different data sources is transformed into unified, fixed-length, irreversible behavior elements, enabling subsequent frequency statistics and accumulator construction to be performed on a unified data foundation. The standardization process eliminates the aforementioned differences by unifying log formats from different sources, aligning and calibrating time fields, and normalizing and disambiguating entity identifiers, enabling all log data to be expressed in a unified vector space or encoding space. Based on this, cryptographic hashing is performed on behavioral features. Due to the deterministic (the same input always produces the same output) and uniform distribution (the outputs from different inputs are uniformly distributed across the value range) mathematical properties of hashing, identical behavioral features are mapped to the same behavioral elements, and different behavioral features are mapped to different behavioral elements with a very high probability. The behavioral elements generated by hashing have a fixed length, unaffected by the length of the original behavioral features, facilitating efficient storage and comparison operations. Furthermore, the irreversibility of hashing ensures that the original behavioral features cannot be derived from the behavioral elements, protecting the privacy of the original behavioral data in security analysis scenarios.

[0039] Meanwhile, anomalous behaviors in the behavior log data statistically exhibit long-tail characteristics, meaning that a large number of anomalous behaviors occur very infrequently in the overall log. According to an embodiment of the present invention, based on the above step S102, behavioral elements are divided into two categories according to their frequency of occurrence: sparse behavioral elements and normal behavioral elements. Simultaneously, pre-configured known normal behaviors are included in the normal behavioral element set, so that the normal behavioral element set simultaneously contains both high-frequency historical behavioral elements and pre-configured normal behavioral elements. This allows subsequent non-membership proofs based on the normal behavior accumulator to effectively distinguish between "rare but normal" behaviors and "truly anomalous" behaviors. Specifically, by counting the number of times each behavioral element appears within a preset time window, the frequency distribution of each behavioral element within a specific time period can be obtained. A preset sparse threshold serves as an adjustable statistical boundary, dividing the frequency distribution into low-frequency and high-frequency intervals. Behavioral elements with an occurrence frequency less than or equal to the preset sparse threshold constitute the low-frequency interval, corresponding to a candidate set of potential abnormal behaviors. Behavioral elements with an occurrence frequency greater than the preset sparse threshold constitute the high-frequency interval, corresponding to statistically stable and representative behavioral patterns. This frequency-based binary division enables the system to accurately converge its detection focus from massive behavioral logs to low-frequency behaviors, avoiding unnecessary cryptographic operations on high-frequency normal behaviors.

[0040] Furthermore, relying solely on frequency-based classification presents a logical problem: some behaviors, while statistically low-frequency, may actually be normal behaviors, such as compliance operations performed only once a month by a specific administrator. Directly classifying all these behaviors as abnormal would lead to numerous false positives. To address this derivative problem, this embodiment of the invention, based on step S102, uses pre-configured known normal behaviors, processed with the same cryptographic hash operation, as the second normal behavior element. This second normal behavior element, along with the high-frequency behavior element (i.e., the first normal behavior element), constitutes the normal behavior element set. Since both the first and second normal behavior elements are generated through the same cryptographic hash operation, their representation in the encoding space is completely identical, allowing for unified membership verification within the same normal behavior accumulator. When a low-frequency behavior element actually belongs to the known normal behavior set, it will necessarily exist in the normal behavior element set. Subsequent non-membership verification based on the normal behavior accumulator will return a result indicating "belongs to the normal set," thus avoiding false positives.

[0041] Standard cryptographic accumulators perform only one operation on each element in a set, limiting their expressive power to the binary relation of "whether an element belongs to the set," and failing to describe the frequency or activity level of elements within the set. However, in behavioral analysis scenarios, the frequency of occurrence of different normal behavioral elements has significant distinguishing value. High-frequency behaviors reflect the regular operating patterns of users or entities, while low-frequency but normal behaviors reflect special but compliant operations. According to an embodiment of the present invention, based on the above step S103, the frequency of occurrence of each behavioral element in the set of normal behavioral elements is embedded as a weight into the mathematical structure of the cryptographic accumulator. This allows the accumulator to not only represent the existence of elements in the set but also reflect the activity level of each element, while compressing the entire set of normal behavioral elements into a single accumulated value, significantly reducing storage overhead. Specifically, by introducing the occurrence count of each behavioral element as a weight into the mathematical construction of the accumulator, the internal structure of the accumulator is changed. The larger the weight, the greater the contribution of the behavioral element to the accumulated value. When generating non-membership proofs subsequently, the weight information is already embedded in the accumulator structure, eliminating the need to additionally store the occurrence count of each behavioral element. Meanwhile, the accumulator's cumulative product structure ensures that regardless of the number of behavioral elements in the normal behavior element set, they are ultimately compressed into a single accumulated value. The length of this single accumulated value is fixed and does not increase with the number of elements in the set, achieving constant-level compressed storage of the normal behavior element set. It should also be noted that the second normal behavior element originates from pre-configured known normal behaviors, such as historically stable behaviors, whitelisted behaviors, legitimate business behaviors, and known trusted behaviors. These behavioral elements themselves have not undergone frequency statistics; their occurrence frequency is mathematically preset to a configuration value, typically 1 or other set values, to ensure a deterministic mathematical contribution in the accumulator construction, guaranteeing that the accumulator correctly reflects the membership of these pre-configured elements in the normal behavior set.

[0042] Existing UEBA systems rely on probability or statistical inference for anomaly detection. Their outputs (such as risk scores and anomaly probabilities) are essentially estimates, unable to provide a definitive conclusion on whether a behavior truly belongs to the set of normal behaviors, nor can the correctness of the detection results be independently verified afterward. According to an embodiment of the present invention, based on the aforementioned step S104, the anomaly detection problem is transformed from probabilistic inference of statistical deviation to deterministic verification of set membership. Verifiable determination of sparse behaviors is achieved through membership proofs or non-member proofs, giving the detection results a clear and independently verifiable cryptographic basis. When a system uses sparse behavioral elements as the behavioral elements to be detected, its mathematical essence is to determine whether the behavioral element belongs to the set of normal behavioral elements. Based on the normal behavioral accumulator, the system can generate a membership proof (if the element belongs to the normal set) or a non-membership proof (if the element does not belong to the normal set) for the behavioral element to be detected. The mathematical basis of the above proof is the security and correctness of the accumulator: according to the mathematical properties of cryptographic accumulators, only elements that truly belong to the set represented by the accumulator can generate a valid membership proof, and only elements that truly do not belong to the set represented by the accumulator can generate a valid non-membership proof. The verifier does not need to access the complete set of behavioral elements; it only needs to hold the normal accumulator value and the corresponding proof to complete the verification independently. When the verification result indicates that the behavioral element to be detected does not belong to the set of normal behavioral elements, the judgment result has a definite cryptographic meaning, that is, if a certain behavioral element is mathematically proven to be different from all elements in the set of normal behavioral elements, the corresponding behavioral element to be detected is determined to be an abnormal behavior. The above judgment process does not involve probability estimation or statistical assumptions, does not rely on any threshold selection, and is not affected by sample distribution bias. Therefore, the detection results have the characteristics of being independently verifiable and traceable and auditable.

[0043] In some of these embodiments, the pre-configured known normal behaviors include at least one of historical stable behaviors, whitelisted behaviors, legitimate business behaviors, and known trusted behaviors.

[0044] Pre-configured known normal behaviors: refers to the set of normal behaviors that are pre-set and configured by administrators or security operations personnel before or during system operation. These include historical stable behaviors, whitelisted behaviors, legitimate business behaviors, and known trusted behaviors, and are used to provide a supplementary source for the normal behavior baseline in addition to frequency statistics.

[0045] Based on the above settings, several specific examples of pre-configured known normal behaviors are provided, which, together with the frequency partitioning mechanism, complete the construction of the normal behavior element set. Specifically, the frequency partitioning mechanism automatically selects high-frequency behaviors as the first normal behavior element through statistics, covering the statistically significant normal operating patterns of users or entities; further, it obtains the second normal behavior element by providing diverse pre-configured sources for known normal behaviors, covering "rare but normal" behaviors that frequency statistics cannot cover. These two types of normal behavior elements are aligned in the encoding space through the same cryptographic hash operation, together forming a complete normal behavior element set. This enables subsequent non-membership proofs based on the normal behavior accumulator to accurately distinguish between "truly abnormal" and "rare but normal" sparse behaviors, thereby helping to improve the recall rate of sparse behavior detection while controlling the false positive rate.

[0046] Among them, the aforementioned historical stable behavior refers to behavioral patterns that have been verified as normal over a long historical period, such as users' login behavior during fixed working hours over a long period of time, regular system maintenance operations, etc. These behaviors are derived from the accumulation and verification of long-term behavioral data and can reflect the stable operating habits of users or entities over a long time scale. These behaviors may appear to be low-frequency or even absent in a short time window, but they have important reference value for normal behavior in the long term.

[0047] The aforementioned whitelisted behaviors refer to behaviors that have been pre-confirmed through security audits. These behaviors typically originate from security policy configurations or business compliance requirements. Their characteristic is that they are explicitly identified as safe or compliant behaviors in business logic, requiring no anomaly detection and no reliance on historical data verification.

[0048] The aforementioned legitimate business activities refer to behaviors that occur within normal business processes, such as finance personnel performing specific settlement operations at the end of the month, or operations and maintenance personnel performing specific configuration changes in the change window. These behaviors originate from the understanding and modeling of business processes and are characterized by being associated with specific business functions or tasks. If a statistically low-frequency behavior is part of a legitimate business process, it should be included in the normal behavior baseline.

[0049] The aforementioned known trustworthy behaviors refer to behaviors that have been confirmed as non-threatening in past security operations. These behaviors typically originate from the accumulated experience of security operations personnel and the backtracking verification of known security incidents. Their characteristic is that they have been verified as harmless in actual security operations.

[0050] In some of these embodiments, the standardization process includes: unifying the format of behavior log data from different sources, aligning and calibrating time fields, and normalizing and disambiguating entity identifiers.

[0051] Based on the above settings, a specific example of standardization processing is provided. Format unification eliminates the heterogeneity of different log sources at the field semantic level, enabling behavioral logs from different security devices, terminal nodes, and business systems to be expressed in a unified data structure. Time alignment calibration eliminates the heterogeneity of different log sources at the time reference level, enabling cross-source behavioral events to be compared and sorted on a unified timeline. Entity identifier normalization and disambiguation eliminates the heterogeneity of different log sources at the entity identifier level, enabling cross-source behaviors of the same user or entity to be correctly merged. These three operations standardize multi-source heterogeneous logs from the semantic, temporal, and entity dimensions, respectively, allowing previously fragmented multi-source behavioral logs to be integrated in a unified data space. This provides standardized input data with consistent structure, clear semantics, accurate timing, and explicit entities for subsequent behavioral feature extraction and cryptographic hashing operations, eliminating the differences in field semantics, time reference, and entity identifiers among multi-source heterogeneous log data.

[0052] In some embodiments, the step of constructing a frequency-weighted cryptographic accumulator based on each behavioral element and its weight to obtain a normal behavioral accumulator includes: for each behavioral element in the set of normal behavioral elements, calculating the weighted value of the behavioral element and a preset private parameter, and exponentiating the weighted value with the weight of the behavioral element as the exponent to obtain the weighted exponent term corresponding to the behavioral element; multiplying the weighted exponent terms corresponding to all behavioral elements in the set of normal behavioral elements to obtain an exponent product; and exponentiating the exponent product as the exponent of the generator to obtain the accumulated value of the normal behavioral accumulator; wherein the generator is the generator in the algebraic group on which the frequency-weighted cryptographic accumulator is based.

[0053] Based on the above settings, a specific implementation scheme for obtaining the normal behavior accumulator is provided. For each behavior element in the normal behavior element set, its value and the weighted value of the preset private parameters are used as the base, and its occurrence frequency is used as the exponent to perform a power operation to obtain a weighted exponent term. All weighted exponent terms are multiplied together to obtain an exponent product. This exponent product is used as the exponent of the generator to perform a power operation to obtain the accumulated value of the normal behavior accumulator. This construction embeds the member identity information, occurrence frequency information, and preset private parameters of each behavior element in the entire normal behavior element set into the exponent structure of the accumulated value, realizing a constant-level compressed expression of the complete behavior element set into a single accumulated value. This compression is irreversible and tamper-proof, and the introduction of preset private parameters ensures security.

[0054] The aforementioned weighted exponent term refers to the algebraic expression obtained by exponentiation of the weight of the i-th behavior element in the set of normal behavior elements, with the weight of the behavior element and the preset private parameters as the base and the weight of the behavior element as the exponent.

[0055] The above exponential product refers to the product obtained by multiplying the weighted exponential terms corresponding to all behavioral elements in the set of normal behavioral elements.

[0056] The aforementioned generator is a fixed element, denoted as g, in the algebraic group upon which the cryptographic accumulator is based. Any element in this group can be represented as a power of g. In this embodiment of the invention, the aforementioned algebraic group is a prime-order cyclic group or an elliptic curve group, and the aforementioned generator is the generator of that group.

[0057] The above accumulated value: the group element obtained by exponentiation of the product of exponents as the generator is a single short value output by the frequency-weighted cryptographic accumulator after compressing the set of elements with normal behavior.

[0058] Within the mathematical framework of cryptographic accumulators, the security of accumulators relies on the one-way nature of exponential operations and the difficulty of solving the discrete logarithm problem. In standard cryptographic accumulators, each set element typically participates in the calculation of the accumulated value in the form of a first power.

[0059] This invention introduces a weight as an exponent into the standard cryptographic accumulator. This weight is the number of times a behavioral element appears within a preset time window and is a positive integer. For each behavioral element in the set of normal behavioral elements... The system first calculates the behavior element and the preset private parameters. weighted value This yields a new group element; then, the weights of the elements are determined by this row. As a power exponent, the weighted value is exponentially raised to obtain... The mathematical meaning of this exponentiation is: the more times a behavioral element appears in the set of normal behavioral elements, the higher its exponent in the accumulator construction, and the greater its contribution to the final accumulated value. If a behavioral element appears frequently within a preset time window, i.e., has a large weight, then its corresponding weighted exponent term... The weighted exponent, which is significantly larger than the behavioral elements with smaller weights, represents a power-law weighting, a method fundamentally different from simply expressing weights as linear multiples. It deeply embeds weight information within the accumulator's exponent structure, rather than appending it to the outside of the accumulator. Simultaneously, it presets private parameters. The introduction of this ensures that even if two elements with different behaviors have the same value after hashing (collision) or two elements with the same behaviors have the same weight, due to... The participation of [the relevant entity], and the corresponding base number. This will also obfuscate different or identical data, and combined with the anti-aliasing attack characteristics of hash functions, external attackers will be unable to determine the nature of the data. In cases where it is impossible to deduce specific behavioral elements or weight information from the accumulated value, the security of the accumulator is further enhanced.

[0060] Furthermore, by multiplying the weighted exponent terms corresponding to all behavioral elements in the set of normal behavioral elements together to obtain an exponential product, the weighted exponent terms of each behavioral element in the set of normal behavioral elements are integrated into a unified and indivisible exponential product through multiplication operations in an algebraic group, so that the frequency information of all behavioral elements is mathematically fused into a single expression.

[0061] Finally, the product of exponents is used as the exponents of the generators to perform exponentiation, resulting in the accumulated value of the normal behavior accumulator. Here, the generators are those in the algebraic group upon which the frequency-weighted cryptographic accumulator is based. Thus, by using the product of exponents as the exponents of the generators to perform exponentiation, the final accumulated value is generated, ensuring its uniqueness, irreversibility, and constant length within the algebraic group. Furthermore, it guarantees the legitimacy and verifiability of a single accumulated value within the algebraic group.

[0062] In some embodiments, the method further includes a distributed collaborative verification step: multiple security nodes maintain their own local behavior log data, and each security node constructs a corresponding local normal behavior accumulator based on its local behavior log data. The local normal behavior accumulator adopts the construction method of frequency-weighted cryptographic accumulator, and each security node's local normal behavior accumulator uses its own corresponding independent behavior domain parameters. The independent behavior domain parameters enable the same behavior element to have different accumulation expressions in the accumulators of different security nodes. When any security node determines the behavior element to be detected, the security node generates a local behavior proof of the behavior element to be detected based on its local normal behavior accumulator, and sends the local behavior proof, the node identifier of the security node, and the accumulator digest of its local normal behavior accumulator to the central verification node. The central verification node determines the corresponding security node according to the node identifier, verifies the behavior element to be detected based on the local normal behavior accumulator of the security node, and determines whether the behavior to be detected is abnormal based on the verification result.

[0063] Based on the above setup, a complete collaborative verification mechanism is provided for a multi-node distributed security analysis environment. Specifically, each security node constructs a frequency-weighted cryptographic accumulator locally using independent behavior domain parameters, achieving independent modeling of local normal behavior baselines and logical isolation of behavior domains between nodes, ensuring that the detection processes of each node do not interfere with each other. After each security node generates a behavior proof of the behavior element to be detected locally, it only sends the proof, node identifier, and accumulator digest to the central verification node, without uploading the original behavior log data, reducing the cross-node data transmission volume from TB to KB. The central verification node determines the corresponding security node based on the node identifier and completes the verification judgment based on the local normal behavior accumulator of that node. Collaborative verification of cross-node behavior is achieved without obtaining the original log data, reducing the cross-node log transmission pressure, ensuring the independence of the behavior domains of each security node, and improving the real-time performance of anomaly detection in the distributed environment.

[0064] Specifically, in large enterprise networks or cloud environments, behavior logs are naturally distributed across different security nodes. VPN gateways record network access behavior, endpoint detection and response nodes record endpoint operation behavior, database audit nodes record data access behavior, and cloud workload nodes record cloud platform operation behavior. The business scenarios and behavioral patterns faced by each node are fundamentally different. The normal behaviors that VPN gateways focus on (such as remote access during office hours) and the normal behaviors that database audit nodes focus on (such as data queries in business systems) have completely different behavioral characteristics, and there is no unified standard for "normal behavior" across nodes. If a single centralized accumulator is used to uniformly model the behavior of all nodes, two problems will arise: First, after the behavioral data from different business domains are mixed, the boundaries of normal behavior for each node will be blurred by the behavioral data of other nodes, leading to a decrease in the accuracy of anomaly detection. Second, all raw behavior logs need to be transmitted from each node to the central node. In a 10Gbps network environment, the daily log volume can reach TB levels, and cross-node transmission will consume a large amount of network bandwidth and produce significant transmission latency. This invention enables each security node to independently maintain local behavior logs and construct local normal behavior accumulators. Each local normal behavior accumulator uses different independent behavior domain parameters, so that the same behavior element has different accumulation expressions in the accumulators of different nodes. This achieves local autonomy in behavior detection and avoids mutual contamination of behavior data between different business domains through parameter isolation.

[0065] Meanwhile, in traditional centralized UEBA schemes, each node needs to transmit the complete raw behavior logs to the central node, which then performs frequency statistics, accumulator construction, and anomaly verification. In large network environments, the daily volume of behavior logs can reach terabytes. Transmitting raw log data across nodes consumes significant network bandwidth and storage resources, and transmission delays prevent anomaly detection from being completed in real time. In the above embodiments of the present invention, after the security node completes the proof generation of the behavior element to be detected locally, it only sends three pieces of information—the behavior proof, the node identifier, and the accumulator digest—to the central verification node, without uploading the behavior element itself or the raw behavior log data. This minimizes the amount of data transmitted across nodes while ensuring verification feasibility.

[0066] In this embodiment of the invention, the central verification node can complete the verification and judgment of abnormal behavior without obtaining the original behavior log data, realizing collaborative verification of cross-node behavior while ensuring the real-time nature and traceability of the verification. Specifically, after receiving three pieces of information from the security node—the local behavior proof, the node identifier, and the accumulator digest—the central verification node determines the security node to which the behavior element to be verified belongs based on the node identifier, thereby determining the verification context required to verify the behavior proof and the construction method of the local normal behavior accumulator corresponding to the security node. The central verification node completes the verification calculation locally based on the independent behavior domain parameters of the security node and the accumulator digest, without needing to obtain the original behavior log data of the security node. The verification calculation of the central verification node is mathematically equivalent to performing the verification locally on the security node, because the accumulator digest is a compressed value that correctly reflects the set of normal behavior elements of the security node, and the proof provided by the security node is generated based on the accumulator. After successful verification, the central verification node can directly output the anomaly judgment result. Based on the aforementioned distributed collaborative verification mechanism, the verification capability of the central verification node is no longer limited by whether the original log data has been transmitted. The verification operation can be executed immediately after receiving the proof, without any data synchronization delay. At the same time, since the proof, node identifier, and accumulator digest on which the verification result depends can all be recorded and archived, the central verification node can re-verify the correctness of any historical judgment result afterward, enhancing the traceability and auditability of the detection results.

[0067] In some of these embodiments, the aforementioned security nodes include at least one of a virtual private network gateway node, a terminal detection and response node, a database audit node, and a cloud workload node; the independent behavioral domain parameters corresponding to different security nodes are different from each other.

[0068] Based on the above settings, the security nodes in the distributed collaborative verification mechanism are specified as at least one of the following: virtual private network gateway node, terminal detection and response node, database audit node, and cloud workload node. The applicable scenarios of the scheme in typical multi-node security environments are clarified. Each node independently performs behavior modeling and anomaly detection according to the same frequency weighted cryptographic accumulator mechanism. At the same time, by limiting the independent behavior domain parameters corresponding to different security nodes to be different, the security risks that may be caused by parameter reuse are mathematically eliminated, the mathematical independence of the accumulator structure of each security node is realized, and the logical isolation of the behavior domains between nodes is guaranteed. In a multi-node distributed security environment, behavior domain isolation is achieved, user behavior pattern privacy is protected, and the failure of a single node does not affect the security of other nodes.

[0069] Among them, the aforementioned Virtual Private Network Gateway Node, or VPN Gateway Node, refers to the gateway device or service in the enterprise network responsible for handling secure access for remote users. It is used to record users' network access behavior, including authentication requests, connection establishment time, access IP address, disconnection and other log information.

[0070] The aforementioned Endpoint Detection and Response (EDR) nodes refer to security monitoring components deployed on terminal devices, used to record terminal operating system and application-level behaviors, including log information such as process startup, file access, network connection, and registry modification.

[0071] Database audit node: refers to a security audit component deployed at the database system level, used to record access and operation behaviors to the database, including log information such as SQL query statements, data read operations, data modification operations, and permission change operations.

[0072] Cloud workload nodes refer to security monitoring components deployed on workloads (including virtual machines, containers, serverless functions, etc.) in the cloud platform. They are used to record the operation and interaction behavior of workloads in the cloud-native environment, including log information such as instance creation, configuration changes, service calls, and resource access.

[0073] In some embodiments, the method further includes: when a new behavior element is obtained, using the weighted result of the new behavior element and a preset private parameter as an exponent to power the current accumulated value of the normal behavior accumulator to obtain an updated accumulated value; when a behavior element needs to be deleted from the set of normal behavior elements, using the modulo inverse of the weighted result of the deleted behavior element and the preset private parameter as an exponent to power the current accumulated value of the normal behavior accumulator to obtain an updated accumulated value; wherein the deleted behavior elements include behavior elements that are eliminated as the time window slides.

[0074] Based on the above settings, a complete dynamic update mechanism is provided for the frequency-weighted cryptographic accumulator. When a new behavioral element is added to the set of normal behavioral elements, the current accumulator value is exponentially raised using the weighted result of the new behavioral element and the preset private parameters as the exponent, and its contribution is included in the accumulator value. When a behavioral element needs to be deleted, including scenarios where a behavioral element is eliminated due to time window sliding, the current accumulator value is exponentially raised using the modular inverse of the weighted result of the deleted behavioral element and the preset private parameters as the exponent, and its contribution is removed from the accumulator value. Both addition and deletion operations require only one exponentiation operation, and their computational cost is independent of the size of the behavioral element set, realizing constant-time dynamic updates of the accumulator. This supports real-time processing of streaming logs and sliding window behavior management, eliminating the need for periodic accumulator reconstruction, significantly reducing the accumulator update cost, and also supporting real-time processing of streaming logs.

[0075] Sliding time windows are a crucial mechanism in behavioral analysis. Within a preset time window, the frequency of occurrence of each behavioral element depends on the window's boundaries. As time progresses and the window slides forward, some historical behaviors statistically exceed the window's range. These corresponding behavioral elements need to be removed from the set of normal behavioral elements to ensure the normal behavior accumulator only reflects behavioral patterns within the current time window. In traditional accumulator construction methods, window sliding means re-counting all behavioral elements within the new window and completely rebuilding the accumulator, resulting in high computational costs. In this embodiment, the elimination of behavioral elements caused by time window sliding is transformed into a deletion operation within the accumulator. For behavioral elements exceeding the window's range, their accumulated contribution is removed from the accumulated value through a first-order exponentiation operation (using the modulo inverse of the weighted result of the element and its private parameters as the exponent). This process does not involve re-counting or recalculating other behavioral elements and is unaffected by the window size.

[0076] Specifically, when a new behavior element is added to the set of normal behavior elements, the accumulator can be updated with a single exponentiation operation, without needing to reacquire all behavior elements and rebuild the accumulator, thus achieving constant-level incremental updates of the accumulator. When a behavior element needs to be deleted from the set of normal behavior elements, the accumulator can be updated with a single exponentiation operation, without needing to rebuild the accumulator, thus achieving constant-level deletion updates of the accumulator. At the same time, the elimination of historical behaviors caused by time window sliding is explicitly included in the scope of deletion updates, so that the dynamic update mechanism of the accumulator and the preset time window management mechanism work together to keep the update of the accumulator synchronized with the sliding of the time window. When the sliding of the time window causes a behavior element to be eliminated, the system automatically uses the modulo inverse of the weighted result of the eliminated behavior element and the preset private parameters as the exponent to exponentiation the current accumulator value, removing the contribution of the behavior element from the accumulator value. The updated accumulator value only contains the normal behavior elements in the current time window and their occurrence counts, which precisely correspond to the actual behavior patterns in the current window.

[0077] In some embodiments, the above-mentioned preset sparse threshold is determined by: setting a fixed value as the preset sparse threshold; or, dynamically determining the preset sparse threshold according to a pre-configured dynamic threshold rule based on the statistical distribution of the occurrence frequency of behavioral elements.

[0078] Based on the above settings, specific examples of determining preset sparse thresholds are provided, including two selectable sparse threshold determination schemes: fixed numerical threshold and dynamic threshold. The fixed numerical threshold method uses a pre-set fixed value as the threshold, applying a uniform frequency threshold to all behavioral elements, thus achieving sparse filtering with minimal computational overhead. The dynamic threshold method adaptively calculates the threshold according to the statistical distribution of the frequency of occurrence of behavioral elements and pre-configured dynamic threshold rules, allowing the sparse threshold value to adapt to differences in behavioral frequency distribution under different scenarios. These two methods are respectively suitable for scenarios with stable behavioral patterns and the need to maintain consistent judgment criteria, and scenarios with large differences in user behavioral patterns and the need for adaptive adjustment, ensuring effective sparse behavior filtering in different application scenarios.

[0079] According to an embodiment of the present invention, after frequency statistics are completed, each behavioral element corresponds to a count value of the number of occurrences. Setting a fixed value as a threshold means applying a uniform frequency threshold to all behavioral elements that does not change with the characteristics of the behavioral elements or time. This fixed value is usually preset based on security operation experience or offline analysis of historical behavior logs. For example, if the fixed value is set to 3, behavioral elements that occur 3 times or less are identified as sparse behavioral elements, and behavioral elements that occur more than 3 times are identified as normal behavioral elements. By setting a fixed value as a sparsity threshold, the system can classify all behavioral elements with a uniform, predetermined frequency boundary, and binary distinguish between behavioral elements that occur less than or equal to the fixed value and behavioral elements that occur more than the fixed value, thereby completing the screening of sparse behavioral elements with the lowest computational cost.

[0080] Another advantage of fixed numerical thresholds lies in their determinism. As long as the preset fixed value remains unchanged, frequency statistics and sparse filtering of the same behavior log data at different times and under different operating environments will produce exactly the same classification results. This determinism is of great significance for security analysis scenarios. When security operations personnel need to backtrack or reproduce historical detection results, fixed numerical thresholds ensure the reproducibility and auditability of the classification criteria.

[0081] In enterprise network environments, the behavioral patterns of different users, departments, and business systems vary significantly. For example, the daily behavior of R&D employees may involve frequent access to code repositories and system build calls, while the daily behavior of finance department employees may involve infrequent access to financial statements and approval operations. Within the same system, peak business hours on weekdays and off-peak business hours on holidays may also produce different distributions of behavioral frequency. If a uniform fixed threshold is used for all scenarios, the threshold that can effectively filter out sparse and abnormal behaviors in one scenario may misclassify a large number of normal behaviors as sparse behaviors or miss genuine sparse and abnormal behaviors in another scenario. In some embodiments, by introducing a dynamic threshold determination method based on statistical distribution, the sparse threshold is dynamically determined according to the statistical distribution of the frequency of occurrence of behavioral elements. This allows the value of the sparse threshold to adapt to the differences in behavioral frequency distributions among different users, departments, and business systems, and can also automatically adjust the frequency boundary within the same system as business patterns change, ensuring the consistency of the effectiveness of sparse behavior filtering across different scenarios.

[0082] The pre-configurability of the aforementioned dynamic threshold rules is reflected in the fact that system maintenance personnel only need to configure the dynamic threshold rules themselves, such as selecting the specific values ​​of adjustment parameters and specifying the calculation method of statistical distribution, without having to set specific threshold values ​​for different scenarios. Once the rules are configured, the specific value of the dynamic threshold is automatically calculated and determined by the system based on the frequency statistical distribution within the current window.

[0083] In some embodiments, the step of counting the number of occurrences of each behavioral element within a preset time window includes: determining the time interval between each behavioral element and the current time based on the time information of the behavioral log data; applying a time decay function to decay the number of occurrences to obtain the decayed number; wherein the time decay function decreases as the time interval increases, so that behavioral elements closer to the current time correspond to a larger decayed number, and behavioral elements farther from the current time correspond to a smaller decayed number; and using the decayed number as the occurrence count of the corresponding behavioral element.

[0084] Based on the above settings, a specific implementation plan is provided for counting the occurrences of each behavioral element within a preset time window. The time interval between each occurrence of a behavioral element and the current moment is determined based on the time information of the behavioral log data. A time decay function that decreases as the time interval increases is used to decay the occurrence count, so that behavioral elements closer to the current moment receive a larger decayed count, and behavioral elements farther from the current moment receive a smaller decayed count. The decayed count is then used as the occurrence count of the corresponding behavioral element in subsequent sparse threshold comparisons and accumulator weight allocation. This time decay mechanism ensures that all subsequent processing steps are based on the time-adjusted behavioral frequency, reducing the impact of historical behavior on current detection results, strengthening the detection capability of recent abnormal behavior, and enabling the behavioral baseline to reflect behavioral pattern evolution in a timely manner.

[0085] The aforementioned time interval refers to the time difference between the specific moment when the same behavioral element occurs each time and the current moment, which can be denoted as Δt and is used to measure the degree of novelty of the occurrence of the behavior.

[0086] Time decay function: a monotonically decreasing function f(Δt) with time interval Δt as the independent variable. The function value decreases as Δt increases and is used to weight historical behavior based on its timeliness.

[0087] Decay parameter: An adjustment parameter that controls the rate of time decay. The larger the decay parameter, the faster the decay rate and the stronger the suppression of the weight of historical behavior. The smaller the decay parameter, the slower the decay rate and the more the contribution of historical behavior is retained.

[0088] Decayed count: The value obtained by weighting the original count of all occurrences of the behavioral element within a preset time window with time decay. The decayed count is less than or equal to the original count and reflects the recent activity level of the behavioral element.

[0089] According to an embodiment of the present invention, by calculating the time interval between each behavioral element and the current time, and using a time decay function to weight and adjust the original occurrence count of the behavioral element, the statistical results can distinguish the timeliness of the behavior occurrence, providing the subsequent frequency weighted accumulator with the occurrence count corrected for timeliness. Through the monotonically decreasing property of the time decay function, the decayed count is inversely correlated with the distance between the behavior occurrence time and the current time, so that the occurrence count after decay processing can accurately reflect the recent activity level of the behavioral element. The decayed count is output as the occurrence count of the behavioral element, so that subsequent steps (including sparse threshold comparison, weight allocation, accumulator construction, etc.) are all based on the occurrence count corrected for timeliness, ensuring that all subsequent processing steps are performed on the basis of considering the timeliness of the behavior.

[0090] In the sparse threshold comparison step, the decayed frequency is used instead of the original frequency for comparison. This means that the classification of a behavioral element (sparse or normal) depends not only on its historical cumulative frequency but also on the temporal distribution of its frequency. A behavioral element that has appeared frequently in the past but has recently stopped may have its decayed frequency reduced to a low level, thus being classified as a sparse behavioral element and included in the detection range. Conversely, a behavioral element that has recently become active may have its decayed frequency increased to a high level even if its historical cumulative frequency is not high, thus being included in the normal behavioral element set. This time-based dynamic classification method allows sparse screening to capture the evolution of behavioral patterns, rather than relying solely on static historical cumulative statistics.

[0091] In the weighting process, the decayed frequency is used as the weight, so that recent high-frequency behaviors have a greater mathematical contribution to the normal behavior accumulator, while long-term behaviors have a smaller mathematical contribution. When a new behavior element is added to the set of normal behavior elements, its weight reflects the recent activity level of the behavior element within the current time window, rather than its total frequency of occurrence throughout the entire window.

[0092] In some of these embodiments, the frequency-weighted cryptographic accumulator is constructed using a bilinear mapping-based cryptographic accumulator construction method, where the bilinear mapping employs bilinear pairing operations corresponding to the BLS12-381 curve or the BN254 curve.

[0093] Based on the above settings, an alternative construction method for frequency-weighted cryptographic accumulators is provided, which switches the mathematical foundation of the accumulator from an RSA-like construction to a construction method based on bilinear mappings, and changes the generation of the accumulated value from modular exponentiation in the group G to the target group G. T The pairing operation in the bilinear mapping accumulator is effective because the accumulated value and proof output by the bilinear mapping accumulator are both elements in the target group, and their element length is significantly smaller than the corresponding group element length in the RSA class construction, effectively reducing the proof size of both membership and non-membership proofs. At the same time, the BLS12-381 and BN254 curves have efficient pairing operation implementations, which can meet the real-time requirements of UEBA behavior anomaly detection in real-world scenarios. Therefore, it is possible to reduce the proof size and improve verification efficiency while maintaining the frequency weighting mechanism and set compression expression capability.

[0094] Bilinear pairing is a method for mapping two elliptic curve groups G1 and G2 to a target group G. T The mapping function e: G1×G2→G T It has bilinear properties.

[0095] BLS12-381 curve: A pairwise friendly elliptic curve with an embedding degree of 12, a base field size of 381 bits, and a security level of approximately 128 bits.

[0096] BN254 curve: A pairwise friendly elliptic curve with a base domain size of 254 bits, providing a security level of approximately 128 bits.

[0097] Bilinear pairing operation: The specific bilinear mapping calculation performed on pairing-friendly elliptic curves is usually implemented using efficient algorithms such as Miller's algorithm and optimal pairing algorithm.

[0098] In some embodiments, the step of constructing a frequency-weighted cryptographic accumulator based on each behavioral element and its weight to obtain a normal behavioral accumulator further includes: compressing the occurrence count of each behavioral element in the set of normal behavioral elements using a preset mapping function, mapping the original occurrence count to a preset numerical range to obtain a compressed weight value, and using the compressed weight value to replace the original occurrence count in the construction of the frequency-weighted cryptographic accumulator.

[0099] Based on the above settings, a weight compression mapping mechanism is introduced during the construction of the frequency-weighted cryptographic accumulator. The original occurrence counts of each behavioral element in the set of normal behavioral elements are compressed using a preset mapping function, mapping the original occurrence counts spanning several orders of magnitude to a preset, smaller numerical range, resulting in compressed weight values. These compressed weight values ​​replace the original occurrence counts in the accumulator construction. This compression process effectively reduces the weight difference between high-frequency and low-frequency behavioral elements while preserving the relative magnitudes of the original occurrence counts. It avoids numerical overflow or precision loss during accumulator construction due to the dominance of a very small number of extremely high-frequency behavioral elements, ensuring that the frequency-weighted cryptographic accumulator maintains acceptable computational efficiency even when faced with real-world behavioral log data with extremely uneven weight distribution.

[0100] Specifically, according to embodiments of the present invention, by mathematically compressing the original occurrence counts of each behavioral element, the numerical range of the original occurrence counts is reduced to a preset interval, thereby compressing the weight difference between high-frequency and low-frequency behavioral elements from a magnitude difference to a numerical difference. This avoids numerical overflow or precision loss during the accumulator construction process due to the dominance of a very small number of ultra-high-frequency behavioral elements. After the compressed weight values ​​replace the original occurrence counts in the accumulator construction, the mathematical structure of the accumulator still retains the ability to distinguish the activity level of each behavioral element, while avoiding the problem of decreased computational efficiency caused by excessively large original weight differences, making the frequency-weighted accumulator feasible in practical systems.

[0101] In some embodiments, the normal behavior accumulator includes at least one of a user-level normal behavior accumulator, a department-level normal behavior accumulator, and an enterprise-level normal behavior accumulator; the step of generating a membership certificate or non-member certificate of the behavior element to be detected based on the normal behavior accumulator includes: generating a membership certificate or non-member certificate of the behavior element to be detected based on at least one of the user-level normal behavior accumulator, the department-level normal behavior accumulator, and the enterprise-level normal behavior accumulator.

[0102] Based on the above settings, three granularities of normal behavior accumulators were constructed: user-level, department-level, and enterprise-level. The user-level accumulator reflects the personalized behavior patterns of individual users, the department-level accumulator reflects the common behavior patterns of the entire department, and the enterprise-level accumulator reflects the general behavior patterns across the entire system. During detection, the system can generate membership or non-membership proofs for the behavior element to be detected based on at least one of the above accumulators. Appropriate judgment criteria are selected according to different detection granularities and scenarios, enabling non-membership verification of sparse behavior elements within different behavioral ranges, thus improving the flexibility and accuracy of anomaly detection at different granularities.

[0103] Different ranges of behavioral data possess different statistical characteristics and meanings of normal patterns. A user-level normal behavior accumulator is built upon the behavioral log data of a single user within a preset time window. It captures the personalized behavioral habits of individual users, including their unique operating patterns, access preferences, and time patterns. Since each user's behavioral pattern may differ from other users, the user-level accumulator reflects the unique behavioral characteristics of that user. A department-level normal behavior accumulator is built upon the aggregation of behavioral log data from multiple users within the same department. Users in the same department typically have similar job responsibilities and business operation processes, therefore their behavioral patterns share common characteristics at the department level. The department-level accumulator reflects the overall normal behavioral pattern of the department, including department-specific business operation types and activity patterns during work hours. Compared to the user-level accumulator, the department-level accumulator eliminates statistical biases caused by individual, accidental behavior, providing a standardized behavioral baseline at the department level. An enterprise-level normal behavior accumulator is built upon the aggregation of behavioral log data from all users across the enterprise, reflecting the normal behavioral patterns of the entire enterprise. The enterprise-level accumulator provides a global normal behavior baseline and is suitable for detection scenarios where there is no clear departmental affiliation or cross-departmental behavior. According to embodiments of the present invention, by dividing the normal behavior accumulator into three different granularities—user-level, department-level, and enterprise-level—the system can construct normal behavior baselines from multiple behavior ranges, providing differentiated judgment criteria for subsequent anomaly detection. Since the accumulators at all three levels employ the same frequency-weighted cryptographic accumulator construction method, their output accumulated values ​​are mathematically consistent, and each can compress the set of normal behavior elements within its respective range into a single accumulated value. The user-level accumulator corresponds to the set of behavior elements for a single user, the department-level accumulator corresponds to the set of behavior elements for all users in the same department, and the enterprise-level accumulator corresponds to the set of behavior elements for all users in the enterprise.

[0104] In some embodiments, for any behavior element to be detected, the system first generates a membership certificate or a non-membership certificate based on a user-level normal behavior accumulator. If the verification result indicates that the behavior element belongs to the user's user-level normal behavior set, the behavior can be directly determined to be normal without further coarse-grained detection. This utilizes the high-precision capture capability of the user-level accumulator for individual behavior patterns, enabling the identification of user-specific normal behavior patterns. If the verification result based on the user-level accumulator indicates that the behavior element does not belong to the user's normal behavior set, the system further generates a certificate based on a department-level normal behavior accumulator and performs verification. If the verification result indicates that the behavior element belongs to the department-level normal behavior set, the behavior is determined to be normal because it is a routine behavior pattern within the department. This can handle scenarios where a user's individual behavior deviates from their own habits but belongs to the department's routine behavior, such as a user temporarily performing an operation that other members in the department frequently perform but that the user themselves do not often perform. If the verification results based on both the user-level and department-level accumulators indicate that the detected behavior element does not belong to the corresponding normal behavior set, the system further generates proof based on the enterprise-level normal behavior accumulator and performs verification. If the verification result indicates that the detected behavior element belongs to the enterprise-level normal behavior set, the behavior is determined to be normal because it belongs to the normal behavior pattern globally. If the verification result indicates that the detected behavior element does not belong to the enterprise-level normal behavior set, the behavior is determined to be abnormal. This layered detection strategy allows anomaly detection to be performed independently at multiple levels. The detection result at one level does not affect the independent operation of other levels. The system can choose the most suitable level for detection or use accumulators from multiple levels simultaneously for comprehensive judgment, thus achieving a differentiated anomaly judgment strategy.

[0105] In some embodiments, the above method further includes the step of constructing a sparse behavior accumulator: taking the occurrence frequency of each behavior element in the sparse behavior set as the weight of the behavior element, using the same frequency-weighted cryptographic accumulator construction method as the normal behavior accumulator, constructing a sparse behavior accumulator based on each behavior element and its weight in the sparse behavior set, the sparse behavior accumulator compresses the sparse behavior set into a single accumulated value, which is used for compressed storage and fast querying of the sparse behavior set.

[0106] Based on the above settings, and building upon the existing sparse behavior set, a scheme is further provided for constructing an independent frequency-weighted cryptographic accumulator for the sparse behavior set. Using the frequency of occurrence of each behavior element in the sparse behavior set as a weight, and employing the same frequency-weighted cryptographic accumulator construction method as the normal behavior accumulator, a sparse behavior accumulator is constructed based on each behavior element and its weight. This compresses the sparse behavior set into a single accumulated value, reducing the storage space of the sparse behavior set from linearly dependent on the number of elements to a constant level. This achieves efficient compressed storage of the sparse behavior set and supports fast existence queries based on membership proofs.

[0107] The aforementioned sparse behavior accumulator is a frequency-weighted cryptographic accumulator built upon the elements of each behavior in the sparse behavior set and their frequency of occurrence. It is used to compress the sparse behavior set into a single accumulated value, supporting compressed storage and fast lookup of the set. The compressed storage refers to utilizing the set compression capability of the cryptographic accumulator to store a sparse behavior set containing multiple behavior elements as a single accumulated value; the storage space is independent of the number of elements in the set. The fast lookup refers to using the membership proof mechanism of the cryptographic accumulator to confirm the existence of a target behavior element within the sparse behavior set without traversing all elements in the set.

[0108] Specifically, the sparse behavior set has been constructed through frequency statistics and sparse threshold filtering. It contains low-frequency behavior elements whose occurrence frequency is less than or equal to a preset sparse threshold. These low-frequency behavior elements are a candidate set of potential anomalous behaviors, characterized by uncertain numbers and variations over time and business scenarios. In the anomaly detection process, elements in the sparse behavior set are treated as behavior elements to be detected. Each element is verified one by one using a normal behavior accumulator for either membership or non-membership proof. For behavior elements confirmed as anomalous through verification, the sparse behavior set itself also requires compressed storage and retrieval. Security operations personnel may need to retrospectively review sparse behavior elements judged as anomalous within a certain time period, or confirm whether a specific behavior element was ever filtered into the sparse behavior set. In this embodiment of the invention, for each behavior element in the constructed sparse behavior set, the frequency of its occurrence within a preset time window is used as a weight. A sparse behavior accumulator is constructed using the exact same mathematical construction method as the normal behavior accumulator, enabling the sparse behavior set to also acquire the set compression expression capability of a cryptographic accumulator.

[0109] Meanwhile, the core function of the normal behavior accumulator is to serve as a benchmark for anomaly detection, that is, to verify whether the behavior element to be detected belongs to the set of normal behaviors through non-membership proofs. Although the sparse behavior accumulator is completely identical to the normal behavior accumulator in its mathematical construction, their technical functions are fundamentally different. The sparse behavior accumulator is used for storing and querying the sparse behavior set itself, rather than for anomaly detection. This difference in functional positioning stems from the different sets of behavior elements on which the two accumulators are based: the normal behavior accumulator is based on the set of normal behavior elements and is used to define the boundary of "normal," serving as the benchmark for anomaly detection; the sparse behavior accumulator is based on the set of sparse behavior elements and is used to record and manage the set of "candidate anomalous behaviors," serving as the data foundation for subsequent security analysis and investigation.

[0110] The sparse behavior accumulator provided in this embodiment of the invention provides a compressed representation of sparse behavior sets in the following aspects: When the normal behavior accumulator determines a sparse behavior element as an abnormal behavior, the behavior element is still retained in the sparse behavior set. Security operators may subsequently need to query whether the sparse behavior set contains a specific behavior element for threat tracing or event correlation analysis. If the original data of the sparse behavior set is stored directly, it is necessary to store the complete behavior feature information (including behavior type, context information, timestamp, etc.) for each sparse behavior element, and the storage overhead increases linearly with the number of sparse behavior elements. However, after using the sparse behavior accumulator, the entire sparse behavior set is compressed into a single accumulated value, and the storage space required to store this accumulated value is independent of the number of behavior elements in the set. Queries on the sparse behavior set can be completed through the membership proof mechanism of the accumulator. To query whether a specific behavior element belongs to the sparse behavior set, the system generates a membership proof for the behavior element based on the sparse behavior accumulator. If the verification passes, it indicates that the behavior element exists in the sparse behavior set; if the verification fails, it indicates that it does not exist. The query process does not require traversing all behavioral elements in the sparse behavioral set, nor does it require accessing the original behavioral log data. Existence confirmation can be completed using only the accumulated value and proof.

[0111] The above-described behavior anomaly detection method based on a cryptographic accumulator provided in this invention involves acquiring user or entity behavior log data, performing standardization processing on the behavior log data, extracting behavior features from the obtained standardized behavior data, performing cryptographic hash operations on the behavior features to generate behavior elements, counting the occurrence frequency of each behavior element within a preset time window, identifying behavior elements with occurrence frequencies less than or equal to a preset sparse threshold as sparse behavior elements, and constructing a sparse behavior set; identifying behavior elements with occurrence frequencies greater than the sparse threshold as first normal behavior elements, and performing cryptographic hash operations on pre-configured known normal behaviors to generate second normal behavior elements, constructing a normal behavior element set based on the first and second normal behavior elements; and using the normal behavior elements... The frequency of occurrence of each behavioral element in the set is used as the weight of the corresponding behavioral element, and the frequency of occurrence of the second normal behavioral element is a pre-configured number. A frequency-weighted cryptographic accumulator is constructed based on each behavioral element and its weight to obtain the normal behavioral accumulator. The normal behavioral accumulator compresses the set of normal behavioral elements into a single accumulated value. Sparse behavioral elements in the sparse behavioral set are used as the behavioral elements to be detected. Membership proofs or non-membership proofs of the behavioral elements to be detected are generated based on the normal behavioral accumulator. The verification results of the membership proofs or non-membership proofs determine whether the behavior to be detected corresponding to the behavioral element is an abnormal behavior, and an abnormal detection result is output. Specifically, when the verification result indicates that the behavioral element to be detected does not belong to the set of normal behavioral elements, the behavior to be detected is determined to be an abnormal behavior. This approach achieves compressed storage of the behavioral element set, targeted detection of sparse behavioral elements, and verifiable confirmation of the detection results, thereby improving detection accuracy, enhancing the credibility of detection results, reducing storage overhead, and expanding the applicable scenarios of the solution.

[0112] To address the aforementioned issues, this invention also provides a specific implementation of a behavior anomaly detection method based on a cryptographic accumulator. This method, by performing set-based modeling of sparse behaviors in user and entity actions and utilizing a cryptographic accumulator to achieve compressed representation of the behavior set, member verification, and non-member verification, achieves efficient and verifiable anomaly detection for massive security log scenarios. It is particularly suitable for: Security Operations Centers (SOCs), Security Information and Event Management Systems (SIEMs), User and Entity Behavior Analysis Systems (UEBAs), zero-trust security architectures, cloud environment behavior analysis, and multi-node distributed security analysis systems. This specific implementation mainly includes: Step 1: Log collection and standardization processing.

[0113] First, the system collects behavior logs in real time from multiple security devices, terminal nodes, and business systems. These behavior logs include, but are not limited to: user login logs, VPN access logs, DNS access logs, web access logs, API call logs, file access logs, database access logs, network connection logs, host process logs, and terminal behavior logs. It can be further expanded to include eBPF kernel probes, Sysmon terminal logs, Kafka log streams, agent-initiated collection, SIEM interface synchronization, and cloud security API interfaces. Because different log sources have different formats, the system further performs log standardization. Let the i-th log entry be represented as: ,in, Identifiers representing users or entities Representing the system's time scale, The system further performs the following on the logs: deduplication, field completion, time alignment, filtering of non-compliant fields, and behavior normalization, thereby ensuring the consistency of subsequent behavior set construction.

[0114] Step 2: Encoding behavioral features and mapping behavioral elements.

[0115] To facilitate subsequent cryptographic operations, behavioral features are further uniformly encoded. Let behavioral features be... for:

[0116] in, Represented as IP address Represented as domain name, Indicated as region, Represented as process name, This represents API call behavior and can be generated based on actual circumstances or requirements.

[0117] Further utilize cryptographic hash functions: Mapping behavioral characteristics to behavioral elements Represented as:

[0118] In one specific implementation: , || represents the string concatenation operation.

[0119] Furthermore, the behavioral elements can be further expanded to include user roles, device fingerprints, MAC addresses, browser fingerprints, protocol types, traffic characteristics, etc., as extended behavioral features to achieve high-dimensional behavioral expression.

[0120] Step 3: Behavior frequency statistics and time window construction.

[0121] Since attacks are typically infrequent and time-sensitive, the system further performs frequency statistics and time window divisions on the attacks.

[0122] Let user behavior set for:

[0123] Define the behavior frequency function for:

[0124] Where: Count() represents a statistical function.

[0125] The system further constructs a set of user behaviors based on time windows. , where t represents the time window.

[0126] Furthermore, time window types are added to the implementation, including: 1-hour window, 24-hour window, 7-day window, user-defined time length (Duration) sliding window, etc., which can be determined according to business needs.

[0127] The system further employs a time decay function:

[0128] in, This represents the weighted number of occurrences of behavior element x at time t after time decay, i.e., the number of occurrences after decay. Indicates the attenuation parameter; Indicates the interval between the action and the current time.

[0129] The above settings effectively reduce the impact of historical behavior on current detection and enhance the ability to detect recent abnormal behavior.

[0130] Step 4: Sparse behavior set filtering mechanism.

[0131] Since anomalous behaviors typically exhibit long-tail characteristics, the system further filters low-frequency behaviors, defining a sparse behavior set. for:

[0132] in, This indicates the preset sparsity threshold.

[0133] In one implementation method It can be set to a fixed value, such as 3, to indicate a behavior that occurs no more than 3 times; furthermore, a dynamic threshold can also be used. :

[0134] in, Indicates the mean frequency of behavior, Indicates the standard deviation of behavior frequency. This represents the adjustment parameter, typically a floating-point number between 0 and 1. Using this dynamic threshold form of a preset sparse threshold allows for adaptive sparse behavior filtering across different users, departments, and business systems. Furthermore, it enables targeted filtering of: abnormal region access, low-frequency domains, rare process chains, rare API call combinations, and abnormal lateral movement behaviors.

[0135] Step 5: Constructing the cryptographic accumulator.

[0136] The system constructs a cryptographic accumulator for a sparse set of behaviors to achieve a compressed representation of the behavior set; let the sparse set of behaviors be... for:

[0137] Wherein, the sparse set of behaviors of user or entity u It consists of n elements, each of which is a tuple. Unlike traditional cryptographic accumulators, this one uses occurrence count weights for different states, as shown in the above formula. This refers to the frequency weight, which reflects the number of repetitions of each state. To reduce discrepancies, the original frequencies are generally not used for calculation. Instead, a selected mapping function is used to compress them into a smaller interval, such as using a logarithmic function and then rounding up. The formal representation is... .

[0138] Constructing the accumulator: , represents: the set of sparse behaviors for user or entity u. Apply the accumulator function Acc to generate the accumulated value Au corresponding to this set.

[0139] In a specific implementation, the system uses a dynamic weighted cryptographic accumulator to obtain a single accumulated value. :

[0140] in, For generators; This is a private parameter to avoid the risk of tampering due to simple guessing attacks. Furthermore, in subsequent distributed steps, different parameters can be used for different nodes. parameter; This is the value mapped to the behavior element.

[0141] Using the aforementioned dynamically weighted cryptographic accumulator, the system can compress a complete set of actions into a single accumulated value. This achieves: compressed representation of behavior sets, rapid verification of behavior sets, and rapid querying of behavior sets. Furthermore, this specific implementation may also employ a bilinear mapping accumulator: ,in, This represents a bilinear mapping, thereby further reducing the proof size; bilinear algorithms such as BLS12-381 or BN254 can be used to obtain more outstanding performance than cryptographic accumulators based on RSA algorithms, which can meet the application needs in practical scenarios.

[0142] Step 6: Update the dynamic accumulator.

[0143] As the UEBA log continues to grow, the system further supports dynamic updates. When new actions are added... Upon entering the system, there's no need to re-traverse the entire set of behaviors. The system directly updates the accumulated value corresponding to the accumulator.

[0144] This enables streaming log updates, real-time behavior modeling, and reduced reconstruction costs. Furthermore, it also supports behavior deletion, time window eviction, and historical behavior invalidation to achieve sliding window behavior management.

[0145] Step 7: Establishing a baseline for normal behavior.

[0146] The system further constructs a set of normal behaviors. The normal behavior set includes: historically stable behavior, whitelisted behavior, legitimate business behavior, and known trustworthy behavior.

[0147] The system further generates a normal behavior accumulator:

[0148] Furthermore, in specific implementations, it can also be constructed separately according to business systems, etc. , , This allows for multi-level UEBA behavior analysis, corresponding to user-level, department-level, and enterprise-level behavior baselines. In some specific implementations, the normal behavior set also includes: behavior elements whose occurrence frequency is greater than a sparsity threshold, selected from behavior elements determined by real-time acquired behavior logs, which are then identified as normal behavior elements.

[0149] Step 8: Generation of membership proofs and non-member proofs.

[0150] When the system detects a new behavior y to be analyzed, it first encodes the behavior: The system then uses a normal behavior accumulator. Generate member or non-member proofs, where the proof is represented as .

[0151] Membership proof is used to prove Non-membership proofs are used to prove

[0152] Accordingly, in this specific implementation, a cryptographic accumulator method is actually used to transform the state processing in traditional UEBA from a general anomaly scoring problem into a set membership problem proof. This compresses the processing of extremely sparse states into a very small space, thereby saving a lot of memory, improving system availability, and reducing persistent runtime resource consumption.

[0153] Step Nine: Verification of Abnormal Behavior and Risk Output.

[0154] Further execute the verification function: ,when =1 indicates The system determines that the user entity's behavior is normal; while when =0, then means This means the system further determines that the behavior is abnormal.

[0155] Abnormal behavior may include login from abnormal regions, access from abnormal IPs, abnormal domain name resolution, abnormal process execution, abnormal lateral movement, and abnormal API calls, which will lead the system to generate risk alerts, attack chain records, threat events, security audit reports, etc.

[0156] Step 10: Distributed collaborative verification.

[0157] In large enterprise networks, cloud environments, or multi-node security systems, behavior logs are typically scattered across different security nodes or business areas, such as VPN gateways, EDR, database servers, and cloud workload nodes. Traditional UEBA systems usually require uploading the raw logs from each node to a unified analysis platform before behavior modeling and anomaly detection. This can lead to problems such as high network transmission pressure, high centralized storage costs, complex cross-node behavior synchronization, and low efficiency of real-time multi-node analysis. Therefore, this specific implementation further proposes a distributed collaborative verification mechanism. In this implementation, each security node maintains its own local behavior set:

[0158] in, Indicates the first The set of behaviors corresponding to each node.

[0159] Each node further constructs a local behavior accumulator based on its local behavior set:

[0160] in, This represents the independent behavior domain parameters of the corresponding node. Therefore, even if the same behavior appears in different nodes, the corresponding accumulator structures are still different, thus avoiding behavior pollution between different business domains.

[0161] Furthermore, in specific implementations, independent behavior accumulators can be maintained for VPN nodes, database nodes, and terminal nodes respectively. This allows for the description of network access behavior, data access behavior, and terminal execution behavior, among others. The system further maintains a global verification strategy in the central verification node.

[0162] When a node detects behavior to be verified At that time, only the proof of behavior, accumulator digest, and node identifier need to be sent to the central verification node, without uploading the complete original log; The central verification node will further execute: This completes behavior verification; therefore, it can effectively reduce the pressure of transmitting raw logs across nodes, the cost of distributed log synchronization, and the load on central storage.

[0163] The above embodiments and specific implementation methods are not intended to limit the scope of protection of this invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this invention, and these modifications and improvements all fall within the scope of protection of this invention.

[0164] Based on the above-described behavior anomaly detection method based on cryptographic accumulators provided in the embodiments of the present invention, the embodiments of the present invention also provide a behavior anomaly detection device based on cryptographic accumulators. Figure 2 As shown, the behavior anomaly detection device 200 based on a cryptographic accumulator includes: The behavior element generation module 201 is used to obtain user or entity behavior log data, perform standardization processing on the behavior log data, extract behavior features from the obtained standardized behavior data, perform cryptographic hash operation on the behavior features, and generate behavior elements. The behavior set construction module 202 is used to count the number of times each behavior element appears within a preset time window, determine the behavior elements whose number of occurrences is less than or equal to a preset sparse threshold as sparse behavior elements, and construct a sparse behavior set; determine the behavior elements whose number of occurrences is greater than the sparse threshold as first normal behavior elements, and perform cryptographic hash operation on the pre-configured known normal behaviors to generate second normal behavior elements, and construct a normal behavior element set based on the first normal behavior elements and the second normal behavior elements; The accumulator construction module 203 is used to use the occurrence frequency of each behavior element in the normal behavior element set as the weight of the corresponding behavior element, and the occurrence frequency of the second normal behavior element is a pre-configured number; a frequency-weighted cryptographic accumulator is constructed based on each behavior element and its weight to obtain the normal behavior accumulator; wherein, the normal behavior accumulator compresses the normal behavior element set into a single accumulated value. The anomaly detection module 204 is used to take sparse behavior elements in the sparse behavior set as behavior elements to be detected, generate membership proof or non-member proof of the behavior elements to be detected based on the normal behavior accumulator; determine whether the behavior to be detected corresponding to the behavior element to be detected is an anomalous behavior based on the verification result of the membership proof or non-member proof, and output the anomaly detection result; wherein, when the verification result indicates that the behavior element to be detected does not belong to the normal behavior element set, the behavior to be detected is determined to be an anomalous behavior.

[0165] Based on the above setup, the behavior element generation module standardizes behavior log data, extracts behavior features, and performs cryptographic hash mapping to generate unified behavior elements, providing a data foundation for frequency statistics and set operations. Then, the behavior set construction module performs frequency statistics and sparse thresholding on the behavior elements, precisely converging the detection focus from massive behavior logs to low-frequency behaviors. The integrity of the normal behavior element set is ensured through hash fusion of pre-configured known normal behaviors. Next, the accumulator construction module embeds the frequency of each behavior element in the normal behavior element set into the exponential structure of the cryptographic accumulator in a weighted manner, compressing the normal behavior element set into a single accumulated value. This preserves both the membership and frequency information of the elements within constant-level storage space. Finally, the anomaly detection module uses the accumulator's membership and non-membership proof mechanisms to verify sparse behavior elements. This achieves compressed storage of the behavior element set, targeted detection of sparse behavior elements, and verifiable confirmation of detection results, thereby improving detection accuracy, enhancing the credibility of detection results, reducing storage overhead, and expanding the applicability of the solution.

[0166] Meanwhile, the aforementioned behavior anomaly detection device 200 based on cryptographic accumulator is configured to execute any of the aforementioned behavior anomaly detection methods based on cryptographic accumulator. Therefore, the relevant modules in the aforementioned behavior anomaly detection device based on cryptographic accumulator are also used to execute the corresponding operations in any of the aforementioned behavior anomaly detection methods based on cryptographic accumulator. Accordingly, it also possesses all the beneficial effects of any of the aforementioned behavior anomaly detection methods based on cryptographic accumulator, which will not be elaborated further in this application.

[0167] It should be noted that the specific modules in the above-mentioned behavior anomaly detection device based on cryptographic accumulators are defined mainly based on the corresponding operations performed, and are not intended to limit the specific modules.

[0168] This invention also provides a non-transitory machine-readable medium storing computer instructions, wherein the computer instructions, when executed by a computer's processor, are used to cause the computer to perform the method of an embodiment of this invention.

[0169] This invention also provides a computer program product, including a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform the methods of embodiments of this invention. The computer program product should be understood as a software product that primarily implements the methods of this invention through a computer program.

[0170] This invention also provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores a computer program executable by the at least one processor, which, when executed by the at least one processor, causes the electronic device to perform the method of this invention.

[0171] refer to Figure 3 The present invention will now be described in the form of a structural block diagram of an electronic device that can serve as an embodiment of the present invention, which is an example of a hardware device that can be applied to various aspects of the present invention. The electronic device is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0172] like Figure 3 As shown, the electronic device includes a computing unit 301, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 302 or a computer program loaded from a storage unit 308 into a random access memory (RAM) 303. The RAM 303 may also store various programs and data required for the operation of the electronic device. The computing unit 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0173] Multiple components in the electronic device are connected to I / O interface 305, including: input unit 306, output unit 307, storage unit 308, and communication unit 309. Input unit 306 can be any type of device capable of inputting information into the electronic device. Input unit 306 can receive input digital or character information and generate key signal inputs related to user settings and / or function control of the electronic device. Output unit 307 can be any type of device capable of presenting information and may include, but is not limited to, a display, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 308 may include, but is not limited to, disks and optical discs. Communication unit 309 allows the electronic device to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, and / or wireless communication transceivers, such as Bluetooth devices, WiFi devices, WiMax devices, cellular communication devices, and / or the like.

[0174] The computing unit 301 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 301 include, but are not limited to, CPUs, graphics processing units (GPUs), various special-purpose artificial intelligence (AI) computing units, various computing units running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. The computing unit 301 performs the various methods and processes described above. For example, in some embodiments, the method embodiments of the present invention can be implemented as a computer program tangibly contained in a machine-readable medium, such as storage unit 308. In some embodiments, part or all of the computer program can be loaded and / or installed on an electronic device via ROM 302 and / or communication unit 309. In some embodiments, the computing unit 301 can be configured to perform the methods described above by any other suitable means (e.g., by means of firmware).

[0175] Computer programs for implementing the methods of embodiments of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0176] In the context of embodiments of the present invention, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable signal medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, or infrared systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, compact optical disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0177] It should be noted that the term "comprising" and its variations used in the embodiments of the present invention are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". The modifications of "one" and "multiple" mentioned in the embodiments of the present invention are illustrative and not restrictive. Those skilled in the art should understand that, unless explicitly indicated otherwise in the context, they should be understood as "one or more".

[0178] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in the embodiments of the present invention are all information and data that have been permitted by the user or have been fully agreed upon by all parties. Furthermore, the collection, use and processing of the relevant data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to agree or refuse.

[0179] The steps described in the method embodiments provided by this invention can be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of protection of this invention is not limited in this respect.

[0180] The term "embodiment" in this specification refers to a specific feature, structure, or characteristic described in connection with an embodiment that may be included in at least one embodiment of the invention. The appearance of this phrase in various places in the specification does not necessarily imply the same embodiment, nor does it imply independence or alternativeity from other embodiments. The various embodiments in this specification are described in a related manner, with reference to each other for similar or identical parts. In particular, for apparatus, device, and system embodiments, since they are substantially similar to method embodiments, the description is relatively simple, and relevant details are referred to in the description of the method embodiments.

[0181] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of protection. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the appended claims.

Claims

1. A method for detecting behavioral anomalies based on cryptographic accumulators, characterized in that, include: Obtain user or entity behavior log data, perform standardization processing on the behavior log data, extract behavior features from the obtained standardized behavior data, perform cryptographic hash operation on the behavior features, and generate behavior elements; The occurrence frequency of each behavioral element within a preset time window is counted, and behavioral elements whose occurrence frequency is less than or equal to a preset sparse threshold are identified as sparse behavioral elements, and a sparse behavioral set is constructed. The behavior elements whose occurrence frequency is greater than the sparse threshold are identified as first normal behavior elements, and the cryptographic hash operation is performed on the pre-configured known normal behaviors to generate second normal behavior elements. A set of normal behavior elements is constructed based on the first normal behavior elements and the second normal behavior elements. The frequency of occurrence of each behavior element in the set of normal behavior elements is used as the weight of the corresponding behavior element, and the frequency of occurrence of the second normal behavior element is a pre-configured number; a frequency-weighted cryptographic accumulator is constructed based on each behavior element and its weight to obtain a normal behavior accumulator; wherein, the normal behavior accumulator compresses the set of normal behavior elements into a single accumulated value. The sparse behavior elements in the sparse behavior set are taken as the behavior elements to be detected. Membership proof or non-membership proof of the behavior elements to be detected is generated based on the normal behavior accumulator. The detection result of the membership proof or the non-membership proof is used to determine whether the behavior to be detected corresponding to the behavior element to be detected is an abnormal behavior, and the abnormal detection result is output. When the verification result indicates that the behavior element to be detected does not belong to the normal behavior element set, the behavior to be detected is determined to be an abnormal behavior.

2. The method according to claim 1, characterized in that, The step of constructing a frequency-weighted cryptographic accumulator based on each behavioral element and its weight to obtain a normal behavioral accumulator includes: For each behavior element in the set of normal behavior elements, calculate the weighted value of the behavior element and the preset private parameter, and use the weight of the behavior element as the exponent to exponentiate the weighted value to obtain the weighted exponent term corresponding to the behavior element. Multiply the weighted exponent terms corresponding to all behavioral elements in the set of normal behavioral elements to obtain an exponential product; use the exponential product as the exponent of the generator to perform an exponentiation operation to obtain the accumulated value of the normal behavioral accumulator; wherein, the generator is the generator in the algebraic group on which the frequency-weighted cryptographic accumulator is based.

3. The method according to claim 1, characterized in that, It also includes a distributed collaborative verification step: Multiple security nodes maintain their own local behavior log data. Each security node constructs a corresponding local normal behavior accumulator based on its local behavior log data. The local normal behavior accumulator adopts the construction method of the frequency-weighted cryptographic accumulator. Moreover, the local normal behavior accumulator of each security node uses its own corresponding independent behavior domain parameters. The independent behavior domain parameters enable the same behavior element to have different accumulation expressions in the accumulators of different security nodes. When any security node determines a behavior element to be detected, the security node generates a local behavior proof of the behavior element to be detected based on its local normal behavior accumulator, and sends the local behavior proof, the node identifier of the security node and the accumulator digest of its local normal behavior accumulator to the central verification node. The central verification node determines the corresponding security node based on the node identifier, verifies the behavior element to be detected based on the local normal behavior accumulator of the security node, and determines whether the behavior to be detected is abnormal based on the verification result.

4. The method according to claim 1, characterized in that, The method further includes: When a new behavior element is obtained, the weighted result of the new behavior element and the preset private parameter is used as the exponent to perform an exponentiation operation on the current accumulated value of the normal behavior accumulator to obtain the updated accumulated value. When it is necessary to delete a behavior element from the set of normal behavior elements, the modulo inverse of the weighted result of the deleted behavior element and the preset private parameter is used as the exponent to perform an exponentiation operation on the current accumulated value of the normal behavior accumulator to obtain the updated accumulated value; wherein, the deleted behavior elements include behavior elements that are eliminated as the time window slides.

5. The method according to claim 1, characterized in that, The methods for determining the preset sparsity threshold include: Set a fixed value as the preset sparsity threshold; Alternatively, the preset sparsity threshold can be dynamically determined according to the statistical distribution of the occurrence frequency of the behavioral elements and a pre-configured dynamic threshold rule.

6. The method according to claim 1, characterized in that, The step of counting the number of occurrences of each behavioral element within a preset time window includes: Based on the time information of the behavior log data, the time interval between each behavior element and the current time is determined. The occurrence count is then reduced using a time decay function to obtain the decayed count. The time decay function decreases as the time interval increases, so that behavior elements closer to the current time correspond to a larger decayed count, and behavior elements farther from the current time correspond to a smaller decayed count. The decayed count is taken as the occurrence count of the corresponding behavioral element.

7. The method according to claim 1, characterized in that, The frequency-weighted cryptographic accumulator is constructed using a bilinear mapping method, where the bilinear mapping employs bilinear pairing operations corresponding to the BLS12-381 curve or the BN254 curve.

8. The method according to claim 1, characterized in that, The step of constructing a frequency-weighted cryptographic accumulator based on each behavioral element and its weight to obtain a normal behavioral accumulator further includes: The occurrence count of each behavioral element in the set of normal behavioral elements is compressed using a preset mapping function, mapping the original occurrence count to a preset numerical range to obtain a compressed weight value. The compressed weight value is then used to replace the original occurrence count in the construction of the frequency-weighted cryptographic accumulator.

9. A behavior anomaly detection device based on a cryptographic accumulator, characterized in that, include: The behavior element generation module is used to acquire user or entity behavior log data, perform standardization processing on the behavior log data, extract behavior features from the obtained standardized behavior data, perform cryptographic hash operation on the behavior features, and generate behavior elements. The behavior set construction module is used to count the number of times each behavior element appears within a preset time window, determine the behavior elements whose number of occurrences is less than or equal to a preset sparse threshold as sparse behavior elements, and construct a sparse behavior set. The behavior elements whose occurrence frequency is greater than the sparse threshold are identified as first normal behavior elements, and the cryptographic hash operation is performed on the pre-configured known normal behaviors to generate second normal behavior elements. A set of normal behavior elements is constructed based on the first normal behavior elements and the second normal behavior elements. An accumulator construction module is used to use the occurrence frequency of each behavior element in the set of normal behavior elements as the weight of the corresponding behavior element, and the occurrence frequency of the second normal behavior element is a pre-configured number; a frequency-weighted cryptographic accumulator is constructed based on each behavior element and its weight to obtain a normal behavior accumulator; wherein, the normal behavior accumulator compresses the set of normal behavior elements into a single accumulated value. An anomaly detection module is used to take sparse behavior elements in the sparse behavior set as behavior elements to be detected, generate membership proof or non-member proof of the behavior elements to be detected based on the normal behavior accumulator, determine whether the behavior to be detected corresponding to the behavior element to be detected is an anomalous behavior based on the verification result of the membership proof or the non-member proof, and output the anomaly detection result; wherein, when the verification result indicates that the behavior element to be detected does not belong to the normal behavior element set, the behavior to be detected is determined to be an anomalous behavior.

10. A non-transitory machine-readable medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to any one of claims 1 to 8.

Images