Game account security detection management system and method based on big data

Abstract

The invention relates to the field of security detection, and discloses a game account security detection management system and method based on big data, and the system comprises an account data collection module which is used for collecting the login information, operation behavior data, equipment information and in-game transaction data of a game account in real time; the data storage module is used for storing the collected data, and the data storage module adopts a distributed database architecture to carry out classified storage on the data and establish an index; the big data analysis module is used for analyzing the stored data and judging whether an operation behavior is abnormal or not, and abnormal login equipment and an abnormal transaction module are performed; the safety evaluation module is used for calculating a safety risk score of the account according to analysis results of the operation behavior abnormity, the abnormal login equipment and the abnormal transaction mode; and the early warning module is used for sending out account security early warning when the security risk score exceeds a preset threshold value. According to the invention, efficient and safe monitoring of the game account is realized.

Description

Technical Field

[0001] This invention relates to the field of security detection, specifically to a game account security detection management system and method based on big data. Background Technology

[0002] With the rapid development of the gaming industry, game accounts have evolved from simple login credentials into important carriers containing virtual assets and user identity information. Their security directly affects user rights and the reputation of game developers. However, traditional game account security detection methods have significant limitations and are ill-equipped to address increasingly complex security threats.

[0003] Traditional detection methods often rely on single-dimensional verification, such as passwords or SMS verification codes. These methods can only prevent the risks associated with leaked account passwords, but cannot identify account theft scenarios involving legitimate passwords and abnormal behavior. For example, after obtaining an account password, attackers may log in from a different device, mimic the user's operation frequency but tamper with the core instruction sequence, or conduct high-value virtual item transactions that are inconsistent with the user's historical habits. Traditional detection systems often fail to detect such anomalies in a timely manner due to their lack of multi-dimensional data correlation analysis capabilities.

[0004] Meanwhile, as the number of game users expands, account operation data, device data, and transaction data are growing exponentially. Traditional centralized databases struggle to handle the storage demands of massive amounts of data, and their low data retrieval efficiency leads to excessively high detection latency. Simple statistical analysis algorithms, such as single threshold judgments, cannot capture the implicit correlations between operational behaviors, devices, and transactions, and are prone to false alarms or false negatives. For example, they may classify normal users' device changes or large-scale holiday spending as abnormal, while failing to identify low-frequency but high-risk abnormal transactions. This not only affects user experience but also increases the risk of account theft. Summary of the Invention

[0005] The purpose of this invention is to provide a game account security detection and management system and method based on big data, thereby solving the above-mentioned technical problems.

[0006] The objective of this invention can be achieved through the following technical solutions:

[0007] A game account security detection and management system based on big data includes:

[0008] The account data collection module is used to collect game account login information, operation behavior data, device information, and in-game transaction data in real time.

[0009] The data storage module is used to store the collected data. The data storage module adopts a distributed database architecture, classifies and stores the data, and establishes an index.

[0010] The big data analytics module is used to analyze the stored data to determine whether there are any abnormal operational behaviors, abnormal login devices, or abnormal transactions.

[0011] The security assessment module is used to calculate the security risk score of the account based on the analysis results of abnormal operation behavior, abnormal login devices, and abnormal transaction patterns.

[0012] The early warning module is used to issue an account security warning when the security risk score exceeds a preset threshold.

[0013] As a further technical solution, the big data analysis module includes:

[0014] The first analysis unit is used to identify operational behavior anomalies based on the degree of deviation between the operational behavior data and historical operational behavior data.

[0015] The second analysis unit is used to analyze the device information using a clustering algorithm to identify abnormal login devices;

[0016] The third analysis unit is used to analyze the in-game transaction data using association rule mining technology to detect abnormal transaction patterns.

[0017] As a further technical solution, the login information includes login time, login location, and login IP address; operation behavior data includes game operation command sequence, operation frequency, and operation duration; device information includes device hardware identifier, operating system type and version, and device network environment information; and in-game transaction data includes transaction object, transaction item, transaction amount, and transaction time.

