A data security risk quantitative dynamic monitoring method and system

Abstract

The application discloses a kind of data security risk quantization dynamic monitoring method and system, belong to data security technical field.The method includes the following steps: global unique collaborative session identification is generated for monitoring task, and the collaborative session identification is distributed to each participant;Corresponding score record is generated, and the distribution difference value of score value is obtained by collaborative calculation;Outlier participants with abnormal scores are identified, and the outlier participants are instructed to switch decision models and recalculate score records;Determine the reason for the divergence, and output the final monitoring result;Periodically calculate the global collaborative health index, and perform recalibration or isolation treatment on frequently abnormal participants.The application solves the problems of lack of consistent detection in scoring, lack of common evidence in auditing, and lack of active sensing in degradation through the distribution of collaborative identification unified evidence, outlier detection switching model, and statistical health index self-repair.

Description

Technical Field

[0001] This invention relates to the field of data security technology, and in particular to a method and system for dynamic monitoring of data security risks. Background Technology

[0002] With the rapid development of collaborative businesses such as joint financial risk control, government data sharing, and cross-regional energy supervision, the risk characteristics possessed by a single institution are limited, making it difficult to independently identify complex attack chains. Multi-party data fusion is essential to improve the comprehensiveness and reliability of risk assessment. However, under the compliance framework of the Data Security Law and the Personal Information Protection Law, the original data of the participating parties cannot be directly shared outside their respective domains. Against this backdrop, cross-domain collaborative monitoring solutions based on privacy-preserving computing technologies such as multi-party secure computation have been proposed, becoming a mainstream technological approach that balances data value release with compliance requirements.

[0003] Existing technical solutions typically employ the following architecture to achieve cross-domain collaborative monitoring: each participant independently maintains the monitoring model and parameter configuration locally, performs risk scoring on the same business entity, and each participant independently triggers corresponding local handling actions based on its own scoring results. Meanwhile, each participant's scoring records and handling logs are stored in their respective local databases, without real-time result exchange or consistency verification between them.

[0004] However, the existing solutions still have significant technical limitations in practical engineering deployment. First, the different data perspectives, model training sample distributions, and model update frequencies and time points among the participating parties lead to significant differences in risk scores for the same event across different parties. Existing solutions lack proactive detection and outlier identification mechanisms for score consistency among participating parties before fusion. Differentiated score results are directly included in the fusion process or output separately, triggering inconsistent decision-making issues such as one party implementing a ban while another maintains permission. Attackers can exploit this inconsistency to select the weakest point in the defense as the attack entry point, bypassing the overall security protection system.

[0005] Secondly, in the existing scheme, the logs and scoring records of each participating party are stored independently and lack a unified collaborative session identifier for association. The fusion results of the central node are not jointly witnessed and verified by all participating parties. As a result, when auditing after the fact, the auditors are faced with multiple contradictory log evidences and cannot determine the true evolution of the event. The overall credibility of cross-domain collaborative monitoring is systematically damaged.

[0006] Third, due to the lack of quantitative measurement methods for the health status of the collaborative system, the above-mentioned problems have continuously eroded the foundation of mutual trust among the participants in the long run. The existing solutions have not designed statistical indicators for assessing the consistency of cross-domain judgments, nor do they have a degradation warning and automatic repair process based on such indicators. The collaborative monitoring system remains in a "superficial operation" state when the consistency continues to deteriorate, and the actual defense effectiveness cannot be actively perceived and intervened. Summary of the Invention

[0007] This application provides a data security risk quantification and dynamic monitoring method and system, which solves the technical problems in the prior art where inconsistent judgment results among participants in cross-domain collaborative monitoring lead to conflicting handling, contradictory audit evidence, and a lack of collaborative health measurement methods that cause the collaborative system to gradually deteriorate. By using collaborative session identifiers to achieve cross-participant scoring correlation and consistency verification, outlier participant identification and model switching correction, data snapshot comparison to distinguish the causes of disagreements and differentiate weight adjustments, and periodically statistically analyzing historical consistency to generate a collaborative health index and performing recalibration or isolation on abnormal participants, this application realizes the automatic maintenance of global consistency of judgment results in cross-domain collaborative monitoring, the immutability and traceability of audit evidence, and the quantitative measurement and proactive repair of the long-term operational stability of the collaborative system.

[0008] This application provides a method for dynamic monitoring of data security risks, including: generating a globally unique collaborative session identifier for the monitoring task, and distributing the collaborative session identifier to each participating party;

[0009] Each participant calculates a risk score locally based on the collaborative session identifier, generates a corresponding score record, and submits the score record to a distributed log storage structure for persistent writing.

[0010] Read multiple scoring records under the same collaborative session identifier in the distributed log storage structure, and calculate the distribution difference value of the scoring values ​​through collaborative computation;

[0011] When the distribution difference value exceeds the tolerance threshold, outlier participants with abnormal scores are identified, and the outlier participants are instructed to switch the judgment model and recalculate the score records.

[0012] By comparing the input data snapshots of the outlier participant with those of other participants, the reasons for the divergence are determined, and the decision weights of the outlier participant are adjusted based on the reasons for the divergence, and the final monitoring results are output.

[0013] Based on the consistency status of historical scoring records in the distributed log storage structure, a global collaborative health index is periodically calculated, and when the global collaborative health index decays, recalibration or isolation measures are performed on participants with frequent anomalies.

[0014] Furthermore, the step of distributing the collaborative session identifier to each participant includes:

[0015] The network address of the initiator, the current timestamp, and a randomly generated integer are concatenated together. A hash operation is performed on the concatenated text, and a string of a preset length is extracted from the operation result as the identifier of the collaborative session.

