Method and device for determining suspected user of target event

Abstract

The embodiment of the invention provides a method for determining a suspected user of a target event, and the method comprises the steps: obtaining a plurality of result tables which are obtained through querying different types of user behavior log tables related to the target event; and for any first result table, determining the respective field abstract of each first field according to the field value of each first field in the first result table. Inputting each first field and the field abstract thereof into a first large model, so that the first large model extracts a plurality of key fields from each first field to form a first compression table; and according to the target field value of the identity information field, reading each first data row from the first compression table to form a first sub-table of the target user identified by the target field value. And utilizing the second large model to generate behavior chain information of the target user based on a plurality of sub-tables, corresponding to the plurality of result tables, of the target user. And determining a suspected user from the plurality of users according to the behavior chain information of the plurality of users in the plurality of result tables.

Description

TECHNICAL FIELD

[0001] One or more embodiments of the present specification relate to the technical field of data security, and in particular to a method and device for determining a suspect user of a target event. BACKGROUND

[0002] With the deepening of enterprise digital transformation, sensitive data assets such as marketing strategies, technical research and development documents, and strategic planning schemes are facing multiple risks caused by unauthorized leakage by internal personnel. Such leaks not only may lead to the disclosure of business secrets and the weakening of competitiveness, but also may result in regulatory penalties and public opinion crises due to violations of laws and regulations such as the Data Security Law and the Personal Information Protection Law. Specifically, employees may unintentionally or for personal gain send confidential documents through email, instant messaging, or physical storage, exposing the core data assets of the enterprise to the risk of leakage.

[0003] To address such risks, enterprises urgently need to establish an efficient data leakage emergency tracing mechanism to monitor and record data flow in real time through technical means, quickly locate the source of the leak, and achieve precise accountability and risk control. The tracing process for internal employee violations of the external sending behavior mainly includes generating a tracing idea, collecting log data, writing SQL queries, selecting suspects, fixing evidence chains, emergency disposal, and event review. Among them, suspect selection requires analyzing massive log data, restoring the employee behavior chain, and locking the suspect range. The traditional method mainly relies on manual analysis by operation experts, but due to the large number of log data fields, large volume, and serious redundancy, manual selection often faces the realistic dilemma of high cost, long time, and low success rate. SUMMARY

[0004] One or more embodiments of the present specification describe a method and device for determining a suspect user of a target event by fully utilizing the capabilities of a large model to determine a suspect user of a target event, thereby significantly reducing labor costs and improving determination efficiency.

[0005] In a first aspect, a method for determining a suspect user of a target event is provided, comprising:

[0006] obtaining a plurality of result tables, the plurality of result tables being obtained by querying different user behavior log tables related to the target event;

[0007] For any first result table, respectively determining a field summary of each first field according to the field value of each first field;

[0008] inputting the each first field and its field summary into a first large model to extract a plurality of key fields from the each first field to form a first compressed table; the plurality of key fields include an identity information field and a behavior information field for identifying a user;

[0009] read, according to a target field value of the identity information field, each first data row from the first compressed table to form a first sub-table of a target user identified by the target field value;

[0010] generate, by using a second large model, behavior chain information of the target user based on multiple sub-tables of the target user corresponding to the multiple result tables;

[0011] determine, according to the behavior chain information of multiple users in the multiple result tables, a suspect user from the multiple users.

[0012] In a second aspect, a device for determining a suspect user of a target event is provided, including:

[0013] an obtaining unit configured to obtain multiple result tables by querying different types of user behavior log tables related to the target event;

[0014] a determining unit configured to determine, for any first result table, a field summary of each first field according to a field value of the each first field, respectively;

[0015] an inputting unit configured to input the each first field and the field summary of the each first field into a first large model to enable the first large model to extract multiple key fields from the each first field to form a first compressed table; the multiple key fields include an identity information field and a behavior information field used for identifying a user;

[0016] a reading unit configured to read, according to a target field value of the identity information field, each first data row from the first compressed table to form a first sub-table of a target user identified by the target field value;

[0017] a generating unit configured to generate, by using a second large model, behavior chain information of the target user based on multiple sub-tables of the target user corresponding to the multiple result tables;

[0018] The determining unit is further configured to determine, according to the behavior chain information of multiple users in the multiple result tables, a suspect user from the multiple users.

[0019] In a third aspect, a computer storage medium is provided, and the computer storage medium stores a computer program. When the computer program is executed in a computer, the computer program enables the computer to execute the method in the first aspect.

[0020] In a fourth aspect, a computing device is provided, including a memory and a processor. The memory stores executable code, and the processor executes the executable code to implement the method in the first aspect.