[0018] As a further technical solution, the working process of the first analysis unit is as follows:

[0019] After analysis and standardization, dimensionless deviations in operation frequency, operation duration, and operation command sequence are obtained.

[0020] Through the formula:

[0021] The abnormal operation behavior score A was calculated.

[0022] in, The weighting coefficient for each operation. C represents the dimensionless deviation of each operational behavior. x,y For cross-abnormalities, ω is the product of the deviations of any two dimensionless values ​​in the operational behavior. x,y The weighting coefficients for each cross-outlier are: ρ is the weighting factor, θ is the exponential coefficient, μ is a constant, and α is the adjustment coefficient.

[0023] As a further technical solution, the calculated abnormal operation score A is compared with the abnormal operation threshold AO obtained based on historical data analysis:

[0024] If A ≥ AO, the operation is considered abnormal; otherwise, the operation is considered normal.

[0025] As a further technical solution, the second analysis unit analyzes device information using a clustering algorithm to identify abnormal login devices, and the specific process includes:

[0026] Collect historical login device information, and use the K-means clustering algorithm to perform cluster analysis on device hardware identifiers, operating system types and versions, and device network environment information to form a normal device cluster;

[0027] Calculate the Euclidean distance between the newly logged-in device and the center of each normal device cluster. Sort the calculated Euclidean distances in ascending order and select the first Euclidean distance as the minimum distance between the newly logged-in device and the normal device cluster. When the minimum distance exceeds the preset distance threshold, the newly logged-in device is determined to be an abnormal login device.

[0028] As a further technical solution, the specific process by which the third analysis unit analyzes in-game transaction data using association rule mining technology to detect abnormal transaction patterns includes:

[0029] Step 1: Extract historical normal transaction data from the data storage module. Each transaction record includes transaction time, transaction object, transaction item, and transaction amount. Discretize the continuous features into interval labels through binning, and combine them with the discrete features to form a transaction itemset.

[0030] Step 2: Use an association rule mining algorithm to mine historical transaction itemsets, generating frequent itemsets and strong association rules; the algorithm is either the Apriori algorithm or the FP-Growth algorithm; the strong association rules must simultaneously satisfy the minimum support threshold and the minimum confidence threshold.

[0031] Step 3: Store the discovered strong association rules in the rule base. Each rule is in the form of antecedent and consequent, and record the support, confidence and lift metrics of each rule.

[0032] Step 4: Convert real-time transactions into corresponding transaction itemsets and match them with rules in the rule base; if the transaction itemset violates a strong association rule, calculate the degree of anomaly of the current transaction.

[0033] Step 5: The degree of anomaly is quantified by the rule confidence deviation; specifically: for rule antecedents that fail to match in real-time transactions, the difference between the confidence level and the corresponding rule confidence level in the rule base is calculated, and then multiplied by the support level of the rule for weighting to obtain the violation score of a single rule;

[0034] The transaction anomaly score is obtained by summing the scores of all rule violations and taking a weighted average.

[0035] Step 6: If the abnormal score of a transaction exceeds the preset abnormal score threshold, the transaction is determined to be an abnormal transaction pattern; the abnormal score threshold is the average value calculated based on the abnormal scores of historical normal transactions.

[0036] As a further technical solution, the specific process by which the security assessment module calculates the security risk score of an account includes:

[0037] Based on the analysis results of abnormal operational behavior, abnormal login devices, and abnormal transaction patterns, different weighting coefficients are assigned to each.

[0038] The overall security risk score is calculated using a weighted summation formula:

[0039] Security risk score = q1*A + q2*B + q3*C;

[0040] Where q1, q2, and q3 are weight coefficients, and q1 + q2 + q3 = 1; A, B, and C are the abnormal operation score, abnormal device score, and abnormal transaction score, respectively. The abnormal device score is the dimensionless value after standardization of the minimum distance between the newly logged-in device and the normal device cluster.

[0041] A big data-based game account security detection and management method is implemented based on the aforementioned big data-based game account security detection and management system.