[0016] The initiator encapsulates the collaborative session identifier and the judgment task description into a transmission data packet, and broadcasts it to all participants through a reliable transmission protocol.

[0017] After receiving the transmitted data packet, each of the participating parties returns a confirmation message to the initiator.

[0018] The initiator counts the number of received confirmation messages. When the number of confirmed messages collected within a preset time exceeds a preset threshold, the initiator confirms that the collaborative session identifier has been successfully distributed and starts the monitoring task; otherwise, the monitoring task is terminated.

[0019] Furthermore, the steps of generating corresponding scoring records and submitting them to a distributed log storage structure for persistent writing include:

[0020] After calculating the risk score, the participants encapsulate a score record containing the collaborative session identifier, their own identity identifier, the risk score value, the hash snapshot of the input data, the model version number, and the current timestamp, and send the score record to the preparatory queue of the shared distributed log storage structure.

[0021] Each participating party performs format validity checks on the scoring records in the pre-queue, and broadcasts the summary information of the scoring records to other participating parties after the checks pass.

[0022] Each participating party compares its own recorded digest with the received digest bit by bit. When the number of confirmation messages that match exceeds the set fault tolerance threshold, the scoring record is officially written to the end of the distributed log storage structure.

[0023] Furthermore, the steps for deriving the distributional differences in the score values ​​through collaborative computation include:

[0024] When the number of newly added records in the distributed log storage structure reaches a set threshold or the periodic timer returns to zero, all score values ​​under the same collaborative session identifier are extracted.

[0025] Each participating party uses a secret sharing mechanism to split its own score value into multiple random shares and distribute them to each other. After performing addition and multiplication operations on each received random share locally, the result shares are exchanged again. The global average value and global variance value are restored through share recombination.

[0026] The calculated global variance value is used as the distribution difference value reflecting the distribution of the score values;

[0027] The distribution difference value is compared with a preset tolerance threshold. If the distribution difference value is less than or equal to the tolerance threshold, it is determined that the scoring results under the current collaborative session have reached an agreement.

[0028] Furthermore, the steps of identifying outlier participants with anomalous scores and instructing them to switch decision models and recalculate score records include:

[0029] If the distribution difference value is greater than the tolerance threshold, then the absolute deviation between the score value of each participant and the global average value is calculated, and the participant with the largest absolute deviation is marked as a candidate outlier participant.

[0030] When the absolute deviation of the candidate outlier is greater than the set outlier determination threshold, the candidate outlier is determined to be an outlier.

[0031] The outlier participant searches locally for the global model file synchronously received from the collaborative domain. When it confirms that the global model file is within its validity period, it switches the locally running model to the global model file, recalculates the corrected score record using the input data of the current monitoring task, and resubmits it until the distribution difference value falls within the tolerance threshold or the number of retries reaches the set upper limit.

[0032] Furthermore, the steps to determine the causes of disagreement, adjust the decision weights of outlier participants based on these causes, and output the final monitoring results include:

[0033] If the distribution difference value still exceeds the range after the outlier participant recalculates the score, a snapshot of the hash value of the input data set of all participants in the session is extracted from the distributed log storage structure.

[0034] The hash value snapshot of the outlier participant is compared one by one with the hash value snapshots of other participants;

[0035] If the hash value snapshot of the outlier participant is consistent with the hash value snapshot of at least one other participant, the cause of the divergence is determined to be model bias, and the participant is marked as a model bias participant.

[0036] If the hash value snapshot of the outlier participant is inconsistent with the hash value snapshots of all other participants, the reason for the divergence is determined to be a substantial difference in the data perspective. The participant is then marked as a true divergent participant and the corresponding result is output.

[0037] Furthermore, the steps of adjusting the decision weights of outlier participants based on the reasons for disagreement and outputting the final monitoring results also include:

[0038] For participants marked as model bias participants, their voting weight in the current collaboration session is reset to zero. The final judgment result is obtained by using the score values ​​of the remaining participants and their respective voting weights as a weighted average. The model bias participants are then instructed to force the local model to roll back to the previous consistent global model version.

[0039] For participants marked as having genuine disagreements, the entire current collaborative session is marked as having genuine disagreements and is transferred to the manual assessment waiting queue. Before the manual assessment results are generated, the voting weight of that participant in the current collaborative session is also reset to zero, and the final judgment result is calculated by weighted averaging of the scores of the other participants.

[0040] Furthermore, the steps of periodically calculating the global collaborative health index and performing recalibration or isolation measures for participants with frequent anomalies include:

[0041] When the set evaluation period is reached, the total number of collaborative sessions completed within that period and the number of sessions that are ultimately marked as consistent are counted. The number of consistent sessions is divided by the total number to obtain the global collaborative consistency index, which is used as the global collaborative health index.

[0042] The global collaboration consistency index is compared with a preset lower threshold. If the global collaboration consistency index is lower than the lower threshold for multiple consecutive evaluation periods, the collaboration system is determined to be in a degraded state and an alarm process is triggered.

[0043] By retrieving historical records, the frequency with which each participant was marked as an outlier was counted, and the top-ranking participants were extracted as major outlier contributors.

[0044] This application provides a data security risk quantification dynamic monitoring system for implementing a data security risk quantification dynamic monitoring method, including: a collaborative session identifier generation module, a score record generation module, a distribution difference value calculation module, an outlier participant identification module, a monitoring result output module, and a health index calculation module;

[0045] The collaborative session identifier generation module is used to generate a globally unique collaborative session identifier for the monitoring task and distribute the collaborative session identifier to each participant.