[0021] This specification provides a method and apparatus for identifying a suspected user of a target event. First, a large model is used to compress multiple query result tables corresponding to multi-source log data. Then, user behavior chain information is generated based on the compression results. Finally, the suspected user of the target event is identified based on the behavior chain information. This can significantly reduce labor costs and improve identification efficiency. Attached Figure Description

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

[0023] Figure 1 This is a schematic diagram illustrating an implementation scenario of one embodiment disclosed in this specification;

[0024] Figure 2 This diagram illustrates a method for obtaining multiple result tables in one example of this specification.

[0025] Figure 3 A flowchart illustrating a method for determining a suspected user of a target event according to an embodiment of this specification is shown.

[0026] Figure 4 A schematic diagram illustrating a cell compression method in one example of this specification is shown;

[0027] Figure 5 This diagram illustrates a method for constructing an identity information data table in one example of this specification.

[0028] Figure 6 A schematic diagram of an apparatus for determining a suspected user of a target event according to one embodiment of this specification is shown. Detailed Implementation

[0029] The solution provided in this specification will now be described with reference to the accompanying drawings.

[0030] As mentioned earlier, traditional methods primarily rely on manual analysis by operational experts to identify suspects. Taking the tracing of internal employees' unauthorized external data transfers as an example, the process begins with domain experts reading and analyzing log results to trace each employee's behavioral chain and, based on this, narrowing down the range of suspects with the highest risk of data leakage. When the volume of log results to be analyzed is relatively small, domain experts can accurately pinpoint suspects based on their years of experience in data tracing. However, manual processing requires continuous investment from domain experts, leading to excessively high labor costs. Furthermore, when dealing with large-scale or high-frequency data processing needs, manual processing becomes excessively time-consuming, and when the data volume is too large, it becomes completely unmanageable for humans, resulting in tracing failure.

[0031] To address this, this solution proposes first using a large model to compress multiple query result tables corresponding to multi-source log data, then generating user behavior chain information based on the compressed results, and finally identifying the suspect user for the target event based on this behavior chain information. This approach can significantly reduce labor costs and improve identification efficiency.

[0032] Figure 1 This is a schematic diagram illustrating an implementation scenario of one of the embodiments disclosed in this specification. Figure 1 In this process, multiple result tables T1-Tn can be obtained by querying different types of user behavior log tables related to the target event. For result table Ti, first, the field summary of each field in result table Ti is determined. Then, using the large model, based on the field summaries of each field, key fields are extracted from each field to obtain the corresponding compressed table. Next, the field values ​​corresponding to the key fields for each user are read from the compressed table, thereby obtaining the sub-tables corresponding to result table Ti for each user. In this way, multiple sub-tables corresponding to multiple result tables T1-Tn can be obtained for each user. Finally, using the large model, based on the multiple sub-tables for each user, the user's behavior chain information is generated, and based on the behavior chain information of each user, the suspected users of the target event are identified.

[0033] The following section explains how the results tables T1-Tn were obtained.

[0034] Figure 2 This document illustrates a method for obtaining multiple result tables in one example. Figure 2 In this approach, assuming the target event is a file outgoing event, the event description of the target event can be input into a large model. Based on the event description, the model can determine several file propagation paths and generate corresponding source tracing texts for each path. Each source tracing text should at least indicate a corresponding user behavior log table. Next, structured query statements can be generated for each source tracing text. Finally, the structured query statements are executed to obtain multiple result tables.

[0035] The event descriptions mentioned above may include, but are not limited to, file names (e.g., project planning.pptx), file content, and sending channels.

[0036] In addition, the aforementioned file distribution paths may include, but are not limited to, email, instant messaging clients, cloud storage, and social media platforms.

[0037] In one example, the generated source tracing texts can be as follows:

[0038] 1. Query the employees' terminal operation logs to identify which employees' terminals have downloaded, accessed, or edited the outgoing file.

[0039] 2. Query the employees' email service outbound log table to identify which employees have sent the file to external email addresses.

[0040] 3. Query the outgoing logs of employees' instant messaging clients to identify which employees have sent files to external personnel via instant messaging tools.

[0041] After generating the text for each source tracing approach, the large model can be used to generate corresponding structured query languages ​​(SQL) for each source tracing approach text. Of course, it can also be written manually, and this manual does not limit this.

[0042] It should be understood that the query source table clause in the above structured query statement includes the user behavior log table.

[0043] Finally, each of the multiple result tables obtained above may include multiple fields (e.g., dozens or even hundreds) related to the target event, and the fields included in each result table may be different.

[0044] In one example, the result tables may include the following main fields: identity information field, behavior information field, time field, etc.