[0042] The beneficial effects of this invention are:

[0043] This invention comprehensively covers game account login information, operation behavior data, device information, and in-game transaction data through an account data collection module. Compared to traditional detection methods that rely solely on single login verification, it achieves full-process data capture of account usage, ensuring no critical data is missed. In the data analysis phase, the big data analysis module comprises three specialized analysis units, each employing adaptation technologies for different data dimensions: the first analysis unit identifies operational anomalies by comparing the deviation between current and historical operation behavior data, accurately capturing subtle changes in user operating habits and avoiding misjudgments caused by relying on a single operational indicator; the second analysis unit uses clustering algorithms to cluster device information, forming clusters of normal devices, and... By calculating the distance between the newly logged-in device and the cluster center, abnormal login devices that are not frequently used by users can be effectively identified, solving the problem that traditional device detection cannot distinguish between normal device changes and malicious login devices due to the single dimension of device information. The third analysis unit uses association rule mining technology to analyze transaction data. By constructing a strong association rule library of historical normal transactions, it can quickly discover abnormal transactions that do not conform to normal transaction patterns. Through the combination of multi-dimensional data collection and professional analysis technology, a three-dimensional anomaly identification system is constructed from the three core dimensions of operation, device, and transaction. This improves the accuracy of identifying abnormal account behavior, reduces the situation of missed abnormal accounts and false positives for normal accounts, and provides more comprehensive protection for account security. Attached Figure Description

[0044] The invention will now be further described with reference to the accompanying drawings.

[0045] Figure 1 This is a schematic diagram of the system structure of the present invention. Detailed Implementation

[0046] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0047] Please see Figure 1 As shown, this invention is a game account security detection and management system based on big data, comprising:

[0048] The account data collection module is used to collect game account login information, operation behavior data, device information, and in-game transaction data in real time.

[0049] The data storage module is used to store the collected data. The data storage module adopts a distributed database architecture, classifies and stores the data, and establishes an index.

[0050] The big data analytics module is used to analyze the stored data to determine whether there are any abnormal operational behaviors, abnormal login devices, or abnormal transactions.

[0051] The security assessment module is used to calculate the security risk score of the account based on the analysis results of abnormal operation behavior, abnormal login devices, and abnormal transaction patterns.

[0052] The early warning module is used to issue an account security warning when the security risk score exceeds a preset threshold.

[0053] In this embodiment, the account data collection module breaks through the limitations of traditional detection methods that only focus on single login information. It captures real-time data on login, operation behavior, device, and in-game transactions across all dimensions, ensuring that no critical security-related information is missed during account use. The data storage module adopts a distributed database architecture, which not only solves the storage pressure of massive amounts of account data but also lays the foundation for rapid data retrieval and analysis through categorized storage and indexing. The big data analysis module accurately identifies various anomalies in the collected data, the security assessment module converts the anomaly analysis results into quantifiable security risk scores, and the early warning module triggers timely warnings when risks exceed the limits. Compared with traditional fragmented and passive security detection methods, this achieves proactive, dynamic, and comprehensive monitoring of game account security, effectively filling the gaps in traditional detection methods in terms of incomplete data coverage and delayed response. It significantly improves the timeliness and effectiveness of account security protection, providing a fundamental guarantee for game account security.

[0054] The big data analysis module includes:

[0055] The first analysis unit is used to identify abnormal operation behavior based on the degree of deviation between the operation behavior data and historical operation behavior data. The time range of historical operation behavior data is taken by default as the normal operation data of the past 30 days, excluding abnormal data during the period of account theft, to ensure the accuracy of the deviation calculation benchmark.

[0056] The second analysis unit is used to analyze the device information through a clustering algorithm to identify abnormal login devices; the K value in the clustering algorithm, namely the K-means algorithm, is determined by combining the Elbow Method with the statistics of the number of historical login devices.

