A database security system and its management method
By constructing a cross-domain collaborative analysis model, and combining transaction network graphs and hardware performance counter data, the problem of not being able to identify malicious loads and slow attacks in existing technologies has been solved, achieving efficient protection for database security.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- WEIFANG ZHONGSUO INFORMATION TECH CO LTD
- Filing Date
- 2026-03-23
- Publication Date
- 2026-07-03
AI Technical Summary
Existing database security technologies have limitations in monitoring dimensions, failing to effectively identify malicious loads and slow attacks that exploit legitimate operating privileges, and lacking analysis of the inherent causal and temporal relationships between the business logic layer and the physical execution layer.
By generating transaction network graphs and hardware performance counter data, topology risk indicators and computing resource characteristics are calculated, and time alignment and feature normalization are performed. Cross-domain anomaly collaboration scores are calculated, dual-domain anomaly resonance events are generated, and blocking instructions are output to business logic protection and underlying process isolation systems.
It achieves accurate capture of high-confidence threat events, filters out benign fluctuation noise from a single dimension, identifies deep-hidden attacks with coordinated actions, and improves the accuracy and robustness of database security protection.
Smart Images

Figure CN122333455A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of electronic digital data processing technology, specifically to a database security system and its management method. Background Technology
[0002] As global digital transformation deepens, database systems are no longer merely carriers of information; they have become the nerve center that carries core enterprise data assets and drives critical business logic. Correspondingly, security threats to database systems are exhibiting unprecedented complexity and stealth. Attack methods are evolving from simple vulnerability exploitation to multi-layered, cross-domain composite attacks, posing a severe challenge to the accuracy, foresight, and robustness of existing database security protection technologies.
[0003] Existing database security technologies have limitations in their monitoring dimensions when addressing the above challenges, specifically in the following two aspects:
[0004] "Execution blind spots" in business logic layer monitoring: For example, the financial management method disclosed in patent application CN107315963A focuses its security mechanisms on business logic layers such as user authentication, data encryption, and module operations. While such solutions effectively ensure the compliance and confidentiality of data during storage and circulation, they lack the ability to perceive the actual execution behavior of the underlying processes carrying out business operations, even while understanding business intent. Therefore, when attackers use their acquired legitimate operating privileges to execute malicious payloads unrelated to business logic within the processes, these monitoring solutions focused solely on business compliance struggle to effectively identify them, creating a protection blind spot.
[0005] The "lack of context" in physical execution layer monitoring: Another set of technical solutions focuses on monitoring underlying computing resources, such as identifying malicious processes by detecting anomalies in CPU utilization, memory usage, or network traffic. While such solutions can detect resource abuse at the process execution level, they face challenges in distinguishing between normal business peaks (such as high loads caused by batch report generation at the end of the month) and malicious resource consumption because they cannot analyze the business context behind these resource consumptions. They are also prone to generating a large number of false positives due to overly sensitive threshold settings. At the same time, for "slow" attacks that slowly penetrate the business layer through a large number of small and scattered legitimate operations, these solutions that only focus on resource mutations are ineffective because they lack a perspective on the macro-business model.
[0006] The root of these limitations lies in the fact that existing technologies typically treat the business logic layer and the physical execution layer as two separate security domains for independent monitoring, lacking an effective technical means to correlate and quantify the inherent causal and temporal relationships between abnormal behaviors in these two dimensions. The essence of many advanced attacks lies precisely in the high degree of coordination between the "intent" presented at the business level and the "means" manifested at the physical execution level.
[0007] The information disclosed in the background section above is only intended to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention
[0008] The purpose of this invention is to provide a database security system and its management method to solve the problems mentioned in the background art.
[0009] To achieve the above objectives, the present invention provides the following technical solution:
[0010] A database security system, specifically comprising:
[0011] The first module is used to generate a transaction network graph representing the relationship between funds flow between accounts based on the financial transaction logs of the database, and to calculate topological risk indicators including at least the account centrality variability rate, the Gini coefficient drift of account fund distribution, and the transaction loop complexity index.
[0012] The second module is used to generate computing resource features, including at least the instruction set execution frequency vector, processor cache pollution rate, and memory bus bandwidth saturation, based on the hardware performance counter data of the server where the database is located.
[0013] The third module is used to perform time alignment and feature normalization processing on the topology risk indicators and computing resource characteristics based on transaction ID and timestamp within a preset time window.
[0014] The fourth module is used to calculate a cross-domain anomaly collaboration score based on the aligned and normalized topology risk index and the computing resource characteristics, wherein the cross-domain anomaly collaboration score is used to characterize the degree of correlation between the topology risk index and the computing resource characteristics in terms of time and pattern.
[0015] The fifth module is used to generate a dual-domain abnormal resonance event when the cross-domain abnormal collaboration score exceeds a preset collaboration response threshold, and to simultaneously output blocking instructions to the business logic protection subsystem and the underlying process isolation subsystem.
[0016] A database security management method, the method being used to execute the database security system, comprising:
[0017] Step S1: Based on the financial transaction logs in the database, generate a transaction network graph representing the relationship between fund flows between accounts, and calculate topological risk indicators including at least the account centrality variability rate, the Gini coefficient drift of account fund distribution, and the transaction loop complexity index.
[0018] Step S2: Based on the hardware performance counter data of the server where the database is located, generate computing resource features including at least the instruction set execution frequency vector, processor cache pollution rate, and memory bus bandwidth saturation.
[0019] Step S3: Within a preset time window, perform time alignment and feature normalization processing on the topology risk indicators and computing resource characteristics based on transaction ID and timestamp;
[0020] Step S4: Based on the aligned and normalized topology risk index and the computing resource characteristics, calculate the cross-domain anomaly collaboration score, wherein the cross-domain anomaly collaboration score is used to characterize the degree of correlation between the topology risk index and the computing resource characteristics in terms of time and pattern;
[0021] Step S5: When the cross-domain abnormal collaboration score exceeds the preset collaboration response threshold, a dual-domain abnormal resonance event is generated, and a blocking command is simultaneously output to the business logic protection subsystem and the underlying process isolation subsystem.
[0022] Compared with existing technologies, the beneficial effects of this invention are as follows: By constructing a collaborative analysis model spanning both business logic and physical execution dimensions, the core idea of this model is to no longer treat abnormal events in both dimensions as isolated signals. Instead, it deeply aligns risk indicators originating from business topology with features originating from underlying computing resources in terms of time and pattern, and performs correlation calculations to extract a novel composite risk indicator capable of quantitatively characterizing the degree of "dual-domain abnormal resonance." The system only classifies a high-confidence threat event when the macro-level pattern evolution at the business level and the micro-level consumption pattern of underlying computing resources show a high degree of correlation in both time series and abnormal morphology. This paradigm shift from "independent monitoring" to "collaborative analysis" enables the system to effectively filter out benign fluctuation noise in a single dimension and accurately capture deeply hidden attacks that appear legitimate in any single dimension but are actually collaborative in action. Attached Figure Description
[0023] Figure 1 This is a schematic diagram of the execution logic of the entire system of the present invention;
[0024] Figure 2 This is a schematic diagram of the execution logic of the first module of the present invention;
[0025] Figure 3This is a schematic diagram of the execution logic of the fourth and fifth modules of the present invention. Detailed Implementation
[0026] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.
[0027] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.
[0028] Example 1:
[0029] Please see Figures 1 to 3 The present invention provides a technical solution: for Figure 1 It should be noted that: "Dual-domain data extraction" represents the first and second modules, "cross-domain alignment and normalization" represents the third module, "cooperative anomaly scoring" represents the fourth module, and "linked blocking decision" represents the fifth module;
[0030] A database security system and its management method, specifically including:
[0031] The first module is used to generate a transaction network graph representing the relationship between funds flow between accounts based on the financial transaction logs of the database, and to calculate topological risk indicators including at least the account centrality variability rate, the Gini coefficient drift of account fund distribution, and the transaction loop complexity index.
[0032] The second module is used to generate computing resource characteristics, including at least the instruction set execution frequency vector, processor cache pollution rate, and memory bus bandwidth saturation, based on the hardware performance counter data of the server where the database is located.
[0033] The third module is used to perform time alignment and feature normalization processing on topology risk indicators and computing resource characteristics based on transaction ID and timestamp within a preset time window.
[0034] The fourth module is used to calculate the cross-domain anomaly collaboration score based on the topology risk index and computing resource characteristics after alignment and feature normalization. The cross-domain anomaly collaboration score is used to characterize the degree of correlation between the topology risk index and computing resource characteristics in terms of time and pattern.
[0035] The fifth module is used to generate a dual-domain abnormal resonance event when the cross-domain abnormal collaboration score exceeds the preset collaboration response threshold, and to simultaneously output blocking instructions to the business logic protection subsystem and the underlying process isolation subsystem.
[0036] 1.1) Further explanation: The first module is specifically used for: the steps of constructing the transaction network graph specifically include: using account ID as the node of the graph, using the transaction direction as the directed edge of the graph, and using the transaction amount as the weight of the directed edge;
[0037] The steps for calculating the account centrality variation rate include: using Page's ranking algorithm to calculate the node centrality score of each account node, and calculating its relative variation rate based on the "node centrality score" of two consecutive time windows;
[0038] The steps for calculating the Gini coefficient drift of account fund distribution include: calculating the net fund stock of each account node, calculating the network fund distribution Gini coefficient based on the net fund stock, and calculating the absolute difference of the network fund distribution Gini coefficient between two consecutive time windows.
[0039] The steps for calculating the transaction loop complexity index include: using a depth-first search algorithm to detect transaction loops, and calculating the "transaction loop complexity index" based on the length and average weight of the loop;
[0040] 1.2) Further explanation: Before outputting the account centrality variability, it is determined whether any account node has an account centrality variability exceeding a preset threshold. If so, the maximum "account centrality variability" is taken as the representative value; otherwise, the average value is taken. After calculating each indicator, normalization is performed to limit the output value range of each indicator to the preset interval [0, 1].
[0041] The key parameters involved in this embodiment are defined as follows: Transaction network diagram, denoted as... It is a directed graph consisting of a set of account nodes V and a set of transaction edges E within a sliding time window t. Each account ID corresponds to one node. Each transaction from the payer's account to the payee's account corresponds to a directed edge from the payer's node to the payee's node. The transaction amount is recorded as follows: , is the weight associated with each directed edge e, and its value is equal to the monetary amount of the transaction;
[0042] Define node centrality score Used to quantify account nodes within a sliding time window t. The entire transaction network diagram The importance or influence of a financial account within a financial network. This parameter is calculated using the "link analysis algorithm" in graph theory, specifically the Page ranking algorithm. In this embodiment, it is innovatively applied to assess the centrality of a financial account within the financial network, specifically characterized as follows:
[0043] Representing any account node, for any account node Its node centrality score within the sliding time window t The importance of a node is determined by an iterative calculation formula, based on the importance and number of other nodes pointing to it. Specifically, for account nodes... Node centrality score Equal to a preset damping coefficient Multiply by all nodes pointing to the account account node Node centrality score The sum of its "out-of-range" quotients, plus a factor consisting of (1 minus the damping coefficient) The fundamental component is the quotient of the number of accounts and the total number of nodes in the network. This calculation process is iterated repeatedly until the scores of all account nodes converge to a stable value. Damping coefficient Let be a constant between 0 and 1, whose value is calibrated through offline experiments. In this embodiment, it is set to an empirical value of 0.85 to simulate the probability of random flow of funds in the network. In a network containing three accounts A1, B1, and C1, if A1 transfers funds to B1, B1 transfers funds to C1, and C1 transfers funds to A1, a loop is formed. Initially, all account nodes have a score of 1 / 3. After one iteration, the node centrality score of A1 will be contributed by the node centrality score of C1, the node centrality score of B1 will be contributed by the node centrality score of A1, and the node centrality score of C1 will be contributed by the node centrality score of B1, plus the basic component, until convergence. In this embodiment, "out-degree" represents all points pointing to the account node. The number of starting edges;
[0044] Define account centrality variability Used to measure account nodes The importance of an account node is determined by the degree of change within two consecutive sliding time windows. This parameter is calculated a second time based on the aforementioned node centrality score, and is a type of time series rate of change analysis. Account centrality variability rate in the current sliding time window t Equal to the node centrality score of the current sliding time window t The node centrality score compared to the previous sliding time window t-1 The absolute value of the difference, divided by the node centrality score of the previous sliding time window. To ensure the stability of the output value range, the calculation result is processed through a saturated linear unit function, limiting the output value to the interval [0, 1], i.e., taking the value 1 when the calculated value exceeds 1. If the centrality score of account A1 is 0.2 in the sliding time window t-1 and rises to 0.4 in the sliding time window t, then its account centrality variation rate is... The calculated value is (0.4-0.2) / 0.2=1.0. If the score changes from 0.2 to 0.1, the calculated value of the variation rate is |0.1-0.2| / 0.2=0.5.
[0045] Define the Gini coefficient for network funding distribution. This parameter measures the degree of equilibrium in the distribution of funds across the entire transaction network within a sliding time window t. It directly borrows the calculation method from the Gini coefficient, a measure of income distribution fairness in economics. First, it calculates the distribution for each account node. The net cash stock within the sliding time window t is equal to the sum of the weights of all edges pointing to that node (total inflow) minus the sum of the weights of all edges originating from that node (total outflow). Then, the net cash stocks of all nodes are sorted from low to high, and a Lorenz curve is plotted, with the horizontal axis representing the cumulative percentage of accounts and the vertical axis representing the cumulative percentage of net cash stock. (Network cash distribution Gini coefficient) The value of is equal to twice the area enclosed by the absolute average and the Lorenz curve. Its range is between [0, 1], where 0 represents perfect equality and 1 represents extreme inequality. In this embodiment, in a network, if all accounts have exactly equal net capital, the Lorenz curve coincides with the absolute average, the area is 0, and the network capital distribution Gini coefficient is 0. If all funds eventually converge to one account, and the other accounts have 0, the Lorenz curve approaches the horizontal axis and the right vertical axis, the area is close to 0.5, and the network capital distribution Gini coefficient is close to 1.
[0046] Define the Gini coefficient drift. This parameter measures the magnitude of change in the overall network capital distribution over two consecutive sliding time windows. Specifically, it is obtained through time-series analysis of the Gini coefficient of the network capital distribution; the Gini coefficient drift in the current sliding time window t. The Gini coefficient of network funding distribution equal to the current sliding time window t Gini coefficient of network funding distribution compared to the previous sliding time window t-1 The absolute value of the difference; since the range of the Gini coefficient of network capital distribution is within [0, 1], the absolute value of its difference also falls within the interval [0, 1]. In this embodiment, if the Gini coefficient of network capital distribution changes from 0.3 at t-1 to 0.5 at t, then the Gini coefficient drift is |0.5-0.3|=0.2.
[0047] Define the transaction loop complexity index This is used to quantify the extent of inefficient funding cycles or complex wash trades within a sliding time window t. The calculation logic is as follows: a depth-first search (DFS) algorithm is used to traverse the transaction network graph. The algorithm identifies all unique simple cycles. For each detected simple cycle, its cycle length (the number of edges constituting the cycle) and average weight (the average transaction amount of all edges constituting the cycle) are calculated. Then, the length of each cycle is multiplied by its average weight to obtain the weighted complexity of that cycle. Finally, the weighted complexities of all cycles are summed to obtain a total value. To normalize this total value, it is divided by a historical maximum complexity benchmark calibrated through offline experiments, and the final output transaction cycle complexity exponent is then processed using a saturated linear unit function. The maximum historical complexity benchmark is determined by analyzing the distribution of cyclic complexity in historical normal transaction data and taking the 99th percentile value to ensure sensitivity to extreme anomalies.
[0048] This embodiment detects two loops within a single window. Loop 1 has a length of 3, an average weight of 100, and a weighted complexity of 300. Loop 2 has a length of 4, an average weight of 50, and a weighted complexity of 200. The total is 500. If the historical baseline value is 1000, then the transaction loop complexity index... The value is 500 / 1000 = 0.5.
[0049] 1.3) The specific execution steps of the first module are as follows:
[0050] 1.31) Input all financial transaction logs generated by the database within a preset sliding time window t. Each log entry must contain at least: payer account ID, payee account ID, transaction amount, and transaction timestamp; in this embodiment, the sliding time window t is set to the past 24 hours; 1.32) Dynamic graph construction: The system reads all financial transaction logs within the sliding time window t. Using account ID as account nodes, transaction relationships as directed edges, and transaction amounts as edge weights, the system constructs or updates the transaction network graph for the current sliding time window. 1.33) Parallel calculation of indicators: based on the constructed trading network graph The system initiates the following three independent computational subprocesses in parallel: 1.331) Centrality calculation: Execute Page Ranking Algorithm to calculate the transaction network graph. Each account node Node centrality score Subsequently, the node centrality score is compared with the previous sliding time window t-1. Compare and calculate each account node Account centrality variability 1.332) Gini coefficient calculation: Calculate the transaction network diagram. The net cash balance of each account node in the network is calculated, and the Gini coefficient of the network cash distribution is calculated based on this. Subsequently, the Gini coefficient of the network funding distribution, stored in the previous sliding time window t-1, is compared with the data. By comparison, the Gini coefficient drift was calculated. 1.333) Cyclic complexity calculation: Execute the depth-first search algorithm to detect the transaction network graph. All transaction loops are included, and the transaction loop complexity index is calculated using the aforementioned method. .
[0051] 1.4) Metric Aggregation and Output: For the account centrality variability rate, the system performs a logical judgment: if there are one or more account nodes in the network with an account centrality variability rate... If the mutation rate exceeds a preset single-node mutation threshold, the maximum value of the "account centrality mutation rate" among all account nodes is taken as the final output for that dimension. Otherwise, the average mutation rate of all account nodes is taken. This step aims to capture the risk of local drastic changes. In this embodiment, the preset threshold is represented as the single-node mutation threshold, with a value of 0.8; the system uses the representative value of the determined account centrality mutation rate and the calculated Gini coefficient drift. and transaction loop complexity index They are combined into a three-dimensional vector.
[0052] 1.5) The final output of the process is a three-dimensional topology risk index vector. ,in This is the representative value of the account centrality variability rate determined after the logical judgment in step 1.4). This three-dimensional topological risk index vector as a whole characterizes the macro-structural risk status of the database financial network within the sliding time window t.
[0053] Three input parameters , , The final output three-dimensional topological risk index vector These are direct structural relationships. All three parameters are positively correlated with risk; that is, the higher the value, the higher the risk in the corresponding dimension. Together, they constitute a three-dimensional risk space, and the network state of any sliding time window can be mapped to a point in this space. By analyzing the position of this point in the space and its trajectory over time, the topological risk of the network can be comprehensively assessed.
[0054] Further explanation: When the three-dimensional topological risk index vector When all component values approach 0, this example is... This indicates that the database financial network is in a highly stable, healthy, and historically consistent operating state.
[0055] When the topology risk indicator vector When any one or more component values approach 1, this example is or This indicates a drastic and abnormal structural anomaly in the database's financial network across a specific dimension, suggesting the occurrence of one or more potential malicious activities with slow-penetration characteristics. The specific technical implications are:
[0056] : This indicates the probability that an account will be activated and quickly become a transit hub for funds; where " "Representations converge;"
[0057] This indicates a probability that funds may rapidly accumulate in a small number of accounts.
[0058] This indicates a high probability of large-scale wash trading to inflate trading volume or complex fund circulation to circumvent regulations. In this state, the system determines that there is a high risk at the business logic level, requiring further in-depth correlation analysis by subsequent modules.
[0059] Node centrality score Other things being equal, the node centrality score of a single or a few accounts A sharp increase or decrease in a short period of time will lead to a corresponding account centrality variability rate. Approaching 1, thus making the final vector components Monotonically increasing. This is a positive correlation. This design aligns with the real-world logic of financial risk. A long-dormant account suddenly becoming a core node in the network (i.e., a dramatic increase in node centrality score), or a core corporate account suddenly losing all connections (a dramatic decrease in node centrality score), are both abnormal phenomena, often associated with account theft, corporate bankruptcy, or the preparatory stage for fraud. This embodiment accurately captures this risk signal of "sudden change in influence."
[0060] Gini coefficient of network funding distribution The larger the absolute difference within the continuous sliding time window, the greater the Gini coefficient drift of the final vector component. The larger the value, the greater the correlation. It is also a positive correlation. In a healthy economic system, the wealth distribution structure should remain relatively stable or evolve slowly on a macro level. If the Gini coefficient of network capital distribution... Dramatic changes in a short period signify a large-scale, structural redistribution of funds. This could be triggered by the pooling of funds or the rapid withdrawal of assets. The algorithm quantifies risk by measuring the degree of disruption to this "structural stability." Table 1 below shows the three-dimensional topological risk indicator vectors calculated by the first module of this invention under different financial scenarios.
[0061] Table 1: Three Typical Financial Scenarios
[0062]
[0063] In the above data, the calculation of the account centrality mutation rate reflects the threshold processing logic in the embodiment. Taking scenario two as an example, since the maximum account centrality mutation rate (0.92) exceeds the preset single node mutation threshold of 0.8, the final output is... The maximum value of 0.92 is used instead of the average value of 0.12. In Scenario 1, since the maximum account centrality mutation rate (0.08) does not exceed the single node mutation threshold of 0.8, the average value of 0.05 is used.
[0064] Comparing Scenario 1 (normal) and Scenario 2 (initial preparation for malicious transactions): Scenario 1 data shows that under normal business operations, all network indicators are in a low stable state, and all components of the output three-dimensional topology risk indicator vector are close to 0. However, in Scenario 2, although the total number of transactions is not large, the activation of a few "puppet accounts" causes a sharp increase in the account centrality mutation rate, represented by their influence, resulting in a maximum account centrality mutation rate as high as 0.92. This triggers the threshold logic, leading to the final output... The value is 0.92. This strongly demonstrates that the present invention can accurately capture the risks caused by mutations in local critical nodes. Compared with traditional methods that only look at global transaction volume, it has the ability to provide early warning of attacks, reflecting the significant innovation.
[0065] Comparing Scenario 3 (malicious fundraising) and Scenario 4 (fraudulent transactions): These two scenarios demonstrate the invention's ability to characterize risk from multiple dimensions. In Scenario 3, a large amount of funds converges on a small number of accounts, leading to a sharp widening of the wealth gap online, reflected in the Gini coefficient drift. The index reached as high as 0.85, while other indicators were relatively normal. In scenario four, funds were frequently traded between a few accounts, creating numerous ineffective loops, which is reflected in the transaction loop complexity index. The accuracy rate is as high as 0.91. This proves that the present invention is not a general risk score, but rather can accurately identify different types of financial crime patterns by analyzing which component in the vector is abnormal. This "pattern profiling" capability is not available in existing technologies, providing a crucial basis for subsequent precision strikes.
[0066] Comparing Scenario 1 (normal) and Scenario 5 (normal settlement): Scenario 5 has a significantly higher number of transactions than normal, but because its transaction pattern conforms to historical patterns (such as the normal aggregation of funds from multiple branch accounts to the headquarters account), the component values of its risk vector remain at a low level, similar to Scenario 1. This fully demonstrates that the present invention can effectively distinguish between "high business load" and "high-risk behavior," avoiding false alarms caused by traffic surges in traditional monitoring methods, and significantly improving the accuracy of security monitoring.
[0067] Further explanation: 2.1) The steps for generating computing resource characteristics based on server hardware performance counter data; and the steps for time alignment and feature normalization of computing resource characteristics and topology risk indicators are detailed below:
[0068] The steps to generate computing resource characteristics are as follows: obtain the execution count statistics of different instruction sets in real time by accessing the processor performance monitoring unit of the server; and combine the number of hits and misses of the processor's last-level cache and the number of bytes read and written by the memory controller to calculate the instruction set execution frequency vector, processor cache pollution rate and memory bus bandwidth saturation respectively.
[0069] The time alignment steps are performed based on a pre-established mapping that associates database transaction IDs with operating system process IDs. This mapping is established by deploying probes at the database connection management layer to capture synchronization events between transaction IDs and process IDs.
[0070] The feature normalization steps involve processing the topology risk indicators and computing resource characteristics using the Z-score standardization method. The historical baseline mean and standard deviation used in the Z-score standardization method are determined through offline statistical analysis of data collected from the system running under preset normal business loads.
[0071] 2.2) The physical meaning, acquisition method, and determination method of each parameter symbol in this embodiment are explained as follows: Define the instruction set execution frequency vector. It represents the relative distribution of various central processing unit (CPU) instructions executed by a specific process within a short sampling period, and is a microscopic representation of the process's computational pattern. This instruction set execution frequency vector The data is obtained by accessing the Processor Performance Monitoring Unit (PMU) built into the server's CPU. The calculation originates from performance event counting analysis in computer architecture. Its value is obtained by statistically normalizing the raw instruction execution counts provided by the PMU; the calculation logic is as follows: a set of instruction categories to be monitored is preset, including: general arithmetic instructions, vectorized instructions, and the Advanced Encryption Standard Instruction Set (AES-NI) for cryptographic instructions. Within a preset sampling time interval provided by the PMU... Within the defined period, the execution frequency vector of various preset instructions associated with the target process is read using performance analysis tools provided by the operating system (this example uses the perf tool under Linux). The value of each element is equal to the number of times the corresponding category of instructions was executed, divided by the total number of times all monitored category instructions were executed within that period. This division operation converts the original count value into a dimensionless proportional value representing relative frequency. This example is in... Within 100 milliseconds, the database process was monitored to execute 1 million general arithmetic instructions, 2 million vectorized instructions, and 7 million cryptographic instructions. Therefore, the total number of monitored instructions is 10 million. The final generated instruction set execution frequency vector... [0.1, 0.2, 0.7].
[0072] Define processor cache pollution rate This parameter quantifies the efficiency of a process's utilization of the CPU's Last Level Cache (LLC). Its value ranges from [0,1]. A higher value indicates a lower cache hit rate and a data access pattern that tends to "pollute" the cache, thus reducing the overall system's memory access performance. The calculation of this parameter is based on statistical analysis of cache access events provided by the Processor Cache Management Unit (PMU), and its core is the inversion of cache hit rate. Processor Cache Pollution Rate It equals "1" minus a ratio. The numerator of the ratio is the sampling time interval in the PMU. Within this ratio, the total number of last-level cache accesses recorded by the PMU is subtracted from the number of last-level cache misses; the denominator of the ratio is the total number of last-level cache accesses within the same time interval. This calculation transforms the original hit / miss event count into a standardized efficiency metric.
[0073] In one Within the processor cache, the PMU recorded a total of 10 million accesses to the last-level cache and 2 million cache misses. Therefore, the total number of last-level cache hits was 8 million. This represents the processor cache pollution rate. The value is "1" minus (eight million divided by ten million), that is, "1" minus 0.8, which gives 0.2.
[0074] Define memory bus bandwidth saturation This parameter measures how close a process is to its theoretical upper limit when actually using memory bus bandwidth; its value ranges from [0,1]. The calculation is based on a comparison of memory controller performance counter readings with server hardware specifications. Memory bus bandwidth saturation. This equals a calculated ratio. The numerator of the calculated ratio is the time interval during PMU sampling. Within this range, the sum of the total number of bytes read from the memory controller's performance counters and the total number of bytes written. The denominator of the ratio calculation is the server's theoretical maximum memory bandwidth. Multiply by the PMU sampling time interval Theoretical maximum memory bandwidth This is an inherent hardware parameter, the value of which is determined by consulting the server motherboard or CPU's technical specifications. In this example, it represents the theoretical bandwidth of DDR4-3200 dual-channel memory. This example server's theoretical maximum memory bandwidth... The PMU sampling interval is 25.6 gigabytes per second (GB / s). The sampling period is 100 milliseconds. Within one sampling period, the memory controller recorded a total of 1.536 gigabytes of read / write bytes. Therefore, the theoretical maximum data transfer volume for this period is 25.6 multiplied by 0.1, which is 2.56 gigabytes. Memory bus bandwidth saturation. The value is 1.536 divided by 2.56, which gives 0.6.
[0075] Define a mapping table between database transaction IDs and operating system process IDs. This data structure is used to establish a direct causal relationship between macro-level business operations and micro-level system execution entities. It is a dynamically updated data structure stored in key-value pairs. The macro-level business operation is represented by the database transaction ID, and the micro-level system execution entity by the operating system process ID. This data structure is built and maintained through application-layer instrumentation or kernel-layer probes on the database system's connection management layer. When an external application client establishes a new connection session with the database server, the operating system assigns a unique operating system process ID to the database worker process or thread handling that session. The system captures this assignment event using a pre-defined probe. When a new database transaction is initiated within this session, the database itself assigns a unique transaction ID to this transaction. The system probe simultaneously captures the transaction's creation event and stores the newly acquired transaction ID and the previously captured process ID in a mapping table as key-value pairs. Client application account A1 establishes a connection with the database through the connection pool. The operating system assigns a process ID of "5678" to the database worker process handling this connection. Subsequently, application account A1 initiates a transfer operation. The database creates a transaction for this operation and assigns it the transaction ID "TXN-A1B1C1-123". The system probe captures this association and records it in the mapping table. Create a record in the system: {TXN-A1B1C1-123:5678}; This indicates that the system has recorded a transaction with a unique ID of "TXN-A1B1C1-123" and the amount of this transaction is 5678.
[0076] Define Z-score standardized eigenvalues It represents the degree of deviation of an original feature value from the mean of its group, expressed in standard deviation. It is used to transform feature values from different sources and with different dimensions (including topological risk indicators and computational resource features) to a unified, directly comparable statistical scale; for any original feature value to be standardized, its corresponding Z-score standardized feature value... It equals the original feature value minus a pre-calculated historical baseline mean. Then, the resulting difference is divided by a pre-calculated historical baseline standard deviation. Historical baseline mean and historical baseline standard deviation It was determined through an offline experimental calibration process: during the calibration phase before the system went live, the database system was run for a sufficient period of time under various typical and confirmed normal business loads, and all feature values were continuously collected. Finally, the mean and standard deviation of each feature were calculated from this "normal behavior" dataset.
[0077] This embodiment calibrates the processor cache pollution rate through offline experiments. The historical baseline mean was 0.1, and the historical baseline standard deviation was 0.05. During real-time data acquisition, the current processor cache corruption rate was measured. The value is 0.2. Therefore, the corresponding Z-score standardized eigenvalue is (0.2 minus 0.1) divided by 0.05, resulting in 2.0.
[0078] Furthermore, the comprehensive calculation process of the above content is broken down as follows: The initial input includes a real-time transaction log stream from the database (containing transaction IDs and timestamps), a process creation and destruction event stream from the operating system kernel, a raw performance counter data stream from the PMU bound to the process ID, and the historical baseline mean and historical baseline standard deviation of each feature that have been calibrated in the offline stage.
[0079] Parallel data acquisition and preliminary processing: The system starts two parallel, continuously running data processing threads.
[0080] Thread A2 is defined as having the following computational resource characteristics: sampled at fixed PMU intervals. The process is executed cyclically. Within each cycle, PMU counter data is collected for all currently active database worker processes, and the instantaneous instruction set execution frequency vector is calculated for each. Processor cache pollution rate and memory bus bandwidth saturation This set of computing resource characteristics, along with the corresponding process ID and the current high-precision timestamp, is packaged and stored in a temporary, time-indexed computing resource characteristic cache.
[0081] Thread B2 is defined as maintaining the mapping relationship: it acquires database connection and transaction events in real time. Whenever a new transaction ID is captured and associated with its host process ID, it is entered into the mapping table. Create or update a record in the middle.
[0082] Triggered by an external event, namely, the first module completes a calculation and outputs a three-dimensional topological risk index vector. This vector carries all the transaction IDs corresponding to the set of transaction logs it analyzes, as well as the sliding time window to which the analysis belongs, ultimately forming a three-dimensional topological risk indicator vector time series;
[0083] The system received Then, immediately extract the set of associated transaction IDs; the execution path is: traverse the set of transaction IDs, using each transaction ID as a key to query the mapping table from transaction ID to process ID. This allows us to obtain one or more sets of causal process IDs related to this macroeconomic business risk.
[0084] Using the set of causal process IDs obtained in the previous step, and The sliding time window represents the cache of generated computing resource features. All time-series data generated by these causal process IDs within the specified sliding time window are extracted, i.e., a series of time-series computing resource feature vectors with timestamps.
[0085] For each component of the three-dimensional topological risk index vector time series, and for each component of each feature vector in the extracted computational resource feature vector time series, the defined Z-score standardized eigenvalue calculation method is applied, using their respective historical baseline mean. and historical baseline standard deviation Perform the calculation.
[0086] The final output of the process is two sets of data: a standard topology risk index vector that has been standardized using Z-score. And a composite computational resource feature vector that is strictly aligned with it in terms of sliding time window and causality, and is also Z-score normalized. These two sets of data together constitute a standardized cross-domain feature pair, which can be directly used for subsequent collaborative analysis.
[0087] A clear logical relationship is established between the output Z-score standardized feature values and risk assessment: the larger the absolute value of a feature's Z-score, the more severe the deviation of the feature from its normal behavior baseline, and the stronger the suspicion of anomaly it indicates. In this example, a memory bandwidth saturation with a Z-score of +3.0 and a Gini coefficient drift with a Z-score of +3.0, although their original physical meanings are completely different, represent the same level of anomaly under this mechanism.
[0088] Further explanation: The steps for calculating the cross-domain anomaly collaboration score are performed based on the topological risk change of the topological risk index, the computational resource offset of the computational resource characteristics, and the cross-domain time series correlation coefficient of the two.
[0089] The topological risk change, computational resource offset, and cross-domain temporal correlation coefficient are weighted and summed, and the sum is processed through a nonlinear activation function to obtain the cross-domain anomaly collaboration score.
[0090] The non-linear activation function is a logistic function. The weight coefficients used in the weighted summation are obtained by training a machine learning model on a dataset containing labeled samples.
[0091] The preset collaborative response threshold is determined by analyzing the receiver operation characteristic curves of the validation dataset;
[0092] The steps to set up the distribution blocking command are as follows: distribute it simultaneously to the business logic protection subsystem and the underlying process isolation subsystem;
[0093] The blocking instructions include: an account freeze instruction containing the associated account ID, and a process isolation instruction containing the associated process ID.
[0094] This embodiment uses a preset calculation model to integrate standardized topological risk indicators aligned with time and causality and computing resource characteristics into a cross-domain anomaly coordination score that can quantitatively assess the correlation between the two in terms of anomaly patterns and occurrence times. Subsequently, based on the comparison result of this score and a preset coordination response threshold, it is determined whether a dual-domain anomaly resonance event is generated. When such an event is generated, the associated business layer and system layer entity identifiers are parsed out, and targeted and synchronous blocking instructions are concurrently output to their respective independent protection subsystems to achieve a cross-layer, in-depth defense closed loop against potential threats.
[0095] The Business Logic Protection Subsystem is a security component deployed at the application layer (Layer 7 of the OSI model). Its core function is to monitor and manage application-layer entities and activities that represent business processes. Application-layer entities include, but are not limited to, user accounts, session states, transaction instructions, and order data. This subsystem identifies and controls high-level business risks by parsing application-layer protocols and business data.
[0096] In one or more specific embodiments of the present invention, the business logic protection subsystem may be composed of one or more of the following technical units:
[0097] Web Application Firewall (WAF) or Application Programming Interface (API) Security Gateway: It is configured as a traffic ingress proxy, capable of deeply parsing application layer requests, and performing operations such as blocking, redirecting or rejecting requests associated with specific target account identifiers based on preset rule sets or external instructions.
[0098] Real-time anti-fraud engine: As a standalone microservice, it receives transaction requests forwarded by the business system via synchronous or asynchronous APIs. The engine has a built-in risk assessment model and provides standardized control interfaces to respond to external instructions, adding specific account identifiers to a dynamic blacklist or triggering circuit breakers for high-risk transactions.
[0099] Identity Authentication and Access Management (IAM) System: As a centralized user identity management hub, the IAM system provides standardized control interfaces (such as SCIM or proprietary APIs) to dynamically adjust the access permissions and session status of specified accounts in response to external commands, such as locking accounts and forcibly revoking all valid session tokens.
[0100] Command interface and execution mechanism: In a preferred embodiment of the present invention, the blocking command for business logic generated by the fifth module is encapsulated in a structured data format (e.g., JSON) and sent to the API endpoint of the subsystem via the HTTPS protocol.
[0101] Structured data formats include:
[0102] The target type field, whose value is set to "ACCOUNT" or an equivalent business entity type;
[0103] The target identifier field has a value that is a unique identifier (ID) of the user account to be processed.
[0104] The action field defines the specific action to be taken.
[0105] The instruction types defined in the action field include, but are not limited to:
[0106] Account freeze command: Used to instruct the subsystem to restrict the account from performing preset sensitive operations, such as fund transfers and information modifications.
[0107] Session termination instruction: Used to instruct the subsystem to immediately invalidate all active sessions associated with this account identifier.
[0108] The underlying process isolation subsystem is a security component deployed at the operating system kernel layer or virtualization management layer (OSI layers 3 and 4). Its core function is to monitor and manage the underlying computing resources running in the server computing environment. These underlying computing resources include, but are not limited to, processes, containers, network sockets, and file handles. This subsystem identifies and controls abnormal underlying execution behavior by monitoring system calls, network traffic, and resource consumption.
[0109] In one or more specific embodiments of the present invention, the underlying process isolation subsystem may be composed of one or more of the following technical units:
[0110] Host Intrusion Prevention System (HIDS) or Endpoint Detection and Response (EDR) agent: This is an agent program installed within the server operating system. Through kernel modules or API hooking technology, the agent has the ability to monitor the activity of all processes within the system in real time and can respond to external commands to perform operations such as suspending, terminating, or restricting the system call privileges of processes with specific process identifiers (PIDs).
[0111] Container security platform: In containerized deployment environments, the platform interacts with the API server of container runtimes (such as containerd) or container orchestration systems (such as Kubernetes) to dynamically adjust security policies associated with specific container identifiers, such as applying network isolation policies (NetworkPolicy), limiting CPU / memory resources (cgroups), or applying stricter system call filtering rules (Seccomp).
[0112] Cloud platform native security services: In public or private cloud environments, this service leverages automated security response services provided by cloud service providers. It can receive external event notifications and invoke internal cloud platform APIs to perform operations such as changing network access control lists (ACLs), isolating security groups, or shutting down instances that host abnormal processes.
[0113] Instruction interface and execution mechanism: In a preferred embodiment of the present invention, the blocking instructions for the underlying process generated by the fifth module are encapsulated in a structured data format similar to that described above, and distributed to the subsystem through a secure channel.
[0114] Structured data formats include:
[0115] The target type field is set to the underlying entity type, such as "PROCESS" or "CONTAINER".
[0116] The target identifier field has a value that is the process unique identifier (PID) or container unique identifier (ID) to be disposed of.
[0117] The action field defines the specific action to be taken.
[0118] The instruction types defined in the action field include, but are not limited to:
[0119] Process suspension instruction: Used to instruct the subsystem to suspend the target process using an operating system signal (such as SIGSTOP) to freeze its running state for subsequent analysis.
[0120] Network isolation directives: These are used to instruct subsystems to dynamically modify firewall rules or network policies to block all or part of the network communication of a target process or container.
[0121] Process termination instruction: Used to instruct the subsystem to forcibly terminate the execution of the target process.
[0122] Through the above detailed description of the two execution subsystems, the dual-domain linkage response mechanism proposed in this invention has a clear, specific, and technically feasible implementation path.
[0123] In this embodiment, all key parameters are assigned unique parameter symbols, and their physical meanings, acquisition methods, and determination methods are explained below:
[0124] Topological risk change It quantifies the degree of change in topology risk indicators, which represent business logic risks, within an analysis window compared to the previous window. The calculation of this parameter originates from norm theory in vector calculus, specifically using the Euclidean norm to measure the magnitude of vector change. The calculation logic is as follows: obtain the topology risk indicator vector of the current analysis window t, after Z-score standardization. The topological risk index vector corresponding to the previous analysis window t-1 Calculate the difference between the two to obtain a topological risk change vector. (Topological risk change amount) This is equivalent to squaring each element in the vector of topological risk changes, summing all the squared results, and finally taking the arithmetic square root of the sum.
[0125] In the description of this invention, a time window refers to a pre-defined, periodically rolling time interval used to aggregate business transaction data to calculate macroeconomic risk indicators. When calculations are performed in the fourth module of this invention, the currently being processed sliding time window t is called the analysis window t, and the sliding time window t immediately preceding it is called the previous analysis window t-1. Therefore, the analysis window t and the sliding time window t are consistent in their definition of time interval, and the difference in their naming is only to emphasize their functional roles in different processing stages.
[0126] Set the standard topology risk indicator vector for the current window. The vector of the previous analysis window t-1 is [0.5, 1.2, 0.1]. Given [0.2, 0.8, 0.2], the change vector is [0.3, 0.4, -0.1]. This represents the change in topological risk. The value is the square root of the sum of (0.3 squared, 0.4 squared, and -0.1 squared), which is the square root of 0.26, and finally equals 0.51.
[0127] Calculate resource offset This parameter quantifies the degree to which the actual computing resource usage pattern of a process associated with a business transaction deviates from its normal behavior baseline within an analysis window t. The calculation of this parameter originates from the norm theory in vector calculus, employing the Euclidean norm. The calculation logic is as follows: obtain the composite computing resource feature vector associated with the target transaction within the current analysis window t, after Z-score normalization. This composite vector is formed by concatenating the components of the normalized instruction set execution frequency vector with the normalized processor cache pollution rate and memory bus bandwidth saturation. This composite computational resource feature vector... It is already a result of Z-score standardization, and the value of each element represents the degree of deviation from its historical mean. Therefore, calculating resource offset... The value is directly equal to the feature vector of this composite computing resource. Square each element in the formula, sum all the squared results, and finally take the arithmetic square root of the sum.
[0128] Set the composite computing resource feature vector of the current window The values are [0.3, 2.5, 1.8, 1.1], which correspond to the standardized general instruction frequency, cryptographic instruction frequency, cache pollution rate, and bandwidth saturation, respectively. The resource offset is calculated as the square root of the sum of (0.3² + 2.5² + 1.8² + 1.1²), which is the square root of (0.09 + 6.25 + 3.24 + 1.21), or the square root of 10.79, ultimately equal to 3.28.
[0129] Define cross-domain time series correlation coefficient Its value ranges from [-1, 1] and is used to measure the temporal synchronicity between the changing trend of the topology risk index and the offset trend of the computing resource characteristics within the analysis window.
[0130] The calculation of this parameter originates from correlation analysis in statistics, specifically employing the Pearson product-moment correlation coefficient algorithm. The calculation logic is as follows: Within the current analysis window, two sets of time-series data, aligned and output by the third module, are obtained: one set is the sequence of the three-dimensional topological risk index vector changing over time, and the other set is the sequence of the composite computing resource feature vector changing over time. To calculate the correlation, these two multi-dimensional time series are first converted into two one-dimensional time series, namely, the change in topological risk. Time series and computational resource offset Time series data. Cross-domain time series correlation coefficient. The value of this is equal to the covariance of the two one-dimensional time series divided by the product of their respective standard deviations. Within a window, an increase in topological risk is always accompanied by a synchronous increase in computational resource offset; therefore, the cross-domain time series correlation coefficient... The cross-domain temporal correlation coefficient approaches 1. If there is no significant correlation between the two, then the cross-domain temporal correlation coefficient... It approaches 0. If the relationship is reversed, it approaches -1.
[0131] Define cross-domain anomaly collaboration score Its value ranges within the interval (0, 1). It integrates the magnitude and synchronicity of anomalies to comprehensively assess the risk level of dual-domain resonance. The calculation logic is as follows: calculate a linear cooperative component. The value of this component is equal to the topological risk change. Multiplied by a topological risk weighting coefficient Add the computational resource offset Multiply by a resource weighting factor In addition, cross-domain time series correlation coefficient Multiplied by a relevance weighting coefficient This linear cooperative component is then passed as input to a logistic sigmoid function. Cross-domain anomalous cooperative score. The value of is the output of the Sigmoid function. The three weight coefficients are... , , The values are determined through an offline model training and calibration process: a logistic regression classification model is trained on a sample set containing a large number of labeled (normal / abnormal) cross-domain features. The regression coefficients of each feature obtained after the model training is completed can then be used as the values of these three weight coefficients. In this embodiment, the values are obtained through offline calibration. , , .current , , The linear cooperative component is then (0.51 0.4) + (3.28 0.3) + (0.9 0.8) = 0.204 + 0.984 + 0.72 = 1.908. Inputting 1.908 into the Sigmoid function yields the cross-domain anomalous cooperative score. The value is 0.87. It should be noted that this embodiment... , , It represents the regression coefficients, which indicate the independent influence of each input feature on the final prediction result, rather than the "proportion" allocated within a framework where the sum is 1.
[0132] Define a preset collaborative response threshold Its value ranges from (0, 1); the determination of this parameter originates from the receiver operating characteristic (ROC) curve analysis in signal detection theory. The value of this parameter is determined through an offline threshold optimization process, using an independent validation dataset (also containing labeled normal / abnormal samples) that was not involved in model training, to calculate the cross-domain anomalous collaboration score for each sample in the dataset. By iterating through all possible thresholds from 0 to 1, the true positive rate (TPR) and false positive rate (FPR) at each threshold are calculated, and ROC curves are plotted. Preset collaborative response thresholds are used. The value is the cross-domain anomalous cooperability score corresponding to the point on the ROC curve where the system achieves the highest true positive rate at an acceptable false positive rate (e.g., below 1%). Alternatively, choose the threshold closest to the top-left corner (0, 1) for optimal overall performance.
[0133] The calculation process described above is broken down as follows: The initial input consists of the time series of the topology risk index vector and the time series of the computational resource feature vector, which are aligned and Z-score standardized by the third module, as well as three weight coefficients. , , and preset collaborative response threshold .
[0134] The core component of parallel computing: The system launches three independent computational subprocesses in parallel to compute the basis of the collaborative score.
[0135] 1.1: Based on the input topological risk index vector time series, calculate the difference between the current window and the previous analysis window, and apply the Euclidean norm to calculate the change in topological risk. 1.2: Based on the time series of the input computational resource feature vector, the latest value of the feature vector in the current analysis window is taken, and the Euclidean norm is applied to calculate the computational resource offset. 1.3: Based on the two complete input time series, the Pearson correlation coefficient algorithm is applied to calculate the cross-domain time series correlation coefficient. .
[0136] The three core components obtained in the previous step , , With the corresponding weighting coefficients , , Weighted summation is performed to obtain the linear cooperative component. This linear cooperative component is then input into the Sigmoid activation function to calculate the final cross-domain anomalous cooperative score. .
[0137] The calculated cross-domain anomaly collaboration score With preset collaborative response threshold Compare; if cross-domain anomaly collaborative scores The value is greater than the preset collaborative response threshold. If the result is positive, it is determined that a dual-domain anomalous resonance has occurred, and the system immediately generates a dual-domain anomalous resonance event.
[0138] A dual-domain anomaly resonance event is a structured data object that contains at least: the cross-domain anomaly co-occurrence score that triggered the event. The data includes the original topological risk indicators and computing resource characteristics constituting this event, as well as the set of account IDs and process IDs directly associated with this event extracted from the alignment relationship. This embodiment sets a preset collaborative response threshold. The value is 0.85; based on the generated dual-domain abnormal resonance event, the system immediately executes the blocking command distribution:
[0139] Extract the set of account IDs and process IDs from the event; send one or more account freeze commands to the preset interface of the business logic protection subsystem, the command content of which includes the account IDs to be frozen; send a process pause command or resource limit command to the preset interface of the underlying process isolation subsystem, the command content of which includes the process IDs to be operated on.
[0140] A process suspension command is equivalent to sending a "SIGSTOP" signal to the operating system; a resource limiting command updates the cgroups configuration (by the system administrator) to set the process's CPU quota close to zero; the underlying process isolation subsystem represents "operating system kernel modules or container runtime"; if cross-domain exceptions occur, the score will be affected. The preset collaborative response threshold was not exceeded. If the output is zero, the process ends and there is no output.
[0141] The core fusion method employed in this embodiment is a model combining a weighted linear combination with a nonlinear activation function based on machine learning calibration. Machine learning calibration: Weights are determined through offline training, avoiding the subjectivity and inaccuracy of manually setting parameters. This ensures that the weights accurately reflect the relative importance of each dimension in distinguishing between attack and normal behavior, guaranteeing the objectivity and effectiveness of the model.
[0142] Weighting coefficient , , Obtained through rigorous offline machine learning model training. This process ensures that the determination of coefficients is data-driven and reproducible. Specifically, a logistic regression model is trained, the goal of which is to determine the coefficients based on three input features (…). , , This is used to predict whether a sample is an attack (label 1) or a normal sample (label 0). Once the model training converges, the optimal regression coefficients learned from these three input features are directly used in this embodiment. , , .
[0143] Further explanation: When cross-domain abnormal collaboration score The closer it is to 1, the stronger the synchronicity and correlation between the abnormal evolution trend at the business logic level and the resource consumption pattern at the physical execution level in terms of time and pattern. The higher the probability that a "dual-domain resonance" event driven by malicious behavior is happening or about to happen; the higher the level of necessity and urgency of linkage blocking.
[0144] When cross-domain abnormal collaboration score As the value approaches 0, the behavior at both the business logic and physical execution levels is more likely to be within the normal baseline range. Even if there are fluctuations at a single level, the temporal synchronicity and pattern correlation between the two are less pronounced. This indicates that the observed phenomena are more likely to originate from independent, non-malicious system noise or normal business fluctuations, rather than coordinated attacks, and therefore no coordinated intervention is required.
[0145] When other parameters remain constant, the change in topological risk The increase will lead to abnormal cross-domain collaboration scores. Monotonically increasing. Change in topological risk. It is calculated using the Euclidean norm, and its value is non-negative. In the weighted summation formula, its weight coefficients... Machine learning is used to label values as positive in order to capture the positive contribution of risk. Therefore, the change in topological risk... The increase directly leads to an increase in the linear cooperative component, which, after being mapped by the monotonically increasing Sigmoid function, inevitably results in an abnormal cross-domain cooperative score. The increase in this is consistent with reality: drastic changes in business topology (such as fund flows and account relationships) are a significant indicator of potential risks, and this positive correlation design accurately maps this security principle.
[0146] Calculate the resource offset while keeping other parameters constant. The increase will lead to abnormal cross-domain collaboration scores. Monotonically increasing. (This is related to the change in topological risk.) Similarly, It is also a non-negative norm value, and its weighting coefficient It is also labeled as a positive value. Therefore, The increase also led to abnormal cross-domain collaboration scores. The monotonically increasing trend of the curve is consistent with the laws of physics: a process's behavior pattern (manifested in its instruction set, cache, and memory usage) deviating significantly from its known normal baseline is a strong signal that the process has been hijacked or is being executed with malicious payloads. This positive correlation design ensures sensitivity to underlying execution anomalies.
[0147] When other parameters remain constant, the cross-domain time series correlation coefficient An increase in (from -1 to +1) will result in an abnormal cross-domain collaboration score. Monotonically increasing. Cross-domain temporal correlation coefficient. The value range is [-1, 1]. Its weighting coefficient... It was also labeled as a positive value. When the cross-domain temporal correlation coefficient... As the value increases from negative to positive, the linear cooperative component also increases, thereby boosting the cross-domain anomalous cooperative score. This embodies the core idea of the invention: only when the business logic is abnormal (due to changes in topology risk) will the exception be made. (manifestation) and physical execution anomalies (caused by computational resource offsets) The correlation between the two factors (reflected in the high positive correlation over time) and the cross-domain time series correlation coefficient are shown to be highly positive. A coordinated attack should only be considered the highest risk if its value approaches 1. If the two are uncorrelated (cross-domain temporal correlation coefficient), then... (approaching 0) or even negative correlation (cross-domain time series correlation coefficient) Even if the individual anomalous magnitudes are large (approaching -1), the system will consider them independent and coincidental events, thus suppressing the final risk score. The following is Table 2 of the experimental data based on the above:
[0148] Table 2: Experimental Data Table
[0149]
[0150] In the table above, cross-domain anomaly collaboration score The value is an approximation obtained by calculating based on the weights and applying the Sigmoid function.
[0151] Comparing Scenario 1, 2, and 3 with Scenario 4: In Scenario 1 (normal peak business hours), calculate the resource offset. The value is a high 3.0, but the change in topological risk is small. The cross-domain time-series correlation coefficient is stationary at a value of 0.2, and the two represent the correlation between the two. The value is a low 0.1. Scenario 2 (isolated system jitter) and Scenario 3 (isolated business probing) also exhibit similar "one-sided anomaly" characteristics. Therefore, despite the presence of high-risk signals in a single dimension, the cross-domain anomaly collaboration score calculated by the algorithm of this invention... The values were 0.73, 0.67, and 0.75 respectively, all within a controllable warning range. However, in scenario four (covert illegal software injection), despite the change in topological risk... and calculate resource offset The values were 0.4 and 2.8, respectively, but due to their extremely strong temporal correlation ( The final cross-domain anomaly collaboration score The value surged to 0.93. This demonstrates the synergistic gain effect of the invention, where "1+1>2": the system can penetrate single-dimensional noise and accurately capture the core characteristics of a real attack, which are composed of "abnormal amplitude" and "abnormal synchronicity," thereby effectively suppressing false alarms of traditional methods.
[0152] Comparing Scenario 4 and Scenario 6: Scenario 4 represents a covert attack, whose anomaly signals across various dimensions are not the strongest. Scenario 6 (high-intensity APT attack), on the other hand, exhibits extreme anomalies at both the business and system levels. The algorithm of this invention provides extremely high cross-domain anomaly coordination scores for both types of attacks. Both 0.93 and 0.99 effectively triggered the highest level of response. This demonstrates that the present invention can not only detect extremely covert attacks, but also has a strong detection capability for high-intensity and obvious attacks, showcasing the robustness and wide applicability of the model.
[0153] The ultimate goal of this invention is to quantify cross-domain anomaly collaboration scores. This translates into a precise and automated security response. To this end, based on expert experience and the aforementioned experimental data analysis, the cross-domain anomaly coordination score... The output range (0, 1) is divided into three risk levels with clearly defined operational instructions. The core of this classification standard is to ensure that the strength of the response measures is proportional to the certainty of the risk level, thereby maximizing security protection while minimizing the potential impact on normal business operations. The classification thresholds here are set to (0.5 and 0.85), specifically the best practice values determined through an offline threshold optimization process (ROC curve analysis). See Table 3 below for details.
[0154] Table 3: Interval Definitions and Corresponding Operations
[0155]
[0156] Through the above three-step demonstration, from the perspectives of theoretical mechanism, empirical data, and practical application, the outstanding substantive features and significant progress of the cross-domain collaborative analysis and linkage response method proposed in this invention are fully demonstrated. It not only theoretically constructs a model capable of accurately quantifying the risk of "dual-domain resonance," but also demonstrates through experimental data its significant advantages over traditional single-domain detection technologies in reducing false alarm rates and improving the detection rate of covert attacks in complex attack scenarios. Finally, through clear risk interval division and corresponding automated response strategies, this invention transforms advanced detection algorithms into a closed-loop, combat-ready, defense-in-depth system, realizing a functional shift in security protection from "passive response" to "predictive blocking."
[0157] This embodiment determines the "cross-domain abnormal collaboration score". "Whether the preset coordinated response threshold is exceeded is the central nervous system of the entire linkage control. When this action is triggered, it does not initiate a single, linear response, but simultaneously activates and optimizes the following two seemingly independent but actually intrinsically related technical effects:"
[0158] Technical Effect 1: A qualitative leap from "passive response" to "predictive defense": Traditional security systems typically only respond after damage occurs or malicious file characteristics are clearly identified. In this solution, "cross-domain anomaly collaborative scoring"... The calculation integrates the topological risk change of the topological risk indicator, the computational resource offset of the computational resource characteristics, and the cross-domain temporal correlation coefficient of the two time series. This means that the system no longer only focuses on "whether the current state is abnormal", but also on "whether the system state is evolving towards a known, high-risk resonance mode".
[0159] Intrinsic Connection: The anomalous evolution of the financial topology (such as the concentration of funds in specific dormant accounts) is the "intent" of the attack, while the anomalies in the underlying computing resources (such as a surge in cryptographic instructions) are the "means" to achieve that intent. "Cross-Domain Anomalous Collaboration Score" "By calculating the temporal correlation between these two, signals can be detected just as the 'intent' and 'means' begin to synchronize, before the attack chain is fully closed. Therefore, a 'cross-domain anomaly coordination score'..." The high score is actually a prediction that "a high-probability successful attack is about to be completed".
[0160] Linkage effect: The triggering of core actions enables defensive actions (such as account freezing) to be executed before the actual outflow of funds, advancing the time window for security protection from "after the fact" or "during the fact" to "before the fact", thus achieving predictive defense.
[0161] Technical Effect Two: Optimization from "High False Alarms in a Single Dimension" to "Low False Alarms in Multi-Dimensional Cross-Validation": Single-dimensional security systems, in order to improve detection rates, must set low alarm thresholds, which inevitably leads to a large number of false alarms (e.g., legitimate report queries causing high CPU usage are mistakenly identified as attacks). This solution's "cross-domain anomaly collaborative score" The threshold triggering mechanism is essentially a "two-domain AND-gate" logic, meaning that an alarm will only be triggered when significant and relevant anomalies occur simultaneously in both the financial logic domain and the physical execution domain.
[0162] Intrinsic Relationship: A legitimate business surge may lead to abnormal computing resource usage, but its financial topology is usually stable or conforms to historical patterns (the "intent" of Effect 1 is normal); a small, harmless fluctuation in system processes may produce glitches in physical execution, but it has no corresponding financial transaction behavior. "Cross-Domain Anomaly Collaboration Score" The calculation formula for "cross-domain abnormal collaboration score" naturally utilizes this inherent connection: only when the topological risk representing "intent" and the resource consumption representing "means" both point to malice, will the "cross-domain abnormal collaboration score" be calculated. "That's when it will surge."
[0163] Linkage Effect: The core action is triggered, using information from one domain to verify alerts from another domain, forming cross-validation. This filters out noise caused by single-dimensional fluctuations, significantly reducing the overall false alarm rate of the system without sacrificing sensitivity to complex attacks, thus improving the efficiency and reliability of security operations.
[0164] Please see Figures 2 to 3 A database security management method, used to implement a database security system, includes the following steps:
[0165] Step S1: Based on the financial transaction logs in the database, generate a transaction network graph representing the relationship between fund flows between accounts, and calculate topological risk indicators including at least the account centrality variability rate, the Gini coefficient drift of account fund distribution, and the transaction loop complexity index.
[0166] Step S2: Based on the hardware performance counter data of the server where the database is located, generate computing resource features including at least the instruction set execution frequency vector, processor cache pollution rate, and memory bus bandwidth saturation.
[0167] Step S3: Within a preset time window, perform time alignment and feature normalization processing on topology risk indicators and computing resource characteristics based on transaction ID and timestamp;
[0168] Step S4: Based on the aligned and normalized topology risk indicators and computing resource characteristics, calculate the cross-domain anomaly collaboration score, whereby the cross-domain anomaly collaboration score is used to characterize the degree of correlation between topology risk indicators and computing resource characteristics in terms of time and pattern.
[0169] Step S5: When the cross-domain abnormal collaboration score exceeds the preset collaboration response threshold, a dual-domain abnormal resonance event is generated, and blocking instructions are simultaneously output to the business logic protection subsystem and the underlying process isolation subsystem.
[0170] It should be noted that all calculation formulas in this application employ regression analysis, including but not limited to machine learning algorithms, to deeply analyze the collected parameters and identify their natural trends and interrelationships. Specialized software, such as Python's Scikit-learn library or the R language, is used to automatically generate mathematical models that match the data. Then, cross-validation and other methods are used to objectively evaluate the model performance, and continuous feedback and optimization are combined to ensure that the created formulas truly reflect the inherent laws of the data, thereby guaranteeing their effectiveness and accuracy. In all calculation formulas in this application, the parameters in each formula undergo dimensionless processing within a consistent range to ensure that different physical quantities are compared on the same scale; dimensionless processing techniques include, but are not limited to, min-max-normalization and Z-score standardization.
[0171] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.
Claims
1. A database security system, characterized in that, Specifically, it includes: The first module is used to generate a transaction network graph representing the relationship between funds flow between accounts based on the financial transaction logs of the database, and to calculate topological risk indicators including at least the account centrality variability rate, the Gini coefficient drift of account fund distribution, and the transaction loop complexity index. The second module is used to generate computing resource features, including at least the instruction set execution frequency vector, processor cache pollution rate, and memory bus bandwidth saturation, based on the hardware performance counter data of the server where the database is located. The third module is used to perform time alignment and feature normalization processing on the topology risk indicators and computing resource characteristics based on transaction ID and timestamp within a preset time window. The fourth module is used to calculate a cross-domain anomaly collaboration score based on the topology risk index and the computing resource characteristics after alignment and feature normalization processing, wherein the cross-domain anomaly collaboration score is used to characterize the degree of correlation between the topology risk index and the computing resource characteristics in terms of time and pattern. The fifth module is used to generate a dual-domain abnormal resonance event when the cross-domain abnormal collaboration score exceeds a preset collaboration response threshold, and to simultaneously output blocking instructions to the business logic protection subsystem and the underlying process isolation subsystem.
2. The database security system according to claim 1, characterized in that: The first module is specifically used to: use account ID as the node of the transaction network graph, use the transaction direction as the directed edge of the transaction network graph, and use the transaction amount as the weight of the directed edge; The steps for calculating the account centrality variation rate include: using Page's ranking algorithm to calculate the node centrality score of each account node, and calculating its relative variation rate based on the "node centrality score" of two consecutive time windows; The step of calculating the Gini coefficient drift of the account fund distribution includes: calculating the net fund stock of each account node, calculating the network fund distribution Gini coefficient based on the net fund stock, and calculating the absolute difference of the network fund distribution Gini coefficient between two consecutive time windows. The steps for calculating the transaction loop complexity index include: using a depth-first search algorithm to detect transaction loops, and calculating the "transaction loop complexity index" based on the length and average weight of the loop; Before outputting the account centrality variation rate, it is determined whether the account centrality variation rate of any account node exceeds a preset threshold. If it does, the maximum "account centrality variation rate" is taken as the representative value; otherwise, the average value is taken.
3. A database security system according to claim 2, characterized in that: The steps for generating computing resource characteristics are as follows: obtain the execution count statistics of different instruction sets in real time by accessing the processor performance monitoring unit of the server; and calculate the instruction set execution frequency vector, processor cache pollution rate and memory bus bandwidth saturation by combining the number of hits and misses of the processor's last-level cache and the number of bytes read and written by the memory controller. The time alignment process is performed based on a pre-established mapping that associates database transaction IDs with operating system process IDs. The mapping relationship is established by deploying probes at the database connection management layer to capture the synchronization generation events of transaction IDs and process IDs; The feature normalization steps are as follows: The topology risk index and the computing resource features are processed using the Z-score normalization method.
4. A database security system according to claim 3, characterized in that: The step of calculating the cross-domain anomaly collaboration score is performed based on the topological risk change of the topological risk indicator, the computing resource offset of the computing resource characteristics, and the cross-domain time series correlation coefficient of the two. The topological risk change, the calculated resource offset, and the cross-domain temporal correlation coefficient are weighted and summed, and the sum is processed through a nonlinear activation function to obtain the cross-domain anomaly collaboration score. The preset collaborative response threshold is determined by analyzing the receiver operation characteristic curve of the verification dataset; The steps to set up the distribution blocking command are as follows: distribute it simultaneously to the business logic protection subsystem and the underlying process isolation subsystem; The blocking instructions include: an account freeze instruction containing the associated account ID, and a process isolation instruction containing the associated process ID.
5. A database security system according to claim 4, characterized in that: Topology risk change: This quantifies the degree of change in the topology risk indicator, which represents business logic risk, compared to the previous window within an analysis window. Resource offset: It quantifies the extent to which the actual computing resource usage pattern of a process associated with a business transaction deviates from its normal behavior baseline within an analysis window; Cross-domain temporal correlation coefficient: used to measure the temporal synchronicity between the changing trend of topology risk indicators and the offset trend of computing resource characteristics within the analysis window.
6. A database security system according to claim 5, characterized in that: The calculated cross-domain anomaly collaboration score is compared with a preset collaboration response threshold; If the cross-domain abnormal collaboration score is greater than the preset collaboration response threshold, it is determined that a dual-domain abnormal resonance has occurred, and the system immediately generates a dual-domain abnormal resonance event. Based on the generated dual-domain anomalous resonance event, the system immediately executes the following blocking instruction distribution: Extract the set of account IDs and process IDs from the event; send at least one account freeze command to the preset interface of the business logic protection subsystem, the command content of which includes the account ID to be frozen; send a process pause command or resource limit command to the preset interface of the underlying process isolation subsystem, the command content of which includes the process ID to be operated. If the cross-domain abnormal collaboration score does not exceed the preset collaboration response threshold, the process ends and there is no output.
7. A database security system according to claim 6, characterized in that: The business logic protection subsystem is a security component deployed at the application layer. Its core function is to monitor and handle application layer entities and activities that represent business processes. The underlying process isolation subsystem is a security component deployed at the operating system kernel layer or virtualization management layer. Its core function is to monitor and manage the underlying computing resource entities running in the server computing environment.
8. A database security management method, characterized in that: The method is used to implement the database security system according to any one of claims 1-7, comprising: Step S1: Based on the financial transaction logs in the database, generate a transaction network graph representing the relationship between fund flows between accounts, and calculate topological risk indicators including at least the account centrality variability rate, the Gini coefficient drift of account fund distribution, and the transaction loop complexity index. Step S2: Based on the hardware performance counter data of the server where the database is located, generate computing resource features including at least the instruction set execution frequency vector, processor cache pollution rate, and memory bus bandwidth saturation. Step S3: Within a preset time window, perform time alignment and feature normalization processing on the topology risk indicators and computing resource characteristics based on transaction ID and timestamp; Step S4: Based on the topology risk index and the computing resource characteristics after alignment and feature normalization, calculate the cross-domain anomaly collaboration score, wherein the cross-domain anomaly collaboration score is used to characterize the degree of correlation between the topology risk index and the computing resource characteristics in terms of time and pattern; Step S5: When the cross-domain abnormal collaboration score exceeds the preset collaboration response threshold, a dual-domain abnormal resonance event is generated, and a blocking command is simultaneously output to the business logic protection subsystem and the underlying process isolation subsystem.
Citation Information
Patent Citations
Financial management method with remote access function
CN107315963A