[0045] The following describes the method for identifying suspected users of a target event based on the results tables T1-Tn mentioned above.

[0046] Figure 3 This diagram illustrates a method flowchart for identifying a suspected user of a target event according to one embodiment of this specification. This method can be executed by any apparatus, device, platform, or cluster of devices with computing and processing capabilities. Figure 3 As shown, the method may include the following steps:

[0047] Step S302: Obtain multiple result tables. A single result table may include multiple fields related to the target event.

[0048] The method for obtaining multiple result tables can be found above. First, use the large model to generate several source tracing idea texts, and then execute the structured query statements corresponding to each source tracing idea text. This will yield multiple result tables.

[0049] Of course, in practice, you can also write and execute structured query statements based on expert experience to obtain the result table. This manual does not limit this approach.

[0050] As mentioned earlier, a single result table may contain dozens or even hundreds of fields (hereinafter referred to as raw fields), but not all of these raw fields are helpful in identifying suspects. Therefore, it is necessary to filter these raw fields, that is, to select the key fields that are helpful in identifying suspects, in order to reduce the data volume.

[0051] Specifically, the number of key fields to be extracted, λ, can be set. If the number of fields in a result table does not exceed λ, then all original fields are key fields. If the number of fields in a result table exceeds λ, then the field filtering process in steps S304-S306 can be executed, which is to perform column compression.

[0052] Step S304: For any result table T1, determine the field summary of each field based on the field value of each field.

[0053] In one example, a field summary for a single field may include field value statistics and / or field value sampling information. The field value statistics for a particular field can be obtained by iterating through all the field values ​​in the result table T1, and may include, but are not limited to, the number of field values, maximum value, minimum value, median, and high-frequency values.

[0054] Furthermore, the field value sampling information for a certain field is a subset of field values ​​extracted from multiple field values ​​of that field. Taking the data type of the field as text as an example, we can first perform word segmentation on each field value of the field. Then, we can combine the word segmentation results for each field value and count the n most frequent keywords. Finally, we can randomly sample a few keywords (for example, 3) from these n keywords as the field value sampling information for that field.

[0055] Of course, in practice, the field summary of a single field may also include other information, and this specification does not limit this.

[0056] For example, assuming the above result table T1 is obtained by querying the terminal operation log table, its contents can be as shown in Table 1.

[0057] Table 1

[0058]

[0059] Of course, in practice, Table 1 may contain more rows and / or more columns, which is not limited in this specification.

[0060] Step S306: Input each field and its field summary into the large model, and let it extract multiple key fields from each field to form a compressed table T1'.

[0061] These key fields include user identification information and behavioral information fields. Additionally, a time field may also be included.

[0062] The identity information field belongs to one of the following information categories: employee ID, name, nickname, username, etc.

[0063] In practice, the input of the above-mentioned large model may also include one or more of the following: the field names and explanations of each field in the result table T1, the source tracing text corresponding to the result table T1, and the structured query statement corresponding to the result table T1, etc.

[0064] Specifically, the prompt word "propmt1" can be input into a large model to extract multiple key fields. Here, "propmt1" can include: the model's role (e.g., "You are an expert with the perspectives of both a data analyst and a database architect"), the instruction description (e.g., "Your task is to identify and extract the most critical fields from a given table"), the filtering principles (e.g., fields that uniquely identify each row of records; numerical or status fields that most directly reflect the table's theme; key categorical fields used for grouping and filtering), a reference example, the input data (i.e., the result table), and the output format (e.g., outputting a comma-separated list of the final identified key field names) and constraints (e.g., not outputting field values).

[0065] It should be understood that this is only an illustrative example, and in practice, the prompt word propmt1 may include more (e.g., field names of required fields) or less, which is not limited in this specification.

[0066] This completes the column compression of the result table T1, resulting in the compressed table T1'.

[0067] Taking the result table T1 as an example, which contains the contents shown in Table 1, the corresponding compressed table T1' can be shown in Table 2.

[0068] Table 2

[0069] User name Behavior information Time Alice File download 2025-11-10 10:23:15 Alice File access 2025-11-10 10:24:01 Bob File send-out 2025-11-10 10:25:30

[0070] The compressed table T1' contains only the following three fields: username, behavior information, and time.

[0071] Similar to the method for obtaining compressed table T1', compressed tables corresponding to other result tables can be obtained.

[0072] It should be noted that this solution uses a large model to compress the columns of the result table, which can filter out the fields that are semantically related to the target event from the result table. This helps to improve the accuracy of identifying suspect users.