[0057] The third analysis unit is used to analyze the in-game transaction data through association rule mining technology to detect abnormal transaction patterns. The association rule mining cycle is once a week, and the rule base is updated synchronously to adapt to the dynamic changes in in-game transaction patterns.

[0058] In this embodiment, the first analysis unit identifies operational anomalies by comparing the deviation between current and historical operational behavior data, accurately capturing subtle changes in user operating habits and avoiding misjudgments caused by focusing only on a single operational indicator in traditional detection. The second analysis unit analyzes device information using clustering algorithms. By constructing a cluster of normal devices, it can effectively distinguish between users changing devices normally and maliciously logging in, solving the problem that traditional device detection cannot accurately determine device security due to a single information dimension and lack of historical data support. The third analysis unit uses association rule mining technology to analyze in-game transaction data, deeply mining the potential patterns of historical normal transactions and quickly identifying abnormal transactions that do not conform to normal patterns. The above design of subdividing analysis units according to anomaly type and matching adaptation technologies for each unit avoids the shortcomings of traditional unified analysis mode in identifying different types of anomalies inaccurately and lacking specificity. It significantly improves the accuracy and efficiency of identifying various anomalies, reduces misjudgments and omissions caused by improper analysis methods, provides more reliable and accurate anomaly data support for subsequent security assessment modules, and further enhances security detection capabilities.

[0059] The login information includes login time, login location, and login IP address; the operation behavior data includes game operation command sequence, operation frequency, and operation duration; the device information includes device hardware identifier, operating system type and version, and device network environment information; and the in-game transaction data includes transaction object, transaction item, transaction amount, and transaction time.

[0060] As one implementation method, login information is collected through the communication protocol between the game client and the server, and the login location is mapped from IP address to geographic information; operation behavior data is collected by listening to user input events on the game client, such as keyboard keystrokes and mouse clicks, and operation response logs on the server side; device information is obtained from the client to obtain underlying device information, such as hardware identification using a unique device identifier, which is not privacy-sensitive information; network environment information includes network type and carrier; in-game transaction data is collected through the log module of the in-game transaction system to ensure the integrity of transaction objects, items, and amounts; among them, the operation command sequence includes core in-game operation commands such as character movement, skill release, item use, and interface switching, excluding invalid interface clicks such as accidental touch commands.

[0061] In this embodiment, the specific content of login information, operation behavior data, device information, and in-game transaction data is clearly defined, providing a clear and explicit collection standard and scope for the account data collection module. This avoids the problems of missing key information or excessive redundant data caused by vague data collection scope and unclear content in traditional detection. At the same time, a complete and accurate data source can provide more comprehensive and valuable analysis materials for the big data analysis module, ensuring that subsequent anomaly identification of operation behavior, login device, and transaction mode is based on complete and valid data. This reduces analysis bias caused by incomplete or invalid data interference, further improving the reliability and accuracy of the detection results.

[0062] The working process of the first analysis unit is as follows:

[0063] After analysis and standardization, dimensionless deviations in operation frequency, operation duration, and operation command sequence are obtained; for example, Z-score standardization is used.

[0064] Through the formula:

[0065] The abnormal operation behavior score A was calculated.

[0066] in, The weighting coefficient for each operation. C represents the dimensionless deviation of each operational behavior. x,y For cross-abnormalities, ω is the product of the deviations of any two dimensionless values ​​in the operational behavior. x,y For each cross-anomaly item, the weighting coefficients are defined as follows: ρ is the weighting factor, θ is the exponential coefficient, μ is a constant, and α is the adjustment coefficient. ρ, θ, μ, and α are all calibrated based on regression analysis of historical abnormal operation data, for example, by optimizing parameters using gradient descent to maximize the match between the abnormal operation score A and the actual abnormal event. ω x,y It was determined by combining the analytic hierarchy process (AHP) with expert experience.

[0067] The calculated abnormal operation score A is compared with the abnormal operation threshold AO obtained based on historical data analysis: AO is obtained by statistically analyzing the distribution of abnormal operation scores A of normal accounts over the past 6 months, and taking the mean plus 2 times the standard deviation as the initial threshold.