[0046] The scoring record generation module is used for each participant to calculate a risk score locally based on the collaborative session identifier, generate a corresponding scoring record, and submit the scoring record to a distributed log storage structure for persistent writing.

[0047] The distribution difference value calculation module is used to read multiple scoring records under the same collaborative session identifier in the distributed log storage structure, and to obtain the distribution difference value of the scoring values ​​through collaborative calculation.

[0048] The outlier identification module is used to identify outliers with abnormal scores when the distribution difference value exceeds the tolerance threshold, and to instruct the outlier to switch the judgment model and recalculate the score record.

[0049] The monitoring result output module is used to compare the input data snapshots of the outlier participant with those of other participants, determine the reasons for the disagreement, adjust the decision weight of the outlier participant based on the reasons for the disagreement, and output the final monitoring result.

[0050] The health index calculation module is used to periodically calculate the global collaborative health index based on the consistency status of historical scoring records in the distributed log storage structure, and to perform recalibration or isolation measures on participants with frequent anomalies when the global collaborative health index decays.

[0051] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages:

[0052] By generating globally unique collaborative session identifiers for monitoring tasks and distributing them to all participants, the differentiated scoring results of each participant for the same event can be proactively perceived, preventing attackers from exploiting defensive vulnerabilities to bypass the overall protection due to inconsistent decision-making among participants.

[0053] Furthermore, by identifying outlier participants and instructing them to switch to the global model for re-scoring, scoring biases caused by deviations in the local model can be automatically corrected without human intervention, thus improving the collaborative decision-making in dynamic multi-participant environments.

[0054] Furthermore, by comparing data snapshots to determine the causes of disagreements, differentiated weight adjustments are performed on the biased and genuinely disagreeing parties in the model. At the same time, a collaborative health index is generated by periodically calculating historical consistency. When the index continues to decline, recalibration and isolation measures are performed on the parties that frequently exhibit abnormalities. This allows the degradation trend of the collaborative system in long-term operation to be quantitatively identified and proactively repaired. It also provides a chain of evidence jointly endorsed by all parties involved for post-audit. Attached Figure Description

[0055] Figure 1 A flowchart of a data security risk quantification and dynamic monitoring method provided in this application embodiment;

[0056] Figure 2 This is a schematic diagram of the structure of a data security risk quantification and dynamic monitoring system provided in an embodiment of this application. Detailed Implementation

[0057] This application provides a data security risk quantification and dynamic monitoring method and system, which solves the technical problems in the prior art such as lack of consistency detection and outlier identification in cross-domain collaborative scoring, lack of joint evidence storage in auditing, and lack of quantitative measurement of collaborative health status, which leads to the inability to proactively detect degradation. By distributing collaborative session identifiers to enable each participant to score independently and submit to distributed storage, collaboratively calculating the difference value of scoring records under the same session to identify outliers and instructing them to switch to the global model for re-scoring, and adjusting the weights after comparing data snapshots to output the final result, and periodically statistically analyzing historical consistency to generate a health index and performing recalibration or isolation on abnormal participants when decay occurs, it realizes proactive perception and correction of cross-domain scoring differences, an immutable evidence chain endorsed by multiple parties, and quantitative identification and proactive repair of collaborative degradation trends.

[0058] To better understand the above technical solutions, the following will provide a detailed explanation of the technical solutions in conjunction with the accompanying drawings and specific implementation methods.

[0059] like Figure 1 The diagram shown is a flowchart of a data security risk quantification and dynamic monitoring method provided in an embodiment of this application. The method is applied to a data security risk quantification and dynamic monitoring system and includes the following steps: generating a globally unique collaborative session identifier for the monitoring task and distributing the collaborative session identifier to each participating party;

[0060] Each participant calculates a risk score locally based on the collaborative session identifier, generates a corresponding score record, and submits the score record to a distributed log storage structure for persistent writing.

[0061] Read multiple scoring records under the same collaborative session identifier in the distributed log storage structure, and calculate the distribution difference value of the scoring values ​​through collaborative computation;

[0062] When the distribution difference value exceeds the tolerance threshold, outlier participants with abnormal scores are identified, and the outlier participants are instructed to switch the judgment model and recalculate the score records.

[0063] By comparing the input data snapshots of the outlier participant with those of other participants, the reasons for the divergence are determined, and the decision weights of the outlier participant are adjusted based on the reasons for the divergence, and the final monitoring results are output.

[0064] Based on the consistency status of historical scoring records in the distributed log storage structure, a global collaborative health index is periodically calculated, and when the global collaborative health index decays, recalibration or isolation measures are performed on participants with frequent anomalies.

[0065] Furthermore, the step of distributing the collaborative session identifier to each participant includes:

[0066] The network address of the initiator, the current timestamp, and a randomly generated integer are concatenated together. A hash operation is performed on the concatenated text, and a string of a preset length is extracted from the operation result as the identifier of the collaborative session.

[0067] The initiator encapsulates the collaborative session identifier and the judgment task description into a transmission data packet, and broadcasts it to all participants through a reliable transmission protocol.

[0068] After receiving the transmitted data packet, each of the participating parties returns a confirmation message to the initiator.

[0069] The initiator counts the number of received confirmation messages. When the number of confirmed messages collected within a preset time exceeds a preset threshold, the initiator confirms that the collaborative session identifier has been successfully distributed and starts the monitoring task; otherwise, the monitoring task is terminated.

[0070] In this embodiment, during cross-domain data security monitoring, to ensure that all participants can make aligned judgments on the same business entity or the same security attack event within the same time window, a unified session link needs to be established. The steps include:

[0071] (1) Local generation of session identifiers:

[0072] When a participant first detects a cross-domain business request or abnormal traffic, that participant becomes the initiator of this risk assessment task. The initiator starts a session initialization process on its local computer, extracts its own network address identifier, such as the server's static IP address or the device's unique MAC address, and obtains the current computer system's millisecond-level timestamp. To prevent the identifier from being maliciously predicted or duplicated, the initiator calls a local random number generator, such as a linear congruential generator, to generate a random integer.

[0073] Subsequently, the initiator converts the aforementioned network address identifier, millisecond-level timestamp, and random integer into a string and concatenates them. The concatenated long string is then input into a preset secure hash algorithm, such as SHA-256 or the domestic SM3 cryptographic algorithm, to calculate a fixed-length digital digest. To save network bandwidth and facilitate fast memory retrieval, the first preset length of bytes of this digital digest, such as the first 16 or 32 bytes, is extracted as a unique collaborative session identifier within the global lifecycle of this judgment task.

[0074] (2) Broadcasting of session identifiers and status confirmation:

[0075] The initiator packages the generated collaborative session identifier along with basic descriptive information of the current monitoring task, such as the target user ID and API call type, into an initialization data packet. Using a reliable transport protocol, such as TCP or the gRPC framework, this data packet is broadcast to all collaborative participants in the network.

[0076] Upon receiving the data packet, each participating party first checks whether its local system has the computing resources to process the task. If so, it sends a confirmation message containing its own signature back to the initiator. The initiator sets up a counter and a countdown timer locally, with the timeout period set between 500 milliseconds and 2000 milliseconds depending on the network environment.

[0077] In practical applications, network fluctuations may cause temporary delays for some participants. Therefore, this embodiment designs a flexible quantity threshold mechanism. The initiator does not need to wait for 100% feedback from all participants; as long as the counter value exceeds a preset quantity threshold before the timeout deadline, such as two-thirds of the total number of collaborating parties, or meets Byzantine fault tolerance requirements... Once the node requires confirmation that the collaboration session identifier has been successfully distributed, the task officially enters the execution state. If the timeout does not reach the required number of participants, the initiator sends a task cancellation command to the participating parties that have already provided feedback, completely releasing the session identifier and avoiding unnecessary waste of computing power.

[0078] Furthermore, the steps of generating corresponding scoring records and submitting them to a distributed log storage structure for persistent writing include:

[0079] After calculating the risk score, the participants encapsulate a score record containing the collaborative session identifier, their own identity identifier, the risk score value, the hash snapshot of the input data, the model version number, and the current timestamp, and send the score record to the preparatory queue of the shared distributed log storage structure.

[0080] Each participating party performs format validity checks on the scoring records in the pre-queue, and broadcasts the summary information of the scoring records to other participating parties after the checks pass.

[0081] Each participating party compares its own recorded digest with the received digest bit by bit. When the number of confirmation messages that match exceeds the set fault tolerance threshold, the scoring record is officially written to the end of the distributed log storage structure.

[0082] In this embodiment, after confirming receipt of the collaborative session identifier, each participating party begins to perform independent security checks locally in parallel. The steps include:

[0083] (1) Encapsulation of local rating records:

[0084] Each participating party calculates a corresponding risk score based on the high-dimensional features collected within its own business domain, according to its locally maintained data security risk quantification scoring rules. In this embodiment, the score is set within a closed range of 0 to 100, with higher values ​​indicating higher risk. After calculation, the participating parties encapsulate these scattered judgment data into a rigorously structured scoring record. This record strictly includes the following core fields:

[0085] Collaborative Session Identifier: Used to indicate which collaborative judgment task the score belongs to.

[0086] Identification: A unique identifier for the participant who submitted the rating.

[0087] Risk score value: The specific score calculated by the local model.

[0088] Input data hash snapshot: The feature fingerprint obtained by performing a global hash operation (such as MD5 or SHA-1) on all the original input data on which this calculation depends, is used to verify the consistency of the data in subsequent calculations.

[0089] Model version number: Version information of the risk assessment model currently running locally.

[0090] Current timestamp: The exact time when local score calculation was completed.

[0091] (2) Append write based on distributed consensus:

[0092] To prevent a single participant from tampering with the score afterward to evade responsibility, this approach introduces a distributed log storage structure jointly maintained by all participants, such as an append-only ledger built on the Raft or PBFT protocols.

[0093] Each participating party first submits the encapsulated scoring record to the write preparation queue of this storage structure. Subsequently, nodes in the network automatically trigger format validity checks. First, it checks whether the collaborative session identifier in the record is in the list of currently active tasks; second, it checks whether the clock deviation between the current timestamp in the record and the network standard time is within a reasonable range (e.g., plus or minus 5 seconds); finally, it checks whether the scoring value is within the valid range of 0 to 100.

[0094] After successful verification, the participating parties broadcast the record's summary information to other collaborating parties. Each party compares the received summary bit by bit. When the number of consistent confirmation messages collected by a participating party exceeds the set Byzantine fault tolerance threshold, a formal commit command is sent to the preparation queue. The storage structure appends the score record to the end of the global log, assigns it a monotonically increasing log index number, and returns a credential acknowledgment containing the index and write timestamp to the committing party. If a write fails due to network conflicts, an exponential backoff retry mechanism is initiated for resubmission.

[0095] Furthermore, the steps for deriving the distributional differences in the score values ​​through collaborative computation include:

[0096] When the number of newly added records in the distributed log storage structure reaches a set threshold or the periodic timer returns to zero, all score values ​​under the same collaborative session identifier are extracted.

[0097] Each participating party uses a secret sharing mechanism to split its own score value into multiple random shares and distribute them to each other. After performing addition and multiplication operations on each received random share locally, the result shares are exchanged again. The global average value and global variance value are restored through share recombination.