[0073] It should also be noted that a single compressed table T1' may contain thousands or even tens of thousands of rows of data. To reduce the amount of data processed by a large model in a single run, this solution will divide the compressed table T1' into blocks according to users, so that the large model analyzes the behavioral information of only one user at a time. The following describes this block division process.

[0074] Step S308: Based on the target field value of the identity information field, read each data row r1 from the compressed table T1' to form a sub-table t1 of the target user identified by the target field value.

[0075] Here, the target field value can be any field value of the identity information field. Taking the information category to which the identity information field belongs, name, as an example, the target field value could be "Alice". Taking the information category to which the identity information field belongs, employee ID, as another example, the target field value could be "00001".

[0076] It should be understood that each of the above data rows r1 includes an identity information field and a behavior information field, and the value of the identity information field is the value of the target field mentioned above. In other words, the above sub-table t1 describes the relevant behavior of the target user. Since sub-table t1 only describes the relevant behavior of the target user, the above step S308 can also be referred to as row compression.

[0077] Similarly, sub-tables of other users identified by the values ​​of other fields in the aforementioned identity information field can be obtained.

[0078] In summary, by performing the above step S308, the compressed table T1' can be divided into multiple sub-tables, where each sub-table describes a user's relevant behavior.

[0079] Taking the compressed table T1' as an example, which contains the contents shown in Table 2, we can obtain two sub-tables, which can be shown in Table 3 and Table 4 respectively.

[0080] Table 3

[0081] User name Behavior information Time Alice File download 2025-11-10 10:23:15 Alice File access 2025-11-10 10:24:01

[0082] This sub-table corresponds to the username "Alice" and is used to describe Alice's related behaviors.

[0083] Table 4

[0084] User name Behavior information Time Bob File send-out 2025-11-10 10:25:30

[0085] This sub-table corresponds to the username "Bob" and is used to describe Bob's related behaviors.

[0086] It should be understood that Tables 3 and 4 are merely illustrative examples, and in practice, Tables 3 and 4 may include more rows of data, which is not limited in this specification.

[0087] Similarly, other compressed tables can also be divided into multiple sub-tables.

[0088] Step S310: Using the large model, generate the target user's behavior chain information based on multiple sub-tables corresponding to multiple result tables.

[0089] It should be noted that the information categories of the identity information fields in different result tables are usually different. For example, the information category of the identity information field in result table T1 is employee ID, while the information category of the identity information field in result table T2 is name. Therefore, the corresponding sub-table cannot be determined directly from other result tables based on the target field value used to identify the target user. Instead, it is necessary to query the identity information data table to determine other identity information of the target user, and then determine other sub-tables for the target user based on the other identity information.

[0090] The aforementioned identity information data table (the construction process will be explained later) includes multiple identity information fields corresponding to different information categories. These different information categories may include, but are not limited to, employee ID, name, username, nickname, etc.

[0091] In one example, the identity information data table can be as shown in Table 5.

[0092] Table 5

[0093] Employee number Name User name 00001 Alice Alice 00002 Bob Bob

[0094] It should be understood that Table 5 is only an illustrative example. In practice, Table 5 may also include multiple identity information retrieved based on the field values ​​of the identity information field in other result tables. This specification does not limit this.

[0095] For example, suppose the target field value is "Alice" in Table 3, meaning its information category is username. And suppose the identity information field in another result table T2 belongs to the employee ID category. Therefore, we can query Table 5 based on username = "Alice" to obtain employee ID = "00001". Then, the sub-table corresponding to employee ID = "00001" in the compressed table of result table T2 can be used as the sub-table corresponding to the target user in result table T2.

[0096] Similarly, sub-tables corresponding to other result tables for the target user can be obtained. Furthermore, sub-tables corresponding to multiple result tables for other users can also be obtained.

[0097] Typically, the amount of data in a cell cannot be known in advance. In addition, this solution can determine whether the amount of data in any cell of any sub-table of any user exceeds the context limit, and compress the cell if it does.

[0098] Figure 4 This diagram illustrates a cell compression method as shown in one example of this specification. Figure 4 In this process, for any cell, if its content length is less than or equal to a preset length, the cell is skipped. If its content length exceeds the preset length, the cell's content is divided into several blocks according to that preset length. Here, the preset length can be the maximum context length that the large model can handle. Using the large model, corresponding block summaries are generated for each block. The block summaries are then aggregated to obtain the target summary. Finally, the content of the cell is replaced with the target summary.

[0099] In one example, the summaries of each chunk can be directly concatenated, and the concatenated result can be used as the target summary.

[0100] In another example, the summaries of each chunk can be input into a large model, which then synthesizes the summaries of each chunk to obtain the target summary.