[0068] If A ≥ AO, the operation is considered abnormal; otherwise, the operation is considered normal.

[0069] In this embodiment, the operation frequency, duration, and instruction sequence deviation are transformed into dimensionless data through standardization, effectively eliminating the interference of different dimensions of data on subsequent calculations and ensuring that each indicator is comparable on the same scale. Secondly, the operation behavior anomaly score calculation formula comprehensively considers the weight of each operation behavior, the impact of cross-anomaly items, and various adjustment parameters. It not only highlights the importance of key operation behaviors for anomaly judgment, but also takes into account the anomalies caused by the interaction between different operation behaviors, avoiding the one-sided judgment caused by simply superimposing a single indicator or ignoring cross-influence in the traditional method.

[0070] The abnormal behavior threshold (AO) is not a fixed value, but rather derived from statistical analysis of a large amount of historical operational behavior data from normal accounts. This closely reflects the normal fluctuation range of operational behavior in actual account usage scenarios, avoiding the misjudgments or omissions caused by fixed thresholds used in traditional detection methods that are out of touch with real-world usage. For example, changes in user operating habits or game version updates may lead to adjustments in operating modes. When the abnormal behavior score reaches or exceeds this threshold, it is judged as an abnormal operation; otherwise, it is judged as normal. This method ensures that accounts with genuine abnormal behavior are accurately identified while effectively reducing the misjudgment of normal accounts due to normal operational fluctuations. For instance, if a user's operation frequency occasionally increases slightly due to environmental changes, but does not exceed the threshold derived from their historical data, it will not be misjudged as abnormal. This ensures the rigor of account security detection while also considering user experience, further improving the rationality and accuracy of abnormal behavior judgment and providing reliable judgment results for subsequent security assessments and early warnings.

[0071] The second analysis unit analyzes device information using a clustering algorithm to identify abnormal login devices. The specific process includes:

[0072] Collect historical login device information, and use the K-means clustering algorithm to perform cluster analysis on device hardware identifiers, operating system types and versions, and device network environment information to form a normal device cluster;

[0073] The Euclidean distance between the newly logged-in device and the center of each normal device cluster is calculated. These Euclidean distances are then sorted in ascending order, and the highest-ranked distance is selected as the minimum distance between the newly logged-in device and the normal device cluster. If this minimum distance exceeds a preset distance threshold, the newly logged-in device is considered an abnormal login device. The distance threshold is based on historical statistical results of Euclidean distances between normal login devices and the center of the normal device cluster, using the maximum distance of 95% of normal devices as the threshold. This ensures that over 95% of normal devices are classified as normal, with only a few devices deviating significantly from the threshold being classified as abnormal.

[0074] In this embodiment, by collecting historical login device information and using a clustering algorithm to form a normal device cluster, this cluster fully reflects the characteristic patterns of commonly used devices, providing a benchmark that fits the actual usage of users for subsequent determination of the security of newly logged-in devices. Secondly, by calculating the Euclidean distance between the newly logged-in device and the center of the normal device cluster, and comparing the minimum distance with a preset threshold, it is determined whether the device is abnormal. This distance-based determination method can intuitively reflect the degree of difference between the characteristics of the new device and the user's commonly used devices, avoiding the misjudgment caused by relying solely on single device information such as IP address to determine device security in traditional detection, such as when a user logs in at a new location using a commonly used device.

[0075] When the minimum distance exceeds the threshold, it is identified as an abnormal login device, which can promptly warn of potential malicious login risks; if it does not exceed the threshold, it is identified as normal, ensuring that users are not disturbed when logging in normally by changing devices. The above process not only makes full use of the reference value of historical device data, but also accurately distinguishes between normal and abnormal login devices through scientific algorithms and threshold settings, reducing the security risk of accounts being logged in by malicious devices and providing key device-level protection for account security.

[0076] The specific process by which the third analysis unit analyzes in-game transaction data using association rule mining technology to detect abnormal transaction patterns includes:

[0077] Step 1: Extract historical normal transaction data from the data storage module. Each transaction record includes characteristics such as transaction time, transaction object, transaction item, and transaction amount. Discretize the continuous features into interval labels through binning, which, together with the discrete features, constitute a transaction itemset. The specific method of binning is as follows:

[0078] The equal-frequency binning method is used to divide continuous features such as transaction amount into several intervals, each interval containing the same amount of historical data, to avoid the bias of equal-width binning when the data distribution is uneven. For example, transaction amount can be divided into three intervals: low amount, medium amount, and high amount, each interval containing 1 / 3 of the historical transaction data.

[0079] Step 2: Use an association rule mining algorithm to mine historical transaction itemsets, generating frequent itemsets and strong association rules; the algorithm is either the Apriori algorithm or the FP-Growth algorithm; the strong association rules must simultaneously satisfy the minimum support threshold and the minimum confidence threshold.

[0080] The minimum support threshold is the lowest support of frequently occurring transaction patterns in historical normal transaction data, such as 0.05, which means the frequency of occurrence is not less than 5%; the minimum confidence threshold is the lowest confidence that can distinguish between normal and abnormal transactions, such as 0.8, which means that the probability of the consequent occurring when the antecedent occurs is not less than 80%.

[0081] Step 3: Store the discovered strong association rules in the rule base. Each rule is in the form of antecedent and consequent, and record the support, confidence and lift metrics of each rule.

[0082] Lift, which is calculated as confidence level / (probability of the consequent occurring alone), is used to measure the effectiveness of a rule. A lift greater than 1 indicates that the rule has a positive association, while a lift less than 1 indicates no association or a negative association. Only rules with a lift greater than 1 are retained.

[0083] Step 4: Convert real-time transactions into corresponding transaction itemsets and match them with rules in the rule base; if the transaction itemset violates a strong association rule, calculate the degree of anomaly of the current transaction.

[0084] Step 5: The degree of anomaly is quantified by the rule confidence deviation; specifically: for rule antecedents that fail to match in real-time transactions, the difference between the confidence level and the corresponding rule confidence level in the rule base is calculated, and then multiplied by the support level of the rule for weighting to obtain the violation score of a single rule;

[0085] The transaction anomaly score is obtained by summing the scores of all rule violations and taking a weighted average.

[0086] Step 6: If the abnormal score of a transaction exceeds the preset abnormal score threshold, the transaction is determined to be an abnormal transaction pattern; the abnormal score threshold is the average value calculated based on the abnormal scores of historical normal transactions.

[0087] In this embodiment, continuous transaction features, such as transaction amounts, are discretized into interval labels through binning, solving the problem that continuous data is difficult to use directly for association rule mining and ensuring that transaction data can be adapted to subsequent algorithms. Secondly, the Apriori algorithm or FP-Growth algorithm is used to mine frequent itemsets and strong association rules of historical normal transaction data and store them in the rule base. These rules fully reflect the inherent patterns of normal transactions, such as users' commonly used transaction objects and the range of regular transaction amounts. Then, real-time transactions are converted into transaction itemsets and matched with the rule base. The degree of transaction anomaly is quantified by calculating the rule confidence deviation, and finally, anomaly score threshold is used to determine whether a transaction is abnormal. Compared with the traditional method of judging anomalies solely by whether the transaction amount exceeds the limit, this process can deeply mine the potential associations of transaction data and accurately identify hidden abnormal transactions, such as a user suddenly making a large transaction with a stranger. This reduces the missed judgments caused by a single indicator and avoids misjudging normal special transactions, such as a user giving a large amount of in-game items to a friend during a holiday. It effectively prevents malicious transactions in the game, such as account asset losses caused by transferring virtual assets after account theft, and provides comprehensive protection for the security of in-game transactions.

[0088] The specific process by which the security assessment module calculates the security risk score of an account includes:

[0089] Based on the analysis results of abnormal operational behavior, abnormal login devices, and abnormal transaction patterns, different weighting coefficients are assigned to each.