[0098] The calculated global variance value is used as the distribution difference value reflecting the distribution of the score values;

[0099] The distribution difference value is compared with a preset tolerance threshold. If the distribution difference value is less than or equal to the tolerance threshold, it is determined that the scoring results under the current collaborative session have reached an agreement.

[0100] In this embodiment, after each participant has successfully persisted their respective rating records, it is necessary to assess whether there are serious disagreements among the parties regarding the same event. The steps include:

[0101] (1) Check the triggering conditions:

[0102] The consistency check process is triggered by two types of conditions: quantity triggering refers to the number of newly written score records in the distributed log storage structure reaching the preset check trigger threshold, such as when all participants in the current task have completed writing; time triggering refers to the preset check cycle timer being reset to zero to prevent individual nodes from going offline and causing the process to be stuck indefinitely.

[0103] (2) Collaborative computing under privacy protection:

[0104] To calculate the global divergence degree without disclosing the privacy scores of each organization, this method employs a secure multi-party computation protocol based on secret sharing. Assume the total number of participants in the current decision-making task is... Each participant. Locally, record your original risk score. Split into Random shares:

[0105] ;

[0106] in It is a sufficiently large prime number. (Participants) These shares were distributed to others via encrypted channels. Each participant retains only [their own information]. .

[0107] After all participants have completed their share exchange, each participant performs addition and multiplication operations locally on each received share to calculate the local sum and local sum of squares. Subsequently, the parties exchange these calculated local sums again and reconstruct the shares locally, thus jointly decrypting the global average without revealing any party's specific score. With global variance The calculation formula is as follows:

[0108] ;

[0109] ;

[0110] (3) Consistency determination:

[0111] After calculating the global variance, this is used as the distribution variance value, reflecting the distribution of the score values. This distribution variance value is then compared with a preset consistency tolerance threshold. (For example Perform a size comparison.

[0112] If the distribution difference is less than or equal to the tolerance threshold, it indicates that all participants have a similar level of risk perception regarding the current security incident, and the score differences are within a tolerable range of random fluctuations. In this case, the consistency check passes, all score records are marked as "consistent" in the log, and the monitoring and judgment task ends normally, with the mean value directly output as the final conclusion. If the distribution difference is greater than the tolerance threshold, it means that a serious judgment conflict has occurred among the participants, and the subsequent outlier identification and correction process is automatically triggered.

[0113] Furthermore, the steps of identifying outlier participants with anomalous scores and instructing them to switch decision models and recalculate score records include:

[0114] If the distribution difference value is greater than the tolerance threshold, then the absolute deviation between the score value of each participant and the global average value is calculated, and the participant with the largest absolute deviation is marked as a candidate outlier participant.

[0115] When the absolute deviation of the candidate outlier is greater than the set outlier determination threshold, the candidate outlier is determined to be an outlier.

[0116] The outlier participant searches locally for the global model file synchronously received from the collaborative domain. When it confirms that the global model file is within its validity period, it switches the locally running model to the global model file, recalculates the corrected score record using the input data of the current monitoring task, and resubmits it until the distribution difference value falls within the tolerance threshold or the number of retries reaches the set upper limit.

[0117] In this embodiment, when the distribution discrepancy value exceeds the tolerance threshold, it is necessary to accurately identify the outlier nodes with high divergence and diagnose whether they are caused by local model evolution malformation. The steps include:

[0118] (1) Precise identification of candidate outliers:

[0119] Using the calculated global average Calculate the score for each participant locally. Absolute deviation from the global mean:

[0120] ;

[0121] Identify the participant with the maximum absolute deviation and mark it as a candidate outlier. Then, compare this maximum absolute deviation with a preset outlier determination threshold. (For example The comparison is performed. If the maximum absolute deviation is less than or equal to the outlier determination threshold, it means that although the overall variance is large, no single node shows an extremely outrageous difference. It is attributed to normal statistical fluctuations and does not trigger model switching. The determination task ends in a consistent state. If the maximum absolute deviation is greater than the outlier determination threshold, the candidate outlier participant is officially identified as an outlier participant.

[0122] (2) Consistency alignment and recalculation of the model:

[0123] For a participant identified as an outlier, its local computer system will automatically initiate a self-checking and corrective process. The outlier participant first accesses its local model storage directory and retrieves the most recently downloaded and backed-up globally recognized risk assessment model file from the collaborative domain. The outlier participant reads the version number and generation timestamp of the file to verify whether it is within the preset validity period (e.g., 24 hours).

[0124] If the global model file is valid, outlier participants can use internal software logic to pause the currently used local independent training model and dynamically switch the decision path to the global model file.

[0125] If the global model file has expired or does not exist, the outlier participant immediately sends an emergency pull request to other healthy participants in the network to download the latest globally consistent model file and load it locally.

[0126] After model switching and loading are complete, the outlier participant imports the original input data snapshot corresponding to this monitoring task and re-runs the risk score calculation based on the new global model version to obtain the corrected risk score value. The outlier participant then submits the score record containing the new score to the write preparation queue of the distributed log storage structure, repeating the write consensus and consistency check described above. This retry process is designed to allow setting a maximum number of retries (e.g., 3 times), combined with an exponential backoff waiting time, until the overall variance falls within the tolerance threshold, thus completely constructing a closed loop for model switching and recalculation through textual logic.

[0127] Furthermore, the steps to determine the causes of disagreement, adjust the decision weights of outlier participants based on these causes, and output the final monitoring results include:

[0128] If the distribution difference value still exceeds the range after the outlier participant recalculates the score, a snapshot of the hash value of the input data set of all participants in the session is extracted from the distributed log storage structure.

[0129] The hash value snapshot of the outlier participant is compared one by one with the hash value snapshots of other participants;

[0130] If the hash value snapshot of the outlier participant is consistent with the hash value snapshot of at least one other participant, the cause of the divergence is determined to be model bias, and the participant is marked as a model bias participant.

[0131] If the hash value snapshot of the outlier participant is inconsistent with the hash value snapshots of all other participants, the reason for the divergence is determined to be a substantial difference in the data perspective. The participant is then marked as a true divergent participant and the corresponding result is output.

[0132] Furthermore, the steps of adjusting the decision weights of outlier participants based on the reasons for disagreement and outputting the final monitoring results also include:

[0133] For participants marked as model bias participants, their voting weight in the current collaboration session is reset to zero. The final judgment result is obtained by using the score values ​​of the remaining participants and their respective voting weights as a weighted average. The model bias participants are then instructed to force the local model to roll back to the previous consistent global model version.

[0134] For participants marked as having genuine disagreements, the entire current collaborative session is marked as having genuine disagreements and is transferred to the manual assessment waiting queue. Before the manual assessment results are generated, the voting weight of that participant in the current collaborative session is also reset to zero, and the final judgment result is calculated by weighted averaging of the scores of the other participants.

[0135] In this embodiment, if the outlier participant's recalculated score still cannot align with the others after switching to the globally recognized model, it indicates that the problem lies not in the model itself, but in the data foundation. In this case, the following steps are performed:

[0136] (1) Data snapshot hash comparison:

[0137] The process of determining a genuine divergence is automatically triggered. The audit component or consensus node reads all previously locked input data hash snapshots from the distributed log storage structure. The hash value of the data snapshot of the outlier participant is then cross-validated one-to-one with the hash values ​​of other participants.

[0138] If the hash value of an outlier participant is found to be exactly the same as the hash value of at least one other participant, it indicates that the data base is completely identical. If the variance is still excessive in this case, it proves that the outlier participant's local model has residual parameter bias or overfitting.

[0139] Mark the outlier as a model bias participant. If the outlier's hash value is different from all other participants, it indicates that the outlier has collected data characteristics that are significantly different from other organizations due to geographical location, business blind spots, or interface limitations, i.e., there is a substantial difference in data perspective. Mark the outlier as a genuine divergent participant.

[0140] (2) Differentiated weight adjustment strategy:

[0141] In response to these two different reasons for disagreement, different security decisions are made at the software control layer:

[0142] For participants marked as model-biased, their judgments are considered unreliable due to the impairment of their local models. In the current collaborative session, their voting weights are directly configured to zero. The final risk assessment result is calculated by a weighted average of the remaining healthy participants in the network based on their initial weights.

[0143] Simultaneously, the model bias participants trigger a forced rollback locally, disabling the current faulty model and rolling back to the previous known, intact global model version. It retrieves a predetermined number of recent historical rating records marked as consistent from the distributed log storage structure, extracts the corresponding input data snapshots as a clean training set, and re-performs model calibration training locally.

[0144] For participants marked as having genuine disagreements, forcibly erasing or aligning their unique, isolated data would result in a loss of overall security perspective. The current collaborative session is therefore marked as "genuinely disagreed" and placed in an out-of-band queue for manual review by security experts from various organizations. Before the manual conclusion is reached, to ensure business continuity, the voting weight of this participant is temporarily reset to zero within the current session, and the weighted average of the remaining participants' scores drives temporary actions on the local execution end. However, the distributed logs permanently retain traces of this genuine disagreement as an immutable cross-domain audit evidence chain.

[0145] Furthermore, the steps of periodically calculating the global collaborative health index and performing recalibration or isolation measures for participants with frequent anomalies include:

[0146] When the set evaluation period is reached, the total number of collaborative sessions completed within that period and the number of sessions that are ultimately marked as consistent are counted. The number of consistent sessions is divided by the total number to obtain the global collaborative consistency index, which is used as the global collaborative health index.

[0147] The global collaboration consistency index is compared with a preset lower threshold. If the global collaboration consistency index is lower than the lower threshold for multiple consecutive evaluation periods, the collaboration system is determined to be in a degraded state and an alarm process is triggered.

[0148] By retrieving historical records, the frequency with which each participant was marked as an outlier was counted, and the top-ranking participants were extracted as major outlier contributors.

[0149] In this embodiment, to prevent the entire collaborative network from gradually degenerating into a loose sandbox of independent operations over long-term operation, a long-term health measurement and proactive defense mechanism is introduced, including the following steps:

[0150] (1) Periodic calculation of the collaborative health index:

[0151] The system uses fixed time windows, such as every 24 hours, or every 1000 completed collaborative sessions, as an evaluation period. When an evaluation period arrives, the statistics component scans the distributed log storage structure to count the total number of completed collaborative sessions within that period. And the number of sessions that were eventually closed normally in a "consistent state". Dividing the two yields the global coordination index for this period. :

[0152] ;

[0153] This index serves as a core global indicator for assessing the overall health of the cross-domain collaborative network. The global collaborative consistency index is compared to a preset lower threshold (e.g., 0.90, requiring over 90% consensus). If the index falls below the lower threshold for a preset number of consecutive assessment periods, a substantial degradation of the entire collaborative system is determined, and an immediate warning is issued.

[0154] (2) Discovery of major outlier contributors:

[0155] After a degradation alarm is triggered, all inconsistent scoring logs within the period are traced back in reverse. The frequency of each participant's identity being identified as an "outlier participant" is accumulated and sorted in descending order of frequency. A preset number of participants (e.g., the top two) are extracted and defined as major outlier contributors. A structured alarm message containing this blacklist is sent to the network-wide operations and maintenance interface.

[0156] (3) Automatic recalibration and security isolation:

[0157] For the major outlier contributors who have been named, tiered governance will be implemented based on the severity of their behavior:

[0158] When a target participant is listed as a major outlier contributor for a predetermined number of consecutive periods, Level 1 governance is triggered, and the collaborative network issues a "forced recalibration instruction" to it. This instruction includes an index pointer to a globally recognized calibration dataset, pointing to a historically consistent "golden dataset" in the distributed log. Upon receiving the instruction, the target participant must automatically download this dataset in the background and restart model iteration training locally, using the global model file as the parameter starting point, to fine-tune the parameters with the goal of minimizing the prediction error on this calibration set. After training is complete, a hash summary of the obtained model parameters is uploaded to the distributed log and latched for future global model synchronization.

[0159] If a target participant is repeatedly flagged as a major outlier contributor in subsequent evaluation cycles after automatic recalibration, it indicates that its local system may have suffered a severe malicious poisoning attack or a low-level hardware / software failure. The system automatically escalates its handling measures, triggering secondary governance and broadcasting an isolation notification to the entire network. Upon receiving the notification, other participants update their local active member lists and directly remove the outlier participant's identity from all subsequent collaborative sessions. This outlier participant not only loses its eligibility to participate in consistency check calculations, but all its decision weights are also permanently reset to zero. It can only regain network access after the organization completes a thorough system reconstruction and fault investigation through out-of-band manual channels, and the initiator resends a permission message.

[0160] like Figure 2 The diagram shown is a structural schematic of a data security risk quantification dynamic monitoring system provided in this application embodiment. The data security risk quantification dynamic monitoring system provided in this application embodiment includes: a collaborative session identifier generation module, a score record generation module, a distribution difference value calculation module, an outlier participant identification module, a monitoring result output module, and a health index calculation module.

[0161] The collaborative session identifier generation module is used to generate a globally unique collaborative session identifier for the monitoring task and distribute the collaborative session identifier to each participant.

[0162] The scoring record generation module is used for each participant to calculate a risk score locally based on the collaborative session identifier, generate a corresponding scoring record, and submit the scoring record to a distributed log storage structure for persistent writing.

[0163] The distribution difference value calculation module is used to read multiple scoring records under the same collaborative session identifier in the distributed log storage structure, and to obtain the distribution difference value of the scoring values ​​through collaborative calculation.

[0164] The outlier identification module is used to identify outliers with abnormal scores when the distribution difference value exceeds the tolerance threshold, and to instruct the outlier to switch the judgment model and recalculate the score record.

[0165] The monitoring result output module is used to compare the input data snapshots of the outlier participant with those of other participants, determine the reasons for the disagreement, adjust the decision weight of the outlier participant based on the reasons for the disagreement, and output the final monitoring result.

[0166] The health index calculation module is used to periodically calculate the global collaborative health index based on the consistency status of historical scoring records in the distributed log storage structure, and to perform recalibration or isolation measures on participants with frequent anomalies when the global collaborative health index decays.

[0167] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art according to the actual situation.

[0168] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, in the form of a computer program product.

[0169] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0170] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

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

[0172] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for quantitative and dynamic monitoring of data security risks, characterized in that, Includes the following steps: A globally unique collaborative session identifier is generated for each monitoring task, and the collaborative session identifier is distributed to each participating party; Each participant calculates a risk score locally based on the collaborative session identifier, generates a corresponding score record, and submits the score record to a distributed log storage structure for persistent writing. Read multiple scoring records under the same collaborative session identifier in the distributed log storage structure, and calculate the distribution difference value of the scoring values ​​through collaborative computation; When the distribution difference value exceeds the tolerance threshold, outlier participants with abnormal scores are identified, and the outlier participants are instructed to switch the judgment model and recalculate the score records. By comparing the input data snapshots of the outlier participant with those of other participants, the reasons for the divergence are determined, and the decision weights of the outlier participant are adjusted based on the reasons for the divergence, and the final monitoring results are output. Based on the consistency status of historical scoring records in the distributed log storage structure, a global collaborative health index is periodically calculated, and when the global collaborative health index decays, recalibration or isolation measures are performed on participants with frequent anomalies.

2. The data security risk quantification and dynamic monitoring method as described in claim 1, characterized in that, The steps of distributing the collaborative session identifier to each participant include: The network address of the initiator, the current timestamp, and a randomly generated integer are concatenated together. A hash operation is performed on the concatenated text, and a string of a preset length is extracted from the operation result as the identifier of the collaborative session. The initiator encapsulates the collaborative session identifier and the judgment task description into a transmission data packet, and broadcasts it to all participants through a reliable transmission protocol. After receiving the transmitted data packet, each of the participating parties returns a confirmation message to the initiator. The initiator counts the number of received confirmation messages. When the number of confirmed messages collected within a preset time exceeds a preset threshold, the initiator confirms that the collaborative session identifier has been successfully distributed and starts the monitoring task; otherwise, the monitoring task is terminated.

3. The data security risk quantification and dynamic monitoring method as described in claim 1, characterized in that, The steps for generating the corresponding score record and submitting it to the distributed log storage structure for persistent writing include: After calculating the risk score, the participants encapsulate a score record containing the collaborative session identifier, their own identity identifier, the risk score value, the hash snapshot of the input data, the model version number, and the current timestamp, and send the score record to the preparatory queue of the shared distributed log storage structure. Each participating party performs format validity checks on the scoring records in the pre-queue, and broadcasts the summary information of the scoring records to other participating parties after the checks pass. Each participating party compares its own recorded digest with the received digest bit by bit. When the number of confirmation messages that match exceeds the set fault tolerance threshold, the scoring record is officially written to the end of the distributed log storage structure.

4. The data security risk quantification and dynamic monitoring method as described in claim 1, characterized in that, The steps for deriving the distributional differences in score values ​​through collaborative computation include: When the number of newly added records in the distributed log storage structure reaches a set threshold or the periodic timer returns to zero, all score values ​​under the same collaborative session identifier are extracted. Each participating party uses a secret sharing mechanism to split its own score value into multiple random shares and distribute them to each other. After performing addition and multiplication operations on each received random share locally, the result shares are exchanged again. The global average value and global variance value are restored through share recombination. The calculated global variance value is used as the distribution difference value reflecting the distribution of the score values; The distribution difference value is compared with a preset tolerance threshold. If the distribution difference value is less than or equal to the tolerance threshold, it is determined that the scoring results under the current collaborative session have reached an agreement.

5. The data security risk quantification and dynamic monitoring method as described in claim 1, characterized in that, The steps for identifying outliers with anomalous scores and instructing them to switch decision models and recalculate their score records include: If the distribution difference value is greater than the tolerance threshold, then the absolute deviation between the score value of each participant and the global average value is calculated, and the participant with the largest absolute deviation is marked as a candidate outlier participant. When the absolute deviation of the candidate outlier is greater than the set outlier determination threshold, the candidate outlier is determined to be an outlier. The outlier participant searches locally for the global model file synchronously received from the collaborative domain. When it confirms that the global model file is within its validity period, it switches the locally running model to the global model file, recalculates the corrected score record using the input data of the current monitoring task, and resubmits it until the distribution difference value falls within the tolerance threshold or the number of retries reaches the set upper limit.

6. The data security risk quantification and dynamic monitoring method as described in claim 1, characterized in that, The steps to determine the causes of disagreement, adjust the decision weights of outlier participants based on these causes, and output the final monitoring results include: If the distribution difference value still exceeds the range after the outlier participant recalculates the score, a snapshot of the hash value of the input data set of all participants in the session is extracted from the distributed log storage structure. The hash value snapshot of the outlier participant is compared one by one with the hash value snapshots of other participants; If the hash value snapshot of the outlier participant is consistent with the hash value snapshot of at least one other participant, the cause of the divergence is determined to be model bias, and the participant is marked as a model bias participant. If the hash value snapshot of the outlier participant is inconsistent with the hash value snapshots of all other participants, the reason for the divergence is determined to be a substantial difference in the data perspective. The participant is then marked as a true divergent participant and the corresponding result is output.

7. The data security risk quantification and dynamic monitoring method as described in claim 1, characterized in that, The steps for adjusting the decision weights of outlier participants based on the reasons for disagreement and outputting the final monitoring results also include: For participants marked as model bias participants, their voting weight in the current collaboration session is reset to zero. The final judgment result is obtained by using the score values ​​of the remaining participants and their respective voting weights as a weighted average. The model bias participants are then instructed to force the local model to roll back to the previous consistent global model version. For participants marked as having genuine disagreements, the entire current collaborative session is marked as having genuine disagreements and is transferred to the manual assessment waiting queue. Before the manual assessment results are generated, the voting weight of that participant in the current collaborative session is also reset to zero, and the final judgment result is calculated by weighted averaging of the scores of the other participants.

8. The data security risk quantification and dynamic monitoring method as described in claim 1, characterized in that, The steps for periodically calculating the global collaborative health index and performing recalibration or isolation measures for participants with frequent anomalies include: When the set evaluation period is reached, the total number of collaborative sessions completed within that period and the number of sessions that are ultimately marked as consistent are counted. The number of consistent sessions is divided by the total number to obtain the global collaborative consistency index, which is used as the global collaborative health index. The global collaboration consistency index is compared with a preset lower threshold. If the global collaboration consistency index is lower than the lower threshold for multiple consecutive evaluation periods, the collaboration system is determined to be in a degraded state and an alarm process is triggered. By retrieving historical records, the frequency with which each participant was marked as an outlier was counted, and the top-ranking participants were extracted as major outlier contributors.

9. A data security risk quantification dynamic monitoring system, used to implement the data security risk quantification dynamic monitoring method according to any one of claims 1-8, characterized in that, include: The module includes a collaborative session identifier generation module, a scoring record generation module, a distribution difference value calculation module, an outlier participant identification module, a monitoring result output module, and a health index calculation module. The collaborative session identifier generation module is used to generate a globally unique collaborative session identifier for the monitoring task and distribute the collaborative session identifier to each participant. The scoring record generation module is used for each participant to calculate a risk score locally based on the collaborative session identifier, generate a corresponding scoring record, and submit the scoring record to a distributed log storage structure for persistent writing. The distribution difference value calculation module is used to read multiple scoring records under the same collaborative session identifier in the distributed log storage structure, and to obtain the distribution difference value of the scoring values ​​through collaborative calculation. The outlier identification module is used to identify outliers with abnormal scores when the distribution difference value exceeds the tolerance threshold, and to instruct the outlier to switch the judgment model and recalculate the score record. The monitoring result output module is used to compare the input data snapshots of the outlier participant with those of other participants, determine the reasons for the disagreement, adjust the decision weight of the outlier participant based on the reasons for the disagreement, and output the final monitoring result. The health index calculation module is used to periodically calculate the global collaborative health index based on the consistency status of historical scoring records in the distributed log storage structure, and to perform recalibration or isolation measures on participants with frequent anomalies when the global collaborative health index decays.

Images