[0101] It should be understood that after performing the above compression process on cells whose content length is greater than the preset length in any sub-table, the target table corresponding to that sub-table can be obtained.

[0102] It should be noted that this solution can achieve efficient data compression of high-density data such as traffic logs and process logs by compressing cells in the result table.

[0103] For any user, after obtaining multiple sub-tables or multiple target tables for that user, the prompt word `propmt2` can be input into the large model to generate the user's behavior chain information. Here, `propmt2` can include: the model's role (e.g., "You are an expert with the perspectives of both a data analyst and a database architect"), three progressively related instructions (e.g., 1. Determine the target behaviors related to outgoing files and their execution times from the user's multiple sub-tables or multiple target tables; 2. Based on the target behaviors and their execution times, analyze the user's behavior chain information, i.e., what behavior was performed at what time; 3. Based on the user's behavior chain information, determine the user's risk level. For example, if a user first accesses an outgoing file from the company's internal cloud drive and downloads it to their local computer, and then sends the file to an external email address, the corresponding risk level is high risk), a reference example, input data (i.e., the user's multiple sub-tables or multiple target tables), and output format and constraints, etc.

[0104] It should be noted that after inputting the above-mentioned prompt word propmt2 into the large model, the large model can not only output the user's behavior chain information, but also output the user's risk level (e.g., high, medium, low).

[0105] It should be understood that this is only an illustrative example, and in practice, the prompt word propmt2 may include more (e.g., field names of required fields) or less (e.g., no third instruction), and this specification does not limit this.

[0106] As can be seen, this solution can leverage the capabilities of large models to compress multiple result tables used to identify suspect users (including column compression and table compression) and determine the user's behavioral chain information. This solves the problem of time-consuming and labor-intensive manual sorting of behavioral chain information in traditional technologies.

[0107] Step S312: Based on the behavioral chain information of multiple users in multiple result tables, identify the suspect user from among the multiple users.

[0108] In one embodiment, the behavioral chain information of multiple users can be analyzed manually to identify the suspect user from among the multiple users.

[0109] In another embodiment, the risk level can be combined to identify suspected users from multiple users. For example, all users with high risk levels can be identified as suspected users.

[0110] In another embodiment, behavioral chain information of multiple users can be input into a large model, which can score the behavioral risk of multiple users from several dimensions, and suspect users can be identified from multiple users based on the score.

[0111] The aforementioned dimensions may include time and behavior type. Additionally, user status, etc., may also be included.

[0112] Taking time as an example, the corresponding scoring criteria could be: if the target behavior occurs 1-7 days before the file is sent out, the score is increased; if the target behavior occurs after the file is sent out or several months before, the score is decreased.

[0113] Taking behavior type as an example, the corresponding scoring criteria could be: if the file only circulates within the company, meaning the target behavior type is internal forwarding, then the score is reduced. This is because business data often needs to be shared between multiple teams, and may even be publicly available within the company; therefore, many users may access or download the file, which is normal behavior within the scope of their work. However, if the target behavior type is external forwarding, then the user poses a significant risk of unauthorized external forwarding.

[0114] Taking user status as an example, the corresponding scoring criteria could be: when a user is about to be transferred or leave the company, there is a higher probability that they will send internal documents out to outsiders in an attempt to seek lasting benefits before leaving the company. The outward behavior of these users needs to be paid extra attention to, so the score is increased.

[0115] Specifically, the prompt word "propmt3" can be input into a large model to identify suspicious users. Here, "propmt3" can include: the model's role (e.g., "You are a security data analyst"), the instruction description (e.g., "Your task is to rate users according to specified dimensions and rank them based on the ratings"), the rating dimensions (e.g., time, behavior type, and user status), a reference example, input data (behavioral chain information and risk levels of multiple users), and the rationale for the rating.

[0116] It should be noted that after inputting the above-mentioned prompt word propmt3 into the large model, the top k suspected users can be obtained.

[0117] As can be seen, this solution can not only compare the behavioral chain information of different users from multiple dimensions, but also narrow down the range of suspected users to within k, thereby greatly reducing the amount of data.

[0118] It should be understood that this is only an illustrative example, and in practice, the prompt word propmt3 may include more or less content, which is not limited in this specification.

[0119] This completes the selection of suspected users targeting the specific time period.

[0120] The following describes the process of constructing the aforementioned identity information data table.

[0121] Additionally, before constructing the aforementioned identity information data table, the identity information fields in each result table can be identified first. Taking any result table as an example, the field information for each field in the result table can be obtained first. The field information for a single field can include one or more of the following: field name, field explanation, and field value. Then, the field information for each field, along with several user identity information categories and their characteristics (e.g., employee ID consists of 5 Arabic numerals, username consists of lowercase letters), are input into the large model, which then determines the fields with characteristics of any target information category as the identity information fields.