[0090] The overall security risk score is calculated using a weighted summation formula:

[0091] Security risk score = q1*A + q2*B + q3*C;

[0092] Where q1, q2, and q3 are weighting coefficients, and q1 + q2 + q3 = 1; A, B, and C are the scores for abnormal operation behavior, abnormal device operation, and abnormal transaction, respectively. The abnormal device operation score is the dimensionless value after standardization, representing the minimum distance between the newly logged-in device and the normal device cluster. q1, q2, and q3 are determined by statistically analyzing the contribution of each anomaly type (abnormal operation behavior, abnormal device operation, and abnormal transaction operation) in historical account security events; the abnormal device operation score uses the same Z-score standardization method as described above.

[0093] In this embodiment, firstly, different weighting coefficients are assigned based on the degree of impact of abnormal operation behavior, abnormal login devices, and abnormal transaction patterns on account security. This weighting setting fully considers the security threat levels of different anomaly types. For example, abnormal transactions usually pose a higher threat to account assets than minor operational anomalies, avoiding the risk assessment bias caused by treating all types of anomalies equally in traditional assessments. Secondly, the scores for abnormal operation behavior, abnormal devices, and abnormal transactions are integrated into a comprehensive security risk score through a weighted summation formula, and the sum of the weighting coefficients is explicitly set to 1, ensuring the standardization and rationality of the score calculation. The above comprehensive assessment method can fully reflect the security status of the account in the three core dimensions of operation, device, and transaction, avoiding the one-sidedness caused by assessing account security based on only a single anomaly type. For example, if an account has minor operational anomalies but no device or transaction anomalies, its overall risk score is low and it will not trigger excessive warnings. However, if an account has both device and transaction anomalies, its overall risk score will increase significantly, triggering a warning in a timely manner. The accurate overall risk score ensures that the warning module only triggers warnings when the account is truly facing a high security risk, improving the rationality and effectiveness of security warnings and avoiding the impact of excessive warnings on user experience and the security risks caused by insufficient warnings.

[0094] A big data-based game account security detection and management method is implemented based on the aforementioned big data-based game account security detection and management system.

[0095] It should be noted that the calculation formulas and all parameters involved in the calculations in this invention have been dimensionless beforehand. The process of dimensionless processing is well known in the industry and will not be described here.

[0096] The foregoing has provided a detailed description of one embodiment of the present invention, but this description is merely a preferred embodiment and should not be construed as limiting the scope of the invention. All equivalent variations and modifications made within the scope of the claims of this invention should still fall within the patent coverage of this invention.

Claims

1. A game account security detection and management system based on big data, characterized in that, include: The account data collection module is used to collect game account login information, operation behavior data, device information, and in-game transaction data in real time. The data storage module is used to store the collected data. The data storage module adopts a distributed database architecture, classifies and stores the data, and establishes an index. The big data analytics module is used to analyze the stored data to determine whether there are any abnormal operational behaviors, abnormal login devices, or abnormal transactions. The security assessment module is used to calculate the security risk score of the account based on the analysis results of abnormal operation behavior, abnormal login devices, and abnormal transaction patterns. The early warning module is used to issue an account security warning when the security risk score exceeds a preset threshold.

2. The game account security detection and management system based on big data according to claim 1, characterized in that, The big data analysis module includes: The first analysis unit is used to identify operational behavior anomalies based on the degree of deviation between the operational behavior data and historical operational behavior data. The second analysis unit is used to analyze the device information using a clustering algorithm to identify abnormal login devices; The third analysis unit is used to analyze the in-game transaction data using association rule mining technology to detect abnormal transaction patterns.

3. The game account security detection and management system based on big data according to claim 2, characterized in that, The login information includes login time, login location, and login IP address; the operation behavior data includes game operation command sequence, operation frequency, and operation duration; the device information includes device hardware identifier, operating system type and version, and device network environment information. In-game transaction data includes the trading partner, the traded items, the transaction amount, and the transaction time.