[0122] In one example, the prompt word `propmt4` can be input into a large model to identify identity information fields. Here, `propmt4` can include: the model's role (e.g., "You are an expert with the perspectives of both a data analyst and a database architect"), the instruction description (e.g., "Your task is to identify identity information fields from a given table"), information category characteristics (e.g., employee ID consists of 5 Arabic numerals; username consists of lowercase letters), a reference example, input data (i.e., the result table), and the output format (outputting the recognition results in JSON format, e.g., `{"information category":"employee ID","field name":"staff_id"}`, meaning "staff_id" is the identity information field, and its corresponding information category is employee ID).

[0123] It should be understood that this is only an illustrative example, and in practice, the prompt word propmt4 may include more (e.g., field names of required fields) or less, which is not limited in this specification.

[0124] After identifying the identity information fields from the various result tables, an identity information data table can be constructed.

[0125] Figure 5 This diagram illustrates a method for constructing an identity information data table in one example of this specification. Figure 5 In this process, multiple result tables can be used sequentially as target result tables. All field values ​​of the identity information field in each target result table are iterated through, and based on the current field value, the identity information query interface is called to obtain multiple identity information entries for the current user corresponding to different information categories. Based on the individual identity information entries for multiple users in the multiple result tables, an identity information data table is constructed.

[0126] For example, suppose the target result table is as shown in Table 1. The "Username" field is the identity information field in the target result table. Therefore, we can first call the identity information query interface based on "Alice," assuming we get the following identity information: Employee ID = "00001", Name = "Alice", Username = "Alice". Then, based on "Bob," we call the identity information interface, assuming we get the following identity information: Employee ID = "00002", Name = "Bob", Username = "Bob". In this way, we can obtain the identity information data table as shown in Table 5.

[0127] In summary, the method for identifying suspected users of a target event provided in the embodiments of this specification quickly identifies abnormal behavior and determines the top k suspected users by automatically analyzing multi-source log data, replacing traditional manual screening and significantly improving the efficiency of suspected user identification. Furthermore, this solution incorporates a table compression mechanism to address the limitation of large model context length, ensuring efficient input and processing of massive log data and preventing the loss of critical information due to excessive data volume.

[0128] Corresponding to the method for identifying suspected users of a target event described above, one embodiment of this specification also provides an apparatus for identifying suspected users of a target event, such as... Figure 6 As shown, the device may include:

[0129] The acquisition unit 602 is used to acquire multiple result tables, which are obtained by querying different types of user behavior log tables related to the target event.

[0130] The determining unit 604 is used to determine the field summary of each first field for any first result table based on the field value of each first field.

[0131] The input unit 606 is used to input each first field and its field summary into the first large model, so that it can extract multiple key fields from each first field to form a first compressed table. The multiple key fields include an identity information field and a behavior information field for identifying the user.

[0132] The reading unit 608 is used to read each first data row from the first compressed table according to the target field value of the identity information field, and form a first sub-table of the target user identified by the target field value;

[0133] The generation unit 610 is used to generate the behavioral chain information of the target user based on multiple sub-tables corresponding to multiple result tables using the second major model;

[0134] The determining unit 604 is also used to identify a suspect user from multiple users based on the behavioral chain information of multiple users in multiple result tables.

[0135] In one embodiment, the plurality of result tables further includes a second result table; the apparatus further includes:

[0136] The query unit 612 is used to query the identity information data table based on the target field value and its corresponding first information category, and obtain the second field value of the identity information field whose corresponding information category is the second information category. The identity information data table includes multiple identity information fields corresponding to different information categories, and the second information category is the information category to which the identity information field in the second result table belongs.

[0137] The determining unit 604 is also used to determine the second sub-table from multiple sub-tables corresponding to the second compressed table of the second result table based on the value of the second field.

[0138] In one embodiment, the device further includes:

[0139] Traversal unit 614 is used to sequentially use multiple result tables as the target result table and traverse the values ​​of each field of the identity information field in the target result table;

[0140] Calling unit 616 is used to call the identity information query interface based on the current field value to obtain multiple identity information of the current user corresponding to different information categories identified by the current field value;

[0141] Construction unit 618 is used to construct an identity information data table based on the identity information of multiple users in multiple result tables.

[0142] In one embodiment, the acquisition unit 602 is further configured to acquire field information of each target field in the target result table;

[0143] The input unit 606 is also used to input the field information of each target field and the information categories and features of several user identities into the third model, so that it can determine the target field with features of arbitrary target information categories from each target field as the identity information field.