4. The game account security detection and management system based on big data according to claim 3, characterized in that, The working process of the first analysis unit is as follows: After analysis and standardization, dimensionless deviations in operation frequency, operation duration, and operation command sequence are obtained. Through the formula: The abnormal operation behavior score A was calculated. in, The weighting coefficient for each operation. C represents the dimensionless deviation of each operational behavior. x,y For cross-abnormalities, ω is the product of the deviations of any two dimensionless values ​​in the operational behavior. x,y The weighting coefficients for each cross-outlier are: ρ is the weighting factor, θ is the exponential coefficient, μ is a constant, and α is the adjustment coefficient.

5. The game account security detection and management system based on big data according to claim 4, characterized in that, The calculated abnormal operational behavior score A is compared with the abnormal operational behavior threshold AO obtained based on historical data analysis: If A ≥ AO, the operation is considered abnormal; otherwise, the operation is considered normal.

6. The game account security detection and management system based on big data according to claim 2, characterized in that, The second analysis unit analyzes device information using a clustering algorithm to identify abnormal login devices. The specific process includes: Collect historical login device information, and use the K-means clustering algorithm to perform cluster analysis on device hardware identifiers, operating system types and versions, and device network environment information to form a normal device cluster; Calculate the Euclidean distance between the newly logged-in device and the center of each normal device cluster. Sort the calculated Euclidean distances in ascending order and select the first Euclidean distance as the minimum distance between the newly logged-in device and the normal device cluster. When the minimum distance exceeds the preset distance threshold, the newly logged-in device is determined to be an abnormal login device.

7. The game account security detection and management system based on big data according to claim 2, characterized in that, The specific process by which the third analysis unit analyzes in-game transaction data using association rule mining technology to detect abnormal transaction patterns includes: Step 1: Extract historical normal transaction data from the data storage module. Each transaction record includes transaction time, transaction object, transaction item, and transaction amount. Discretize the continuous features into interval labels through binning, and combine them with the discrete features to form a transaction itemset. Step 2: Use an association rule mining algorithm to mine historical transaction itemsets, generating frequent itemsets and strong association rules; the algorithm is either the Apriori algorithm or the FP-Growth algorithm; the strong association rules must simultaneously satisfy the minimum support threshold and the minimum confidence threshold. Step 3: Store the discovered strong association rules in the rule base. Each rule is in the form of antecedent and consequent, and record the support, confidence and lift metrics of each rule. Step 4: Convert real-time transactions into corresponding transaction itemsets and match them with rules in the rule base; if the transaction itemset violates a strong association rule, calculate the degree of anomaly of the current transaction. Step 5: The degree of anomaly is quantified by the rule confidence deviation; specifically: for rule antecedents that fail to match in real-time transactions, the difference between the confidence level and the corresponding rule confidence level in the rule base is calculated, and then multiplied by the support level of the rule for weighting to obtain the violation score of a single rule; The transaction anomaly score is obtained by summing the scores of all rule violations and taking a weighted average. Step 6: If the abnormal score of a transaction exceeds the preset abnormal score threshold, the transaction is determined to be an abnormal transaction.

8. The game account security detection and management system based on big data according to claim 1, characterized in that, The specific process by which the security assessment module calculates the security risk score of an account includes: Based on the analysis results of abnormal operational behavior, abnormal login devices, and abnormal transaction patterns, different weighting coefficients are assigned to each. The overall security risk score is calculated using a weighted summation formula: Security risk score = q1*A + q2*B + q3*C; Where q1, q2, and q3 are weight coefficients, and q1 + q2 + q3 = 1; A, B, and C are the abnormal operation score, abnormal device score, and abnormal transaction score, respectively. The abnormal device score is the dimensionless value after standardization of the minimum distance between the newly logged-in device and the normal device cluster.

9. A method for game account security detection and management based on big data, characterized in that, This method is implemented based on the big data-based game account security detection and management system described in any one of claims 1-8.

Images