[0144] The field information for a single target field includes one or more of the following: field name, field description, and field value.

[0145] In one embodiment, the device further includes:

[0146] Compression unit 620 is used to compress the first sub-table to obtain the first target table;

[0147] Compression unit 620 includes:

[0148] The sub-module (not shown in the figure) is used to divide the content of any first cell into several blocks according to the preset length if the content length of the first cell is greater than the preset length.

[0149] The generation submodule (not shown in the figure) is used to generate corresponding block summaries for each block using the fourth major model.

[0150] The summarization submodule (not shown in the figure) is used to summarize the summaries of each block to obtain the target summary;

[0151] A replacement submodule (not shown in the figure) is used to replace the content of the first cell with the target summary;

[0152] The generating unit 610 is specifically used for:

[0153] Based on multiple target tables corresponding to multiple sub-tables, generate behavioral chain information for the target user.

[0154] In one embodiment, the aforementioned key fields also include a time field;

[0155] The generating unit 610 is specifically used for:

[0156] The target prompts are input into the second main model, which instructs the second main model to locate several target behaviors and their execution times related to the target event from multiple sub-tables. Based on these target behaviors and their execution times, the target user's behavior chain information is generated.

[0157] In one embodiment, the determining unit 604 is specifically used for:

[0158] The behavioral chain information of multiple users is input into the fifth model, which scores the behavioral risk of multiple users from several dimensions. Based on the scores, the suspected users are identified from the multiple users. Among these dimensions, at least time and behavior type are included.

[0159] In one embodiment, the target event is a file outgoing event.

[0160] In one embodiment, the acquisition unit 602 is specifically used for:

[0161] Input the event description of the target event into the sixth model, which will determine several file propagation paths based on the event description, and generate corresponding source tracing texts for each file propagation path. Each source tracing text should at least indicate the corresponding user behavior log table.

[0162] Generate corresponding structured query statements for each source tracing approach text;

[0163] Execute each structured query statement to obtain multiple result tables.

[0164] In one embodiment, the input to the first major model also includes one or more of the following:

[0165] The field names and explanations of each first field;

[0166] The source tracing text corresponding to the first results table;

[0167] The structured query statement corresponding to the first result table.

[0168] In one embodiment, the aforementioned different types of user behavior log tables include one or more of the following:

[0169] Terminal operation log table, email service outbound log table, and instant messaging tool outbound log table.

[0170] The functions of each functional unit of the apparatus in the above embodiments of this specification can be implemented through the steps of the above method embodiments. Therefore, the specific working process of the apparatus provided in one embodiment of this specification will not be repeated here.

[0171] The apparatus for identifying a suspect user of a target event provided in one embodiment of this specification can significantly reduce labor costs and improve identification efficiency by making full use of the capabilities of large models to identify the suspect user of a target event.

[0172] According to another embodiment, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed in a computer, causes the computer to perform a combination Figure 3 The method described.

[0173] According to another embodiment, a computing device is also provided, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements a combination... Figure 3 The method described.

[0174] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device or medium embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0175] The steps of the methods or algorithms described in conjunction with the disclosure in this specification can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in RAM, flash memory, ROM, EPROM, EEPROM, registers, hard disk, external hard disk, CD-ROM, or any other form of storage medium well known in the art. An exemplary storage medium is coupled to the processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Alternatively, the ASIC can reside in a server. Of course, the processor and storage medium can also exist as discrete components in the server.

[0176] Those skilled in the art will recognize that, in one or more of the examples above, the functions described in this invention can be implemented using hardware, software, firmware, or any combination thereof. When implemented in software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transfer of a computer program from one place to another. Storage media can be any available medium accessible to a general-purpose or special-purpose computer.

[0177] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0178] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of this specification. It should be understood that the above description is only a specific embodiment of this specification and is not intended to limit the scope of protection of this specification. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of this specification should be included within the scope of protection of this specification.

Claims

1. A method for determining a suspect user of a target event, comprising: obtaining a plurality of result tables, which are obtained by querying different user behavior log tables related to the target event; for any first result table, determining a field summary of each first field according to a field value of the first field, respectively; inputting the first fields and the field summaries into a first large model to extract a plurality of key fields from the first fields to form a first compressed table; the plurality of key fields include an identity information field and a behavior information field; reading each first data row from the first compressed table according to a target field value of the identity information field to form a first sub-table of a target user identified by the target field value; generating behavior chain information of the target user based on a plurality of sub-tables of the target user corresponding to the plurality of result tables by using a second large model; determining a suspect user from a plurality of users according to the behavior chain information of the plurality of users.

2. The method of claim 1, wherein, the plurality of result tables further include a second result table; a second sub-table of the target user corresponding to the second result table is obtained by: querying an identity information data table according to the target field value and a first information category to which the target field value belongs to obtain a second field value of an identity information field of a second information category; the identity information data table includes a plurality of identity information fields corresponding to different information categories; the second information category is an information category to which an identity information field in the second result table belongs; determining the second sub-table from a plurality of sub-tables corresponding to a second compressed table of the second result table according to the second field value.

3. The method of claim 2, wherein, the identity information data table is obtained by: taking the plurality of result tables as target result tables in sequence, traversing each field value of an identity information field in the target result table, and calling an identity information query interface based on a current field value to obtain a plurality of identity information corresponding to different information categories of a current user identified by the current field value; constructing the identity information data table based on each identity information of a plurality of users in the plurality of result tables.

4. The method of claim 3, wherein, the identity information field in the target result table is identified by: obtaining field information of each target field in the target result table; inputting the field information of each target field and information categories and features of a plurality of user identities into a third large model to determine a target field having a feature of any target information category as the identity information field from the each target field.

5. The method of claim 4, wherein, the field information of a single target field includes one or more of the following: a field name, a field explanation, and a field value. 6.The method of claim 1, further comprising: performing compression processing on the first sub-table to obtain a first target table. The compression processing comprises, for any first cell, if a content length of the first cell is greater than a preset length, dividing the content of the first cell into a plurality of blocks according to the preset length; using a fourth large model to generate a corresponding block summary for each block; and summarizing the block summaries to obtain a target summary; The content of the first cell is replaced by the target summary; The generation of the behavior chain information of the target user comprises: Based on a plurality of target tables corresponding to the plurality of sub-tables, the behavior chain information of the target user is generated.

7. The method of claim 1, wherein, The plurality of key fields further comprise a time field; The generation of the behavior chain information of the target user comprises: The target prompt word is input into the second large model, and the target prompt word is used to instruct the second large model to locate a plurality of target behaviors and execution times thereof related to the target event from the plurality of sub-tables; Based on the plurality of target behaviors and execution times thereof, the behavior chain information of the target user is generated.

8. The method of claim 7, wherein, The determination of the suspicious user from the plurality of users comprises: The behavior chain information of the plurality of users is input into a fifth large model, and the fifth large model is instructed to score the behavior risk of the plurality of users from a plurality of dimensions, and the suspicious user is determined from the plurality of users according to the score; wherein the plurality of dimensions at least comprise time and behavior type.

9. The method of claim 1, wherein, The target event is a file external sending event.

10. The method of claim 9, wherein, The obtaining of the plurality of result tables comprises: An event description of the target event is input into a sixth large model, and the sixth large model is instructed to determine a plurality of file propagation paths based on the event description, and to generate a corresponding traceability thought text for each file propagation path; a single traceability thought text at least indicates a corresponding user behavior log table; A corresponding structured query statement is generated for each traceability thought text; The plurality of result tables are obtained by executing the structured query statements.

11. The method of claim 1, wherein, The input of the first large model further comprises one or more of the following: The field name and field interpretation of each first field; The traceability thought text corresponding to the first result table; The structured query statement corresponding to the first result table.

12. The method of claim 1, wherein, The different types of user behavior log tables comprise one or more of the following: A terminal operation log table, an external sending log table of a mail service, and an external sending log table of an instant messaging tool.

13. An apparatus for determining a suspicious user of a target event, comprising: an obtaining unit configured to obtain a plurality of result tables, the plurality of result tables being obtained by querying different types of user behavior log tables related to a target event; a determining unit configured to determine, for any first result table, a field summary of each first field according to a field value of the first field; an input unit configured to input the first field and the field summary of the first field into a first large model, and instruct the first large model to extract a plurality of key fields from the first field to form a first compressed table; The plurality of key fields comprise an identity information field and a behavior information field for identifying a user. A reading unit is configured to read each first data row from the first compressed table according to a target field value of the identity information field, to form a first sub-table of a target user identified by the target field value; A generating unit is configured to generate behavior chain information of the target user by using a second large model and based on multiple sub-tables of the target user corresponding to the multiple result tables. The determining unit is further configured to determine a suspect user from the multiple users according to the behavior chain information of the multiple users in the multiple result tables.

14. A computer readable storage medium having stored thereon a computer program, wherein, When the computer program is executed in the computer, the computer is caused to perform the method of any one of claims 1-12.

15. A computing device comprising a memory and a processor, wherein, The memory stores executable code, and the processor executes the executable code to implement the method of any one of claims 1-12. The memory stores executable code, and the processor executes the executable code to implement the method of any one of claims 1-12.

Images