Backfilling and report generation verification method and system for security operation task results

Abstract

This application provides a method and system for backfilling and generating verification reports for security operation task results. The method may include: extracting placeholders from a report template component tree associated with a security event, and generating placeholder mapping data using the task result and structured execution summary of the security event as the placeholder mapping data data source; verifying the placeholder mapping data according to the component type of the component to which each placeholder belongs to obtain verification results; generating degradation meta-information based on the verification results; triggering the completion of fill values ​​in the placeholder mapping data based on the degradation meta-information when the degradation meta-information includes degradation items; filling the report template component tree with the successfully verified fill values ​​when all placeholder mapping data are successfully verified, thus obtaining a report; and filling the report template component tree with default values ​​for the placeholders corresponding to the degradation items when the number of completion rounds reaches the upper limit and degradation items still exist, and generating a report containing anomaly markers for the placeholders corresponding to the degradation items.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method and system for backfilling and generating and verifying the results of security operation tasks. Background Technology

[0002] In handling security incidents or conducting threat hunting investigations, the Security Operations Center typically needs to utilize various tools to perform actions such as log retrieval, alarm querying, asset confirmation, and load analysis. The results of these tools are processed to form task results and execution summaries, which are stored in the task context of the security incident. Simultaneously, security operations reports are generated based on report templates. These templates consist of various components such as charts, tables, statistical indicators, and text, organized in a nested manner. Each component is populated with corresponding content during the report generation phase using preset placeholders.

[0003] When using task results and execution summaries from the task context as the data source for placeholders in the report template, the processing methods of related technologies present challenges. The report template is filled with content based on template variable parsing and data retrieval configurations, but different components have different requirements for the data structure of the placeholder values. When the fill values ​​are generated intelligently or through task aggregation, they are prone to inconsistencies with the data structure required by the components, and these inconsistencies often only become apparent during the report rendering stage, causing rendering failures. Furthermore, when some placeholder data is temporarily unavailable due to tool execution failures, no query results, or multiple rounds of tasks not yet completed, the report generation chain is easily blocked by a single point of failure.

[0004] As a result, the execution results scattered in the task context and execution summary are difficult to be stably and accurately filled into the report template, and the data structure validation of the filling values ​​is not completed according to the component type before the report is rendered, which ultimately leads to the report not being generated stably or accurately. Summary of the Invention

[0005] According to a first aspect of the embodiments of this application, a method for backfilling and report generation verification of security operation task results is provided, the method comprising: In response to a security incident report generation request, placeholders are extracted from the report template component tree associated with the security incident, and placeholder mapping data is generated using the task result and structured execution summary of the security incident as the data source. The placeholder mapping data includes the mapping relationship between placeholders and fill values. Based on the component type of the component to which each placeholder belongs, the placeholder mapping data is validated to obtain the validation result; Based on the verification result, degradation meta-information is generated. In the case of a verification failure, the padding value of the corresponding placeholder is set to a default value corresponding to the component type of the failed placeholder. The degradation meta-information includes degradation items; each degradation item includes at least one of illegal items and missing items. An illegal item indicates that the padding value of the corresponding placeholder mapping in the placeholder mapping data is illegal, and a missing item indicates that the padding value of the corresponding placeholder mapping in the placeholder mapping data is missing. When the degradation meta information includes the degradation item, the padding value in the placeholder mapping data is triggered based on the degradation meta information. The padding value of the placeholder corresponding to the degradation item is regenerated and the verification of the placeholder mapping data is re-executed until all the placeholder mapping data are successfully verified or the number of padding times reaches the round limit. If all the placeholder mapping data are successfully verified, the report template component tree is filled with the fill value of the successfully verified placeholder mapping data to obtain the report of the security event; if the number of completions reaches the upper limit of the round and the degradation item still exists, the report template component tree is filled with the default value for the placeholder corresponding to the degradation item, and a report of the security event containing the exception marker is generated.

[0006] According to a second aspect of the embodiments of this application, a system for backfilling and generating verification of results of security operation tasks is provided, the system comprising: The filling module is used to respond to a security event report generation request, extract placeholders from the report template component tree associated with the security event, and generate placeholder mapping data using the task result and structured execution summary of the security event as the data source. The placeholder mapping data includes the mapping relationship between placeholders and filling values. The verification module is used to verify the placeholder mapping data according to the component type of the component to which each placeholder belongs in order to obtain the verification result; A generation module is used to generate degradation metadata based on the verification result. In the case of a verification failure, the padding value of the corresponding placeholder is set to a default value corresponding to the component type of the failed placeholder. The degradation metadata includes degradation items; each degradation item includes at least one of illegal items and missing items. An illegal item indicates that the padding value of the corresponding placeholder mapping in the placeholder mapping data is illegal, and a missing item indicates that the padding value of the corresponding placeholder mapping in the placeholder mapping data is missing. The completion module is used to trigger the completion of the fill value in the placeholder mapping data based on the degradation meta information when the degradation meta information includes the degradation item, regenerate the fill value of the placeholder corresponding to the degradation item and re-execute the verification of the placeholder mapping data until all the placeholder mapping data are successfully verified or the number of completions reaches the round limit. The reporting module is used to fill the report template component tree with the fill value of the successfully verified placeholder mapping data when all the placeholder mapping data are successfully verified, so as to obtain a report of the security event; when the number of completions reaches the upper limit of the round and the degradation item still exists, the report template component tree is filled with the default value for the placeholder corresponding to the degradation item, and a report of the security event containing the exception marker is generated.

[0007] According to a third aspect of the embodiments of this application, an electronic device is provided, the electronic device including a processor and a memory; The memory is used to store computer-executable instructions; The processor is used to execute the computer-executable instructions; When the computer-executable instructions are executed by the processor, the aforementioned method for backfilling and generating verification of results for security operation tasks is implemented.

[0008] According to a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided, the computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, can realize the aforementioned method for backfilling and generating verification of results for security operation tasks.

[0009] The technical solutions provided by the embodiments of this application may include the following beneficial effects: This application uses the task results and structured execution summaries of security events as placeholder mapping data sources. During the report generation stage, placeholders are first extracted from the report template component tree, and then their fill values ​​are validated according to the component type of each placeholder. Since components such as charts, tables, statistics, and text have different data structure requirements for fill values, validation is applied separately for each component type. This allows invalid or missing fill values ​​to be identified before report rendering, eliminating the need to wait until the report rendering stage to expose these problems and thus preventing rendering failures caused by these issues.

[0010] For identified verification failures, default values ​​are generated according to their component type and recorded with degradation metadata. Report generation continues based on these default values, ensuring the report generation process is not interrupted by verification failures. Furthermore, degradation metadata drives the completion of fill values. In each round, fill values ​​are regenerated only for degradation items, and the same data structure verification is re-executed until all placeholders pass verification or the round completion count reaches the round limit. Fill values ​​are then used to complete the process with successfully verified fill values. In this way, results scattered across the task context and execution summary are stably mapped to corresponding placeholders in the multi-component report template. Component-level data structure verification, degradation recording, and round-by-round completion are completed before rendering, ensuring that security operation reports can still be stably generated even with missing or invalid data.

[0011] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0012] The accompanying drawings, which are incorporated in and form part of this application, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0013] Figure 1 This is a flowchart illustrating a method for backfilling and generating verification of results for security operation tasks, according to an exemplary embodiment of this application.

[0014] Figure 2 This is a schematic diagram of the structure of a report template component tree and a schematic diagram of the recursive extraction process of placeholders, according to an exemplary embodiment of this application.

[0015] Figure 3 This is a schematic diagram illustrating placeholder protocol verification rules for different component types according to an exemplary embodiment of this application.

[0016] Figure 4 This is a schematic diagram illustrating a complete link from command creation to report generation according to an exemplary embodiment of this application.

[0017] Figure 5 This is a schematic diagram illustrating the relationship between a command object, an execution object, a task object, and an event object, as well as the state transition after the summary is completed, according to an exemplary embodiment of this application.

[0018] Figure 6 This is a schematic diagram of a multi-round completion closed-loop process based on downgraded metadata, according to an exemplary embodiment of this application.

[0019] Figure 7 This is a structural block diagram of a system for backfilling and generating verification of results for security operation tasks, as illustrated in an exemplary embodiment of this application.

[0020] Figure 8 This is a structural block diagram of an electronic device according to an exemplary embodiment of this application. Detailed Implementation

[0021] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0022] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0023] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0024] To better explain or illustrate the embodiments of this application, the following terms are used for clarification: Command object: A unified abstraction and encapsulation of an action to be executed, generated by an event-level handler or task-level handler. A command object can record command type, tool identifier, tool parameters, command target, command description, and / or command status. Command objects can be associated with upper-level business objects through event identifiers and task identifiers.

[0025] Execution object: The record corresponding to a single command execution. An execution object must at least record the execution identifier, execution result, execution summary, structured summary, and execution status. Execution objects can be associated with command objects, event objects, and task objects through command identifiers, event identifiers, and task identifiers.

[0026] Execution Summary: This refers to the content generated after the execution result is summarized in structured or natural language, and is stored in the structured summary field of the executed object. The summary uses different generation paths depending on the command type. Structured query results use the direct structured summary path, while execution results from general execution tools use the summary request path based on the operator-role-based agent.

[0027] The report template component tree refers to the tree-like structure within a safety operations report template, composed of various types of components organized in a nested manner. Component types must include at least a cover page, text, charts, tables, statistics, images, separators, mixed content sections, and / or main chapters. Different component types have different specifications for the data structure of placeholder fill values. The report template component tree can be simply referred to as the template component tree.

[0028] Placeholder value validation, also known as placeholder protocol validation, refers to the process of checking the data type, structure, and completeness of placeholder values ​​before report rendering, based on the component type and data specifications to which the placeholder belongs. Validation rules vary depending on the component type: statistical placeholders require numerical values, chart placeholders require a structured collection of records containing specific fields, table placeholders require a collection of row records aligned with column definitions, and text placeholders require single-value data.

[0029] Degradation metadata: Structured validation results recorded after protocol validation (hereinafter referred to as validation) of the report template placeholders. Degradation metadata includes at least: total number of placeholders, number of placeholders filled, list of missing items, list of illegal items and error descriptions, data source identifier and / or whether a degradation flag exists.

[0030] Total number of placeholders: The total number of all placeholders in the current report template component tree that are to be filled with values ​​(including all types of placeholders such as text, numbers, tables, and charts), used for overall validation statistics.

[0031] Populated Quantity: The total number of placeholders with populated values ​​that have been bound to the data source in this round of validation.

[0032] Missing item list: A set of placeholders for which no valid data source could be found and no available values ​​were available to fill in.

[0033] Information content: typically includes a unique placeholder identifier, component type, and / or location information, etc.

[0034] List of illegal items: A set of placeholders for which there are fill values, but the data structure, format, or field structure does not meet the requirements of the corresponding template component type; Error Description: A description of the error corresponding to the validation failure. For example, the error description may include the specific reason for the validation failure, such as: the fill value of the numeric placeholder is a text string, the number of columns in the table field does not match, the time field in the chart has an incorrect format, or the field type does not match.

[0035] Data source identifiers are used to mark the data source for the current placeholder data. For example, which execution record, which structured summary, or which round of task context / task result, facilitating the tracing of the original data source and precise targeted query completion.

[0036] The degradation flag, which can be a Boolean flag, is used to indicate whether the degradation metadata contains degradation items.

[0037] A downgrade flag value of true indicates that there are missing or invalid items in this round. Missing items mean that the filler value with placeholders is missing, and invalid items mean that the validation with placeholders failed.

[0038] A downgrade flag value of false indicates that all placeholders have been successfully verified, there are no downgraded items, no additional completion is required, and a normal report can be generated directly.

[0039] The embodiments of this application will now be described in detail.

[0040] Figure 1 This is a flowchart illustrating an exemplary embodiment of a method for backfilling and generating verification of security operation task results, according to this application. The entity executing this method may include a system for backfilling and generating verification of security operation task results (hereinafter referred to as the system). This system may run on one or more electronic devices. The electronic device may be a processor and / or a client.

[0041] like Figure 1 As shown, the method includes the following steps: Step 101: In response to the security event report generation request, extract placeholders from the report template component tree associated with the security event, and generate placeholder mapping data using the task result and structured execution summary of the security event as the data source. The placeholder mapping data includes the mapping relationship between placeholders and fill values.

[0042] In some embodiments, during the handling of security incidents or the conduct of threat hunting investigations, the security operations center typically needs to invoke various tools to perform actions such as log retrieval, alarm querying, asset confirmation, and load analysis. The execution results of these tools are processed to form task results and execution summaries, which are stored in the task context of the security incident. When a security operations incident triggers the report generation process, the system reads the report template component tree associated with the incident.

[0043] In some embodiments, such as Figure 2As shown, the report template component tree is composed of multiple template components organized in a nested manner. Component types include at least one or more of the following: cover type, text type, chart type, table type, statistical type, image type, separator type, mixed content section type, and main chapter type. Each component has a unified basic structure, including component identifier, component type, component title, and component configuration fields.

[0044] In some embodiments, the process of extracting placeholders from the report template component tree may include: Receive an array of template components; Iterate through each template component and read its type. If the component type is text, extract all placeholder identifiers from the content field of the component configuration using regular expression matching; If the component type is a chart, iterate through the chart array in the component configuration and extract the placeholder identifier from the placeholder field of each chart element; If the component type is a table, extract the placeholder identifier from the placeholder field configured in the component. If the component type is statistical, iterate through the array of statistical items in the component configuration and extract the placeholder identifier from the placeholder field of each statistical item. If the component type is a chapter type or a main chapter type, recursively process its sub-item array or sub-chapter array, extract placeholders in nested components, and return a deduplicated set of placeholder identifiers.

[0045] The system receives all previous task results and execution summaries as data sources, and generates placeholder mapping data based on the task results and report template component tree. The placeholder mapping data includes the mapping relationship between placeholders and fill values. In some embodiments, the placeholder mapping data may also include data structure validation information.

[0046] Step 102: Based on the component type of the component to which each placeholder belongs, verify the placeholder mapping data to obtain the verification result.

[0047] In some embodiments, the validation of placeholder mapping data may include: validating whether each placeholder maps to a fill value in the placeholder mapping data, and / or validating the data structure of the fill value corresponding to the placeholder that has a fill value. Specifically, for each extracted placeholder identifier, it is matched component by component in the template component tree to determine the component type to which the placeholder belongs. If the component type includes one or more subtypes, it is also necessary to determine its subtypes based on the template component tree.

[0048] In some embodiments, for placeholders of statistical type, the validation requires the fill value to be a numeric type.

[0049] In some embodiments, for placeholders that are chart types, the fill value must be a set of structured records, and each element in the set must be a structured record.

[0050] In some embodiments, for placeholders that are of table type, the fill value must be a set of row records, and the row record field should be aligned with the column definition field.

[0051] In some embodiments, for placeholders that are text types, the fill value should be a single value, and collections or objects are not accepted.

[0052] The verification results are divided into three types: verification successful (or verification failed), verification failed, and missing fill value.

[0053] In some embodiments, step 102 may include: for each extracted placeholder identifier, matching component by component in the template component tree to determine the component type to which the placeholder belongs, performing a validation of the fill value according to the component type, and generating a validation result, wherein the validation result is validation success, validation failure, or fill value missing.

[0054] In some embodiments, for each extracted placeholder identifier, the component type to which the placeholder belongs is determined by matching each component in the template component tree, which may include, but is not limited to, at least one of the following: When the component to which the placeholder belongs is of the statistical type, the system checks whether the fill value of the statistical type placeholder is a numeric value. For example, for placeholders of the statistical type, the validation requires the fill value to be a numeric type (integer or floating-point number). If the validation succeeds, the fill value remains unchanged; if the validation fails, an invalid item is recorded.

[0055] When the placeholder belongs to a chart type component, the validation rules are as follows: the fill value of the chart type placeholder must be a structured record set, and each element in the structured record set must be a structured record that conforms to the chart type data specifications. For example, for a chart type placeholder, the validation rules are as follows: the fill value must be a structured record set; each element in the set must be a structured record.

[0056] When the component to which the placeholder belongs is a table type, the validation rules are as follows: the fill value of the table type placeholder must be a collection of row records, and the fields of each row record in the collection must be aligned with the column definitions configured for the table type component. For example, for a placeholder belonging to a table type, the validation rules are as follows: the fill value must be a collection of row records; each element in the collection must be a row record; and the row record fields should be aligned with the column definition fields.

[0057] When the component to which the placeholder belongs is of type text, validate whether the fill value of the text placeholder is a single-value data. For example, for placeholders of type text, the validation rules are as follows: the fill value should be single-value data (text value, number, or logical value), and collections or objects are not accepted.

[0058] In some embodiments, when the component type to which the placeholder belongs is a chart type, verifying whether the fill value of the chart type placeholder is a structured record set includes: performing one of the following verifications according to the chart subtype of the chart type: When the chart subtype is a line chart or an area chart, validate whether the structured record contains a time field and a value field. For example, a line chart is used to show the trend of data changing over time, and an area chart is used to show the cumulative change of data over time; both require each record to contain a time field and a corresponding value field.

[0059] When the chart subtype is a bar chart, validate whether the structured record contains a category field and a value field. For example, a bar chart is used to display numerical comparisons between different categories, requiring each record to contain a category field and a corresponding value field.

[0060] When the chart subtype is a pie chart, validate whether the structured record contains a name field and a value field. For example, a pie chart is used to show the proportion of each category in the whole, requiring each record to contain a name (or category) field and a corresponding value field.

[0061] When the chart subtype is a scatter plot, validate whether the structured records contain x-axis and y-axis values. For example, a scatter plot is used to show the relationship between two variables, requiring each record to contain x-axis and y-axis values.

[0062] In this embodiment, by further verifying whether the structured record contains the necessary fields for the corresponding subtype of chart, such as line chart, bar chart, pie chart, area chart, and scatter plot, the chart type placeholders are further validated. This makes the chart data validation more refined and accurate, and enables adaptability validation for the data structure requirements of different chart types, further improving the data legality assurance capability before report rendering.

[0063] During the validation process, if a placeholder value is missing, the validation result will indicate that the placeholder value is missing. If the validation process finds that the data type or data structure of a placeholder value is not the data type or data structure specified for the corresponding component type, the validation result will indicate that the validation has failed. For example, if the validation process finds that a placeholder value has not undergone integrity verification, indicating that the placeholder value may have been tampered with, the validation result will also indicate that the validation has failed.

[0064] Figure 3The diagram shown illustrates the placeholder protocol validation rules for different component types. Figure 3 The documentation displays the population value requirements, validation rules, default values, and degradation metadata records for different component types. Validation fails when the population value for a given component type does not meet the population value requirements and / or fails validation based on its corresponding validation rules.

[0065] In this embodiment, by performing differential protocol validation on the placeholder fill values ​​according to component types such as charts, tables, statistics, and text, problems such as mismatch between fill values ​​and component data structures can be detected before report rendering (e.g., chart data lacking necessary fields, statistical placeholders being incorrectly filled with text values, table row records not matching column definitions, etc.). This advances the discovery of data structure problems from the rendering stage to the validation stage, reducing the risk of report rendering failure and lowering the cost of manual investigation and repair due to rendering failure.

[0066] Step 103: Generate downgrade metadata based on the verification results.

[0067] In some embodiments, when the validation result is a validation failure, the padding value of the corresponding placeholder is set to the default value corresponding to the component type to which the validation failed placeholder belongs, and the degradation metadata includes degradation items; degradation items include at least one of illegal items and missing items; illegal items indicate that the padding value of the corresponding placeholder mapping in the placeholder mapping data is illegal, and missing items indicate that the padding value of the corresponding placeholder mapping in the placeholder mapping data is missing. The padding value of the placeholder to which the corresponding component type belongs can be found in [reference]. Figure 3 The default values ​​are shown below.

[0068] In some embodiments, when the system detects a missing or invalid padding value during verification, it generates a default value and records degradation metadata. Reasons for invalid padding values ​​may include, but are not limited to, at least one of the following: incorrect data type of the padding value, incorrect data structure of the padding value, or the padding value failing integrity verification.

[0069] In some embodiments, the padding value corresponding to the placeholder that failed validation is set to a default value corresponding to the component type to which the placeholder belongs, including at least one of the following: When the component type of the placeholder that fails validation is statistical, the corresponding default value is empty or a preset value. When the placeholder that fails validation belongs to a chart or table type component, the corresponding default value is an empty collection. When the component type of the placeholder that fails validation is text, the corresponding default value is the preset placeholder text.

[0070] In some embodiments, for statistical type placeholders that fail validation, an empty value or a preset default value is generated; for chart type placeholders, an empty set of default values ​​is generated; for table type placeholders, an empty set of default values ​​is generated; for text type placeholders, a default value "to be supplemented" is generated; for placeholders with invalid fill values, they are recorded as invalid items in the downgrade metadata, and the invalid item entry may contain a placeholder identifier and a specific validation error description.

[0071] In some embodiments, for cases where a placeholder does not exist in the placeholder mapping data and requires a fill value (i.e., the fill value is missing), it is recorded as a missing item in the downgrade metadata. The missing item entry containing this missing item may include a placeholder identifier.

[0072] In some embodiments, the degradation metadata includes at least: the total number of placeholders, the number of filled placeholders, a list of missing placeholders, a list of invalid placeholders and error descriptions, a data source identifier, and whether a degradation flag exists. For example, the generation of degradation metadata can refer to... Figure 3 .

[0073] Step 104: When the downgraded meta information includes downgraded items, the padding value in the placeholder mapping data is triggered based on the downgraded meta information. The padding value of the placeholder corresponding to the downgraded item is regenerated and the validation of the placeholder mapping data is re-executed until all placeholder mapping data are successfully validated or the padding count reaches the round limit.

[0074] In some embodiments, when the degradation metadata contains degradation items, the system checks the status of the report generation task in the current event round. If the report has not yet been validly generated and there is no ongoing report generation task, a new report generation task is automatically created and sent to the task processing queue, with the event round identifier incremented. Based on the degradation metadata of the previous round (including a list of missing items containing one or more missing items and a list of illegal items containing one or more illegal items), the system reorganizes the data query instructions for the placeholders corresponding to the missing and illegal items and dispatches them to the corresponding expert assistants for supplementary queries. After the supplementary queries are completed, the system regenerates the placeholder mapping data and re-executes the protocol verification. The system can set a maximum round limit. When the number of rounds for filling values ​​reaches the round limit, the system ends the value filling process and records the incomplete status.

[0075] Step 105: If all placeholder mapping data are successfully verified, fill the report template component tree with the fill value of the successfully verified placeholder mapping data to obtain a security event report; if the number of completion attempts reaches the round limit and there are still downgraded items, fill the report template component tree with the default value for the placeholders corresponding to the downgraded items, and generate a security event report containing anomaly markers.

[0076] For example, before the end of the multi-round completion process, the system retains the original report template component tree and the placeholder identifiers corresponding to the downgrade items. In order to generate intermediate preview results, the system can write default values ​​into a temporary copy of the report template component tree, but the temporary copy does not cover the original report template component tree and the placeholder mapping data used in the next round of completion.

[0077] If the report has not yet been generated, i.e. the template rendering result associated with the event is empty or does not exist, or the corresponding degradation item still exists in the degradation meta information, and there is no report generation task in progress, then a new report generation task will be automatically created and sent to the task processing queue.

[0078] When the system reports that all placeholders have been filled according to the protocol (i.e., there are no degradation items in the degradation metadata), the rendered template data is written to the report result field of the event object, and the event completion processing flow is triggered. When the number of completion rounds exceeds the upper limit, the system ends the completion process and records the incomplete status, fills the report template component tree with the default value, and generates a report containing an exception marker for the security event.

[0079] In this embodiment, by using the task results and structured execution summaries of security events as placeholders to map the data source, placeholders in the report template component tree are extracted first during the report generation stage. Then, the corresponding data structure validation is performed on the fill values ​​of each placeholder according to the component type of the component to which it belongs. This allows inconsistencies between fill values ​​and component data structures to be identified before report rendering, rather than waiting until the report rendering stage to expose these problems, thereby eliminating the risk of rendering failure caused by mismatch between fill values ​​and component data structures. At the same time, through the degradation metadata recording and default value degradation mechanism, the report generation process will not be completely interrupted due to the temporary unavailability or invalid format of individual placeholder data. Through the fill value completion mechanism, the system can automatically trigger data query and re-validation when the report is not generated or the placeholders are not completed, forming a fault-tolerant closed loop from the data source to report generation.

[0080] In some embodiments, the padding value corresponding to the placeholder that failed validation is set to a default value corresponding to the component type to which the placeholder belongs, including at least one of the following: When the placeholder for a failed validation belongs to a statistical type component, the corresponding default value is null or a preset value. For example, statistical type placeholders require numerical values, and when validation fails, they can be set to null or a preset value (e.g., 0) to ensure the integrity of the report structure.

[0081] When the placeholder that fails validation belongs to a chart or table type component, the corresponding default value is an empty collection. Chart and table type placeholders require a record collection; when validation fails, it is set to an empty collection, causing the chart or table area to display as blank or in a "no data" state.

[0082] When a placeholder that fails validation belongs to a text component, its default value is the preset placeholder text. Text placeholders require single-value data. When validation fails, they are set to the preset placeholder text (e.g., "To be supplemented") to prompt the user that the content needs manual confirmation or supplementation.

[0083] When the degradation metadata includes degradation items, the padding values ​​in the placeholder mapping data are completed based on the degradation metadata. The padding values ​​for the placeholders corresponding to the degradation items are regenerated, and the validation of the placeholder mapping data is re-executed until all placeholder mapping data are successfully validated or the number of completions reaches the round limit, including: When the degradation metadata contains degradation items, a report generation task is created and the event round identifier is incremented based on the completion round. A data query task is dispatched based on the placeholders that failed the validation to regenerate the corresponding placeholder fill values, and then the data structure validation is re-executed. When the event round identifier exceeds the round limit, the completion process ends.

[0084] Upon receiving feedback, the system checks the status of the report generation task in the current event round. If the report has not yet been generated and there is no ongoing report generation task, a new report generation task is automatically created and added to the task processing queue. The event round identifier is incremented when a new report generation task is created. The system can set a maximum round limit (e.g., no more than 6 or 7 rounds). When the round limit is reached, the system terminates the value completion process and records the incomplete status.

[0085] In this embodiment, by generating default values ​​for placeholders that fail validation according to component type and recording structured degradation metadata including placeholder identifiers, error descriptions, missing item lists, and illegal item lists, the report generation process is prevented from being completely interrupted due to the temporary unavailability of individual placeholder data, thus improving the fault tolerance of the report generation chain. When degradation items exist, the system automatically creates a report generation task and triggers multiple rounds of data queries and placeholder completion. Protocol validation is re-executed in each round until all placeholders pass validation or the round limit is reached, thus automating placeholder data completion and reducing the intervention cost of manual checking and completion. At the same time, the missing item list, illegal item list, and error description in the degradation metadata provide a traceable basis for subsequent auditing and problem localization.

[0086] In some embodiments, during execution Figure 1Before proceeding with the steps shown, it is necessary to obtain the task result, which is obtained in the following way: An execution log is generated based on the execution results of various heterogeneous tools; the execution log includes at least the execution results. Generate an execution summary of the execution record, populate the execution summary into the task context associated with the execution record, and mark the summary status of the execution record as summary completion status; Once all execution records in the same task round have reached the summary completion state, the task context is written to the task result.

[0087] In some embodiments, the system reads the command identifier to be processed from the operation execution queue, queries the corresponding command object, and reads the command type field.

[0088] In some embodiments, an execution record is generated based on the execution results of multiple heterogeneous tools, including: The action to be executed is encapsulated as a command object. The command object contains a command type field for recording the execution path. The command type includes at least two of the following: script execution type, agent invocation type, tool invocation type, manual processing type, load analysis type, security log query type, and relational data query type. Based on the execution path recorded in the command type field, the command object is routed to the corresponding execution tool among various heterogeneous tools; Based on the execution results of the execution tool, create an execution object associated with the command object and record the execution results in the execution object.

[0089] For example, the command type field of a command object is a key field for command routing. The system writes the command type when creating a command object, and subsequently dispatches the command to the corresponding execution path based on this field. Therefore, event-level handlers and task-level handlers do not need to be aware of the specific invocation method of the underlying tool; they only need to specify the command type and related parameters.

[0090] In some embodiments, the system reads the command identifier to be processed from the operation execution queue, queries the corresponding command object, and reads the command type field. Based on the command type, the system distributes the command to the corresponding execution path, including but not limited to at least one of the following: script execution types and agent invocation types are processed through the script execution path; tool invocation types are processed through the tool service path; manual processing types create execution objects in a waiting state, waiting for the user to complete the operation; load analysis types create execution objects in a completed state and perform load analysis through an intelligent analysis request; security log query types perform structured queries through a log query client; relational data query types perform structured queries through a database client.

[0091] In some embodiments, after the execution tasks of each execution path of the system are completed, the system creates an execution object and records the execution identifier, command identifier, event identifier, task identifier, task round identifier, execution result and / or execution status.

[0092] For example, for manual processing types, the system sets the execution status to "waiting"; and / or, for load analysis, security log query, and relational data query types, the system automatically sends the execution identifier to the summary request message of the operation execution queue after the execution record is created, triggering the execution summary generation process; and / or, for types such as script execution and tool invocation, the execution result can be structured data containing status, result, and message fields, and the system serializes the execution result and writes it to the execution result field of the execution object.

[0093] In this embodiment, heterogeneous tool calls such as script execution, tool invocation, manual processing, load analysis, security log querying, and relational data querying are uniformly encapsulated through command objects. The command type field determines the routing execution path, allowing event-level and task-level processors to be unaware of the specific calling methods of the underlying tools, only needing to specify the command type and related parameters, thus reducing the coupling between system modules. The execution object uniformly records execution results and execution status, which can be read in a unified manner for subsequent task processing and event-level decisions, improving the system's scalability and maintainability.

[0094] In some embodiments, based on the execution path recorded in the command type field, the command object is routed to the corresponding execution tool among various heterogeneous tools, which may include, but is not limited to, at least one of the following: Script execution type and agent invocation type are handled through the script execution path; Tool call types are handled through the tool service path; Manual processing creates execution objects in a waiting state; The load analysis type creates an execution object in a completed state and performs load analysis via an intelligent analysis request; Security log query types execute structured queries through the log query client; Relational data query types execute structured queries through database clients.

[0095] In some embodiments, after the tasks corresponding to each execution path are completed, the system creates an execution object and records the execution identifier, command identifier, event identifier, task identifier, task round identifier, execution result and / or execution status.

[0096] In some embodiments, the execution summary generation process includes: the system reading the execution identifier to be summarized from the operation execution queue, querying the corresponding execution object and its associated command object. The system reads the command type field of the command object to determine the summary path of the execution result.

[0097] In some embodiments, for the execution results of a structured query class, the return status and return result are extracted from the execution results, and an execution summary is generated according to a preset template based on the return status and return result.

[0098] In some embodiments, for the execution results of unstructured query classes, a preset agent is invoked based on the execution record to obtain the summary response returned by the preset agent, and an execution summary is generated based on the summary response.

[0099] Specifically, for the execution results of structured queries, the system extracts the return status and return result from the execution results, assembles the command description, command target, and execution result into a structured summary text according to a preset template format, directly writes it into the structured summary field of the execution object, and updates the execution status to "summarized". The entire process does not trigger intelligent summary requests, reducing model call overhead.

[0100] If the command type is an unstructured query type (such as script execution, agent invocation, tool invocation, manual processing, etc.), the system calls the preset agent based on the execution record to obtain the summary response returned by the preset agent, and generates an execution summary based on the summary response.

[0101] Specifically, for unstructured query results, the system extracts the task name, return status, return result, and task objective from the execution object and command object to construct structured context information. It then queries the database for the operator role's summary generation rules, creates an operator role-specific intelligent summary request, and sends it to the summary request queue. The system updates the execution status to "Pending Summary," awaiting the intelligent summary response. After the intelligent summary response returns to the operation execution queue, the system parses the response content, removes non-result content, writes the summary to the structured summary field of the execution object, and updates the execution status to "Summarized." For load analysis types, the system constructs load analysis-specific instructions and input information containing load content, creates an operator role-specific intelligent summary request, and sends it to the summary request queue. After the response is complete, the system writes the processed summary to the structured summary field of the execution object.

[0102] If the command type is a structured query, the system uses a direct structured summary path: extracting the return status and return result from the execution result, assembling the command description, command objective, and execution result into a structured summary according to a preset template format, directly writing it into the structured summary field of the execution object, and updating the execution status to "summarized". If the command type is a script execution, agent invocation, tool invocation, or manual processing, the system uses a summary request path: extracting the task name, return status, return result, and task objective from the execution object and command object, constructing structured context information, creating an operator role intelligent summary request, and sending it to the summary request queue. After the intelligent summary response flows back to the operation execution queue, the system writes the summary into the structured summary field of the execution object and updates the execution status to "summarized".

[0103] In this embodiment, a dual-path summary processing mode is adopted. Structured query results use the direct structured summary path, generating standardized summaries without triggering intelligent summary requests, thus reducing model call overhead and processing latency. General tool execution results generate summaries through intelligent summary requests from operator roles, ensuring summary quality and consistency. Both paths ultimately write the summary to a unified field of the execution object and create a standardized summary message, enabling subsequent task processing, event-level decision-making, and report generation to read the execution summary in a unified manner, balancing processing efficiency and data quality.

[0104] In some embodiments, the process of backfilling the execution summary to the task context associated with the execution record may include: When all execution records associated with the same command object reach either a summary completion state or a failure state, the summary states of each execution record are aggregated to update the command state of the corresponding command object. Specifically, if there is at least one failed execution, the command state is updated to failure; if all executions are successful and all summaries are completed, the command state is updated to completion.

[0105] For example, when all execution records associated with the same command object have entered the final execution state, the execution states of each execution record are aggregated to update the command state of the corresponding command object; wherein, the final execution state includes a summary completion state and a failure state; if there is at least one failed execution, the command state is updated to failure; if there is no failed execution and all execution records have reached the summary completion state, the command state is updated to completion. The system checks whether all command objects in the current round have reached the command final state, which includes the completion state and the failure state. After all command objects have reached the command final state, the system resends the security event to the event processing queue or the corresponding task to the task processing queue according to the backfill branch corresponding to the current round.

[0106] When a command object reaches a failure state, it only means that the command object and its associated execution record have finished processing in the current round, and does not mean that the task objective has been achieved. After the task is re-enqueued, the task-level processor determines whether to retry, perform compensatory execution, or terminate the task based on the execution summary, failure information, and task objective.

[0107] In some embodiments, the process of backfilling the execution summary to the task context associated with the execution record may include: When a security event is a collaborative event and the command type of the command object is an agent invocation type, after the command status of each command object in the current event round associated with the security event reaches the completed state or the failed state, the security event is sent back to the event processing queue to trigger the event-level processing flow. The event-level processing flow is used to re-evaluate the overall status of the security event and / or plan the handling actions based on the execution summary of all tasks under the security event. When a security event is a non-cooperative event or the command type of a command object is not an agent invocation type, after all command states of each command object in the current task round have reached the completed or failed state, the corresponding task is re-sent to the task processing queue so that the task can determine whether the task objective has been achieved based on the execution summary. If the task objective has not been achieved, a new command object is generated and sent to the operation execution queue; if the task objective has been achieved, the task result is written and the task is terminated.

[0108] For example, when the security event is a collaborative event, and all command objects in the current event round associated with the security event are of the agent invocation type, after the command status of all command objects in the current event round reaches the completed state or the failed state, the security event is resent into the event processing queue to trigger the event-level processing flow. The event-level processing flow is used to re-evaluate the overall state of the security event and / or plan the handling action based on the execution summary of all tasks under the security event. When the security event is a non-cooperative event, or when at least one command object in the current event round associated with the security event has a command type that is not an agent invocation type, after all command states of each command object in the current task round have reached the completed or failed state, the corresponding task is re-sent to the task processing queue so that the task can determine whether the task objective has been achieved based on the execution digest; wherein, if the task objective has not been achieved, a new command object is generated and sent to the operation execution queue; if the task objective has been achieved, the task result is written and the task is terminated.

[0109] In some embodiments, the system periodically or each time the execution state changes, queries the command objects in the processing state and checks whether all execution objects under the command have reached the digested or failed state. If all execution objects under the command have reached the digested or failed state, and there is at least one failed execution, the command state is updated to failed; if all execution objects under the command have reached the digested or failed state, and there is no failed execution, the command state is updated to completed; if there are still execution objects under the command in the pending, processing, or completed (not yet digested) state, the command state remains in processing.

[0110] When the event type is a collaborative event and the command type is an agent invocation type, the system checks whether all commands and execution records under the same task round identifier have reached the digested state. If the condition that all execution records under the same command object have reached the digested state is met, the event status is updated to pending processing, and the event is re-sent to the event processing queue, triggering event-level re-decision. This path allows collaborative events to return directly to event-level processing after the command execution digest is completed, rather than going through task-level decision-making, to ensure that the digest generation of collaborative events is accurate and appropriate.

[0111] When the event type is a non-cooperative event or the command type is not an agent invocation type, the system checks whether all commands and execution records under the same task round identifier have reached the digest state. If the condition that all execution records under the same command object have reached the digest state is met, the task status is updated to task round completed, and the task is re-sent to the task processing queue, enabling the task-level processor to continue determining whether the task is completed or whether a new command needs to be generated based on the execution digest. When the task-level processor (the processor that executes the task decision) confirms the task is completed based on the execution digest, the system writes the task result, triggers subsequent tasks, or sends a task completion message to the event processing queue.

[0112] In this embodiment, by using command state aggregation and update based on the execution digest completion status and a queue backfilling trigger mechanism, the execution digest is not merely a text display, but a state machine condition capable of driving command state updates, task re-queuing, and event re-decision. Two different queue paths, event queuing and task queuing, are used for collaborative and non-collaborative events respectively. This allows collaborative events to directly return to the event level for global re-evaluation after the agent's invocation, while ordinary events progress step-by-step at the task level, improving the system's adaptability and processing efficiency for different types of security events.

[0113] In some embodiments, when the system confirms the completion of a task based on an execution summary, it writes the task result, triggers subsequent tasks, or sends a task completion message to an event processing queue.

[0114] In this embodiment, by recording execution results in the execution record and generating a structured execution summary, the execution summary is backfilled into the task context. Furthermore, after all execution records in the same task round have reached the summary completion state, the task context is written into the task result. This allows the execution results of distributed heterogeneous tools to be uniformly recorded and summarized. In the subsequent report generation stage, task results and execution summaries can be read as data sources in a unified manner, eliminating the need to adapt to the return format of each tool separately. This improves the unified encapsulation and reuse capabilities of heterogeneous tool execution results. Simultaneously, the completion state of the execution summary drives command state updates and queue re-triggering, making the execution summary not merely a text display but a state machine condition driving subsequent processing.

[0115] This application provides a method and system for backfilling and verifying the results of security operation tasks and generating reports. Instead of treating "multi-type command execution" and "report template placeholder verification" as two separate functions, this application establishes a closed loop connecting execution result backfilling to report generation: command objects and execution objects are uniformly encapsulated for heterogeneous tool calls; dual-path execution digests transform execution results into reusable structured digests and backfill them into the task context and message stream; digest completion status drives command status updates and re-triggering of task / event queues; in the report generation stage, task results and execution digests are used as placeholders mapped to data sources, and after protocol verification according to component type, default value degradation, and metadata recording, multiple rounds of completion are triggered for placeholders that fail verification or are missing; finally, report data filling is completed without changing the template structure.

[0116] The system provided in this application embodiment may include a command generation module, a command routing module, an execution record module, a dual-path execution summary module, a backfill trigger module, a report template parsing module, a placeholder extraction module, a specification reverse lookup and verification module, a downgrade metadata recording module, a multi-round completion module, a report template filling module, and a database status object.

[0117] The system's main data processing chain is as follows: the command generation module encapsulates the action information output by the event-level processor or task-level processor into a unified command object; the command routing module routes the command to the corresponding tool execution path according to the command type field; the execution record module creates an execution object for each command execution and records the execution result; the dual-path execution summary module generates a summary of the execution result and writes it to the structured summary field of the execution object; the backfill trigger module updates the command status, task status, or event status after all execution objects associated with the command have reached the summary completion or failure state, and triggers the task processing queue or event processing queue to continue processing, while writing the execution summary to the message stream.

[0118] When a security operation event triggers the report generation process, the report template parsing module reads the report template component tree associated with the event, and the placeholder extraction module recursively extracts all placeholders from the component tree. The specification reverse lookup and verification module performs type verification on the fill values ​​based on the component type and data specifications of each placeholder—the source of the fill values ​​is the task results and execution summaries generated in the previous command execution and summary backfilling. The degradation metadata recording module generates default values ​​for placeholders that fail verification or are missing and records degradation metadata. If degradation items exist, the multi-round completion module automatically creates a report generation task and re-triggers data query and placeholder completion; if all placeholders pass verification, the report template filling module fills the report based on the placeholder mapping data without changing the template structure.

[0119] Therefore, as Figure 4 As shown, the complete chain from command creation to report generation includes phase one and phase two; Phase 1 can include, in sequence: command object creation, route command object creation, execution object creation, summary backfilling, task / event status update, and task result retrieval; Phase Two may include, in sequence: obtaining execution summary, extracting placeholders, verifying component-level protocols, determining degraded items / filling in values, and filling in reports.

[0120] The output of the summary backfilling in Phase 1 serves as the data input for the subsequent report generation, forming a unified closed loop.

[0121] This application embodiment encapsulates heterogeneous tool calls in a unified manner through a command object. The command object includes at least one or more of the following fields: 1. Command ID (command_id): Used to uniquely identify a command.

[0122] 2. Event ID (event_id), used to associate with the security event to which it belongs.

[0123] 3. Task ID (task_id), used to associate the expert task that generated the command.

[0124] 4. Task round identifier (task_round_id) is used to mark which round of execution the command belongs to.

[0125] 5. Command type (command_type) determines the route for command execution.

[0126] 6. Tool ID (tool_id): Used to specify the specific tool to be invoked.

[0127] 7. Tool parameters (tool_params) are used to pass the parameters required for the tool to execute.

[0128] 8. Command description (command_describe) is used to explain the purpose of the command to the user or operator.

[0129] 9. Command target: Used to inform the operator what needs to be extracted or summarized.

[0130] 10. Command status (command_status) indicates whether a command is pending, being processed, completed, or failed.

[0131] 11. Command result (command_result) is used to record the result data after the command is executed. This result data can indicate the task result.

[0132] In some embodiments, the command type includes at least one of the following: script execution type, agent invocation type, tool invocation type, manual processing type, load analysis type, security log query type, and relational data query type. The above command types are optional implementations and do not constitute a limitation on the scope of protection of the embodiments of this application.

[0133] In some embodiments, the command type field of a command object is a key field for command routing. The system writes the command type when creating a command object, and the subsequent command routing module dispatches the command to the corresponding execution path based on this field. Therefore, event-level processors (for event-level decisions) and task-level processors (for task-level decisions) do not need to be aware of the specific invocation method of the underlying tools; they only need to specify the command type and related parameters.

[0134] In some embodiments, the command object is further associated with the upper-layer business object through an event identifier and a task identifier: the event identifier can be used to trace which security event the command belongs to, the task identifier can be used to trace which expert task generated the command, and the task round identifier can be used to determine which round of execution the command belongs to.

[0135] In some embodiments, the relationship between the command object and the event object, task object, and execution object can be found in [reference]. Figure 5 .

[0136] This application embodiment creates one or more execution objects for each command (i.e., command object) execution. The execution object includes at least one or more of the following fields: 1. Execution ID (execution_id) is used to uniquely identify an execution record.

[0137] 2. Command identifier (command_id), used to associate with the command object to which it belongs.

[0138] 3. Event ID (event_id), used to associate with the security event to which it belongs.

[0139] 4. Task ID (task_id), used to associate with the expert task to which it belongs.

[0140] 5. Task round identifier (task_round_id) is used to mark which round of the task this execution belongs to.

[0141] 6. Execution result (execution_result): This is used to save the original return results of the tool execution.

[0142] 7. Execution summary (execution_summary) is used to store a preliminary summary of the execution results.

[0143] 8. Structured Summary Field: Used to store the structured summary generated by the direct structured summary path or the smart summary request path.

[0144] 9. Execution status (execution_status) indicates whether the execution record is in a pending, processing, waiting, completed, successful, failed, summarized, or pending summary state.

[0145] In some embodiments, the execution status includes at least the following status values: pending, processing, waiting, completed / successful / failed, digested, and pending digest. "Completed / successful / failed" indicates that the execution has been completed but a digest has not yet been generated; "pending digest" indicates that a smart digest request has been submitted but a response has not yet been received; and "digested" indicates that the digest has been generated and written to the message stream.

[0146] The command routing and execution record creation process in this application embodiment may include the following steps: Step 1: The command routing module reads the command identifier to be processed from the operation execution queue, queries the corresponding command object, and reads the command type field.

[0147] Step 2: Distribute commands through the corresponding execution paths according to command type. For example, this includes, but is not limited to, at least one of the following: Script execution type and agent invocation type distribute command objects through script execution paths; tool invocation type distribute commands through tool service paths; manual processing type creates execution objects in a waiting state, waiting for the user to complete the operation; load analysis type creates execution objects in a completed state and performs load analysis through intelligent analysis requests; security log query type executes structured queries through log query clients; relational data query type executes structured queries through database clients.

[0148] Step 3: After the commands in each execution path are executed, the system creates an execution object to record the execution identifier, command identifier, event identifier, task identifier, task round identifier, execution result, and execution status.

[0149] Step 4: For manual processing types, the system sets the execution status to "waiting," indicating that it is waiting for user operation. For load analysis, security log query, and relational data query types, the system automatically sends the execution identifier to the summary request message in the operation execution queue after the execution record is created, triggering the execution summary generation process.

[0150] Step 5: For types such as script execution and tool invocation, the execution result can be structured data containing status, result, and message fields. The system serializes the execution result and writes it to the execution result field of the execution object.

[0151] In some embodiments, when creating an execution object, the system can also read the extended business object identifier from the task object or event object associated with the command object and write it into the extended association field of the execution object, so that the execution record can be further associated with the upper-level business investigation node.

[0152] The result field, summary field, and status field of the execution object, as well as its one-to-many relationship with the command object, can be found in [reference needed]. Figure 5 .

[0153] The execution summary generation in this application adopts a dual-path processing mode: for structured query execution results, a direct structured summary path is used, and for general tool execution results, an intelligent summary request path based on operator role is used.

[0154] In some embodiments, performing the digest generation process may include the following steps: The system reads the execution identifier to be digested from the operation execution queue and queries the corresponding execution object and its associated command object.

[0155] The system checks whether the events associated with the execution object have a stop flag set; if so, it does not process them for the time being.

[0156] The system reads the command type field of the command object to determine the summary path of the execution result.

[0157] If the command type is a structured query, the system adopts a direct structured summary path: extract the return status and return result from the execution result, assemble the command description, command target and execution result into a structured summary text according to the preset template format, write it directly into the structured summary field of the execution object, and update the execution status to "summarized".

[0158] If the command type is load analysis, the system adopts the load analysis summary path: construct a load analysis-specific instruction and input information containing load content, create an operator role intelligent summary request and send it to the summary request queue. After the response is completed, it flows back to the operation execution queue according to the operator role, and the execution summary processor writes the processed summary into the structured summary field of the execution object.

[0159] Command types include script execution, agent invocation, tool invocation, or manual processing, and the system adopts a summary request path: extracting task name, return status, return result, and task objective from the execution object and command object, constructing structured context information, querying the summary generation rules of the operator role from the database, creating an intelligent summary request for the operator role, and sending it to the summary request queue.

[0160] The system will update the execution status to pending digest, waiting for the intelligent digest response to be fed back.

[0161] After the intelligent summary response flows back to the operation execution queue, the execution summary processor parses the response content, removes non-result content, assembles the summary content according to the command type (for example, the load analysis type uses the "task objective and result" format, and other types use the "task name, task objective and result" format), writes the summary to the structured summary field of the execution object, and updates the execution status to "summarized".

[0162] The execution summary processor creates an execution summary message object. The summary message is associated with an event identifier, task identifier, task round identifier, and summary request identifier. The message type is execution summary, and the message content includes fields such as execution identifier, command identifier, structured summary (i.e., execution summary), command description, command type, tool identifier, tool parameters, command status, and command result.

[0163] Through the above dual-path execution, structured query results can be directly generated into structured summaries without triggering intelligent summary requests, reducing model call overhead; the execution results of general tools (general tools are non-intelligent agents) generate summaries through intelligent summary requests from operator roles, ensuring summary quality and consistency; both paths ultimately write the execution summary into a unified field of the execution object and create a standardized summary message.

[0164] In this embodiment of the application, the backfill triggering module updates the command status, task status, or event status and triggers the corresponding processing queue after all execution objects associated with the command have reached the summary completion or failure state.

[0165] In some embodiments, the state update and queue backfilling process after the summary is completed may include the following steps: The system periodically, or each time an execution status change occurs, queries the command objects in the processing state and checks whether all execution objects under the command have reached the digested or failed state.

[0166] If all executed objects under the command have reached the digested or failed state, and there is at least one failed execution, then the command state will be updated to failed.

[0167] If all executed objects under the command have reached the digested or failed state, and there are no failed executions, then the command status is updated to complete.

[0168] If there are still objects under the command that are in the pending, processing, or completed (not yet summarized) state, the command state remains in the processing state.

[0169] When the event type is a collaborative event and the command type is an agent invocation type, the system checks whether all commands and execution records under the same task round identifier have reached the digested state. If the condition is met, the event status is updated to pending processing, and the event is resent to the event processing queue, triggering event-level re-decision. This path allows collaborative events to return directly to event-level processing after the command execution digest is completed, instead of going through task-level determination.

[0170] When the event type is a non-cooperative event or the command type is not an agent invocation type (e.g., the event type is a non-cooperative event, or the command type is not an agent invocation type), the system checks whether all commands and execution records under the same task round identifier have reached the digested state. If all commands and execution records under the same task round identifier have reached the digested state, the task status is updated to task round completed, and the task is re-entered into the task processing queue, enabling the task-level processor to continue determining whether the task is completed or whether new commands need to be generated based on the execution digest.

[0171] When a task-level processor confirms task completion based on an execution digest, the system writes the task result, triggers subsequent tasks, or sends a task completion message to the event processing queue.

[0172] For execution records based on the summary request path, if the smart summary response fails (e.g., a long text exceeding the limit error is returned), the system can truncate the execution result, reset the execution status to complete, and resend it into the summary request process; if the event is in a paused state, the system will reset the execution status to complete and wait for the event to resume before re-triggering the summary.

[0173] Through the above process, the execution summary is not just a text display, but a state machine trigger condition that drives command state updates, task re-queuing, and event re-decision.

[0174] The state transitions, command state aggregation, and queue backfilling trigger relationships after the summary is completed can be found in [link to documentation]. Figure 5 .

[0175] The report template parsing module and placeholder extraction module in this application embodiment are used to recursively extract all placeholders from the template component tree during the security operation report generation stage, in preparation for subsequent protocol verification and filling.

[0176] like Figure 2 As shown, the report template component tree is composed of multiple template components organized in a nested manner. The component types include at least one or more of the following: cover type, text type, chart type, table type, statistics type, image type, separator type, mixed content section type (which may contain sub-items such as text, charts, tables, statistics, and images), and main chapter type (which may contain sub-chaps such as text, mixed content sections, and statistics).

[0177] Each component has a unified basic structure, including component identifier, component type, component title, and component configuration fields.

[0178] The component configuration of a text-type component (also known as a text component) includes a content field, which can contain one or more preset placeholder tags.

[0179] The chart type component (also known as the chart component) contains an array of charts in its component configuration. Each chart element contains a chart type field and a placeholder field. Chart types can include line charts, bar charts, pie charts, area charts, and / or scatter plots. The placeholder field uses preset placeholder markers during the editing phase and should be replaced with a structured collection of records conforming to the chart type data specifications during the rendering phase.

[0180] The component configuration of a table-type component (also known as a table component) includes an array of column definitions and table-level placeholder fields. Each element in the column definition array must contain at least a column identifier, a column header, and a row field index. The table-level placeholders should be replaced with a collection of row records during the rendering phase, and the row record fields must be aligned with the column definition fields.

[0181] The component configuration of the statistics type component (also known as the statistics component for short) contains an array of statistics items. Each statistics item must contain at least a statistics item identifier, a statistics item title, a statistics type, and a placeholder field. Statistics types may include count, sum, average, maximum, minimum, and / or percentage. Placeholders should be replaced with numeric values ​​during the rendering phase.

[0182] In some embodiments, the component type may also include a hybrid content type. The component configuration of the hybrid content type component (also referred to as the hybrid content component) contains an array of sub-items, each of which can be text, chart, table, statistics, or image type. The component configuration of the main chapter type component contains an array of sub-chapters, each of which can be text, hybrid content section, or statistics type.

[0183] The placeholder extraction module recursively extracts placeholders from the template component tree, which may include the following steps: Receives an array of template components.

[0184] Iterate through each template component and read the component type.

[0185] If the component type is text, extract all placeholder identifiers from the content field of the component configuration using regular expression matching.

[0186] If the component type is a chart, iterate through the chart array in the component configuration and extract the placeholder identifier from the placeholder field of each chart element.

[0187] If the component type is a table, extract the placeholder identifier from the placeholder field configured in the component.

[0188] If the component type is statistical, iterate through the array of statistical items in the component configuration and extract the placeholder identifier from the placeholder field of each statistical item.

[0189] If the component type is a chapter type or a main chapter type, recursively process its sub-item array or sub-chapter array, and extract the placeholders in the nested components.

[0190] Returns the set of placeholder identifiers after deduplication.

[0191] The nesting hierarchy of the report template component tree, the extraction positions of placeholders in each component type, and the recursive extraction output relationship can be found in [reference needed]. Figure 2 .

[0192] The specification reverse lookup and verification module in this application performs type verification on the fill value according to the component type and data specification to which the placeholder belongs.

[0193] In some embodiments, the fill value validation process may include the following steps: For each extracted placeholder identifier, match it component by component in the template component tree to determine the component type and subtype to which the placeholder belongs.

[0194] For placeholders of the statistical type, the returned component type is statistical, and the value to be filled in is required to be a numeric type (integer or floating-point number) during validation.

[0195] For placeholders belonging to the chart type, the returned component type is chart and the specific chart subtype (line chart, bar chart, pie chart, area chart, or scatter plot), and is validated. The validation rules are as follows: the fill value must be a structured record collection; each element in the collection must be a structured record; line chart and area chart records must contain a time field and a value field; bar chart records must contain a category field and a value field; pie chart records must contain a name or category field and a value field; scatter plot records must contain x-axis and y-axis values.

[0196] For placeholders of table type, return the component type table and the associated column definition and validate it. The validation rules are as follows: the fill value must be a collection of row records; each element in the collection must be a row record; the row record field should be aligned with the column definition field.

[0197] For placeholders of type text, return a component of type text and validate it. The validation rules are as follows: the fill value should be a single value (text value, number, or logical value), and collections or objects are not accepted.

[0198] The verification results are divided into three types: verification successful, verification failed (type mismatch or structure does not meet specifications), and missing fill value (the placeholder mapping data does not contain the value corresponding to the placeholder).

[0199] Through the above protocol validation by component type, the system can detect data structure problems such as missing required fields in chart data, statistical placeholders being incorrectly filled with text values, and mismatch between table row records and column definitions before report rendering, rather than exposing errors only during the rendering stage.

[0200] For information on fill value requirements, validation rules, and default value handling for component types such as statistics, charts, tables, and text, please refer to [link / reference]. Figure 3 .

[0201] like Figure 6 As shown, in this embodiment of the application, when the verification finds that the fill value is missing or invalid, the degradation metadata recording module generates a default value and records the degradation metadata.

[0202] In some embodiments, the default value setting and degradation metadata recording process may include the following steps: For statistical type placeholders that fail validation, generate empty values ​​or default values ​​of preset values; for chart type placeholders, generate an empty set of default values; for table type placeholders, generate an empty set of default values; for text type placeholders, generate a default value of "to be supplemented".

[0203] For invalid fill values, the invalid entry is recorded in the downgrade metadata. The invalid entry may include a placeholder identifier and a specific description of the validation error (e.g., "Chart placeholders require a structured record set but the fill value format does not meet the requirements", "Statistical placeholders require numerical values ​​but the fill value is a text value", "Table row records do not conform to column definitions", etc.).

[0204] For missing filler values, the missing entry is recorded in the degraded metadata, and the missing entry may contain placeholder identifiers.

[0205] The system returns the downgraded metadata along with the populated template data. The metadata includes at least: the total number of placeholders, the number of placeholders already populated, a list of missing placeholders, a list of invalid placeholders and error descriptions, a data source identifier (e.g., from execution result mapping or from report generation experts), and whether a downgrade flag exists.

[0206] The system generates placeholder mapping data based on task results and execution summaries, and replaces the placeholders with validated fill values ​​or default values ​​without changing the template component tree structure.

[0207] Through the aforementioned degradation metadata recording mechanism, even if some placeholder data is temporarily unavailable or in an invalid format, the report generation process will not be completely interrupted; subsequent modules or users can learn which placeholders have been downgraded and the reasons for it through the degradation metadata.

[0208] In some embodiments, the recording method for degradation metadata such as missing items, illegal items, error descriptions, and degradation flags can be found in [reference needed]. Figure 6 .

[0209] In this embodiment of the application, the multi-round completion module creates a report generation task and triggers multiple rounds of data query and placeholder completion when the report is not generated or the placeholders are not completed.

[0210] In some embodiments, a multi-round completion process may include the following steps: The event handler (such as the report security commander handler) reads the event-associated report template object from the database and parses the template component tree structure.

[0211] The report event processor generates data query tasks based on the template component tree and the currently available list of assistants (which may include security log experts, security alert experts, asset retrieval experts, and report generation experts) and assigns them to the corresponding expert assistants.

[0212] Each expert assistant executes a data query task and generates task results. The task results include structured data obtained from data sources such as security logs, alarm systems, and asset systems.

[0213] After receiving all task results, the report generation expert processor generates placeholder mapping data based on the task results and the report template component tree.

[0214] The report generation expert processor calls the rendering and verification module to perform protocol verification and default value degradation on the placeholder mapping data according to component type.

[0215] If the metadata after verification and downgrading shows that there are downgraded items (i.e., there are missing or illegal placeholders), the system will feed back the downgrading information to the reporting event handler, which will then determine whether to continue dispatching new data query tasks based on the downgrading information.

[0216] After receiving feedback from the report generation expert, the report event handler checks the status of the report generation task in the current event round. If the report has not yet been generated (i.e., the template rendering result associated with the event is empty or does not exist), and there is no report generation task in progress, a new report generation task is automatically created and sent to the task processing queue.

[0217] When creating a new report generation task, the event round identifier is incremented. The system can set a maximum round limit (e.g., no more than 6 or 7 rounds). When the round limit is reached, the system ends the multi-round completion process and records the incomplete status.

[0218] When the report generates expert feedback that all placeholders have been filled according to the protocol (i.e., there are no degradation items in the metadata), the system writes the rendered template data into the report result field of the event object and triggers the event completion processing flow.

[0219] Through the aforementioned multi-round completion mechanism, report generation is not a one-time "all or nothing" process, but a closed-loop process that involves multiple rounds of task assignment, data query, and completion based on the placeholder filling status.

[0220] The multi-round closed-loop relationship of creating completion tasks based on downgraded metadata, dispatching data queries, updating mappings, and returning validation results can be found in [link to documentation]. Figure 6 .

[0221] In some embodiments of this application, the state objects are associated with each other according to the following relationship: 1. A command object is associated with an execution object through a command identifier. One command object can correspond to one or more execution objects.

[0222] 2. Command objects are associated with event objects through event identifiers, and with task objects through task identifiers.

[0223] 3. Execution objects are associated with command objects through command identifiers, event objects through event identifiers, and task objects through task identifiers.

[0224] 4. The execution summary message object is associated with the execution object through the execution identifier, the event object through the event identifier, and the task object through the task identifier.

[0225] 5. Event report template objects are associated with event objects through event identifiers, and the template component tree is stored in the structured data fields of the template object.

[0226] 6. The report generation expert task is associated with the current processing round of the event object through event identifier and event round identifier.

[0227] In some embodiments, the state transition relationships of each object are shown in the table below. Through the aforementioned cross-object relationships and state transitions, command execution and report generation are no longer isolated functionalities, but rather form a closed loop with event processing and task processing through a unified state object and state transition mechanism.

[0228] The embodiments of this application may include the following exception handling and recovery mechanisms: If a smart summary request fails due to exceeding the long text limit, the system can recursively truncate the text fields in the execution result, reset the execution status to complete, and resend the summary request process.

[0229] When a smart digest request is stopped or returns a failure, the system can reset the execution status to complete and resend it into the digest request process.

[0230] When an event sets a stop flag, summary processing is paused. Upon resumption, the system can re-enqueue the executed objects based on their state in the database.

[0231] During template component validation, the system throws a validation error for components that lack necessary fields (identifier, type, title); similarly, the system captures and reports errors during the validation phase for specification errors such as invalid chart subtypes or missing data index fields in table column definitions.

[0232] If placeholder mapping resolution fails during report generation, the system will update the report generation task status to failure, record the error information, and create a system notification message.

[0233] When a recommended or preset placeholder fails to be matched in the data dictionary for multiple consecutive rounds, the reporting event handler can determine whether to continue dispatching related query tasks based on historical task allocation records to avoid invalid and repeated queries.

[0234] In this application embodiment, alarm content, asset information, log content and / or query results can all use anonymized or simulated data, and sensitive business data should not be written into them before formal submission.

[0235] In one embodiment, the system fully experiences the complete chain from command creation, route execution, dual-path summary, backfill triggering, report template parsing, placeholder protocol verification, degradation record to multi-round completion and report generation.

[0236] Command Creation and Routing Execution Phase. During the security incident analysis process, the analysis expert processor generates two commands: a security log query command, whose tool parameters include a structured query statement, and whose target is "to query access records of the target address within a preset time window"; and an asset confirmation command, whose tool identifier is the asset query tool, and whose target is "to confirm the asset information corresponding to the target address". The system creates command objects for each command, recording the command type, tool identifier, tool parameters, command target, event identifier, task identifier, and task round identifier. After reading the commands from the operation execution queue, the command routing module routes the log query command to the security log query execution path and the asset confirmation command to the tool service execution path based on the command type field. After both commands are executed, the system creates an execution object and records the execution status as complete.

[0237] The system employs a dual-path summary and backfilling triggering phase. For structured query execution results of log query commands, the system identifies the command type as a structured query class and triggers the direct structured summary path: extracting the return status and return result from the execution result, assembling the task name, task objective, and execution result into a structured summary according to a preset template format, directly writing it into the structured summary field of the execution object, and updating the execution status to "summarized." This entire process does not trigger a smart summary request. For tool execution results of asset confirmation commands, the system identifies the command type as an unstructured query class and triggers the smart summary request path: extracting the task name, return status, return result, and task objective from the execution object and command object, constructing structured context information, creating an operator role smart summary request, and sending it to the summary request queue; after the smart summary response is completed, it flows back to the operation execution queue, the system parses the response, removes non-result content, writes the summary into the structured summary field of the execution object, and updates the execution status to "summarized." The system then creates execution summary messages for each execution record. The system checks whether all commands and their execution records under this task round have reached the summarized state; if all are satisfied, the task status is updated to task round completed, and the task is sent back to the task processing queue.

[0238] Report template parsing and placeholder verification phase. After a security incident is handled, the system enters the report generation process. The security operations report template associated with this incident contains the following component structure: a statistics component (for displaying the total number of security incidents and the number of high-risk incidents), a chart component (line chart type, for displaying alarm trends), a table component (for displaying the list of alarm sources), and a text component (for displaying the analysis conclusions). The placeholder extraction module recursively traverses the template component tree and extracts five types of placeholders: event quantity placeholders and high-risk incident quantity placeholders belong to the statistics type; attack timeline placeholders belong to the chart type; source address list placeholders belong to the table type; and conclusion text placeholders belong to the text type.

[0239] The report generation expert processor receives all previous task results and execution summaries as data sources and generates placeholder mapping data. The specification reverse lookup and verification module performs verification based on the component type to which each placeholder belongs: the placeholder for "security event quantity" has a numeric value, and verification succeeds; the placeholder for "high-risk quantity" has a text value, and verification fails and is recorded as "statistical placeholder, the form of the fill value does not meet the numerical requirements"; the placeholder for "attack timeline" has a structured record set containing time and value fields, and verification succeeds; the placeholder for "source address list" has a missing fill value; the placeholder for "conclusion text" has a text segment, and verification succeeds. For placeholders that fail verification or are missing, the system generates default values ​​according to component type: the placeholder for "high-risk quantity" is downgraded to an empty value, and the placeholder for "source address list" is downgraded to an empty set, and these are recorded as illegal and missing items in the metadata, respectively.

[0240] The process involves multiple rounds of completion and report generation. Due to the existence of downgraded items, the report generation expert's processing result shows that the report has been generated but has been downgraded. The report event processor checks the status of the report generation task in the current event round. If it finds that the report has not yet been effectively generated and there is no ongoing report generation task, it automatically creates a new report generation task (the event round identifier increments). After the new task is sent to the task processing queue, the report generation expert, based on the downgraded metadata (missing item list and illegal item list) from the previous round, reorganizes the data query instructions for missing and illegal placeholders and dispatches them to the security alert expert for supplementary queries. After the supplementary queries are completed, the report generation expert generates placeholder mapping data again and re-executes protocol verification. If all placeholders are successfully verified in this round (no downgrade flags in the metadata), the system writes the rendered template data into the report result field of the event object and triggers the event completion processing flow.

[0241] This embodiment fully demonstrates the closed-loop connection between command creation and report generation in this application: the task result and execution summary serve as placeholders to map the data source. After component-level protocol verification, the degradation information drives multiple rounds of completion, and finally the report is generated.

[0242] In another embodiment, under a collaborative security incident, the security commander processor generates an agent invocation command, requesting the collaborative agent to perform a comprehensive threat analysis. This command is of the agent invocation type.

[0243] The executor executes the command and creates an execution object. The execution summary processor generates a summary of the execution result. After the summary is completed, since the event type is a collaborative event and the command type is an agent invocation type, the system triggers the event round completion check path: checking whether all commands and execution records under this event round have reached the summarized state. If the condition is met, the system updates the event status to pending and re-sends the event to the event processing queue. The event-level processor makes a re-decision based on the execution summary and task result, determining whether to continue dispatching new collaborative tasks or terminate the event.

[0244] This example demonstrates that the state transition path of collaborative events after summary backfilling differs from that of ordinary judgment and disposal events—the former directly returns to the event level for re-decision.

[0245] In another embodiment, the execution result returned by a certain tool is too long, causing the smart summary request to return a long text exceeding the limit error.

[0246] Upon receiving the failure response, the execution digest processor recursively truncates the execution result: it iterates through each text field in the structured data of the execution result, truncating any text exceeding a preset length and adding an ellipsis. After truncation, the system updates the execution result field in the execution object with the truncated content, resets the execution status to complete, and resubmits it to the digest request process.

[0247] If the process fails after truncation, or if the failure is due to a non-long text limit (e.g., model service exception), the system will reset the execution status to complete and maintain the retry count, then resubmit the summary request to the process for further processing. This embodiment demonstrates how the exception recovery mechanism of this application addresses specific failure scenarios such as long text limit exceeding.

[0248] The embodiments of this application can be applied to scenarios such as security operations centers, enterprise security incident response systems, AI-SOC systems, security alarm analysis systems, security incident handling platforms, automated threat analysis systems, security operation and maintenance auxiliary decision-making systems, and security operation report automatic generation systems.

[0249] Typical applications include multi-tool invocation and result backfilling during security incident handling, structured summarization and reuse of security log query results, unified encapsulation and backfilling of asset information query results, summarization and recording of attack payload analysis results, standardized recording and backfilling of manual handling confirmation results, automatic generation and data verification of daily / weekly / incident reports for security operations, placeholder protocol verification and fault-tolerant generation of multi-component report templates, and structured report data filling based on task results and execution summaries.

[0250] like Figure 7 As shown in the figure, this application provides a system for backfilling and generating verification of results for security operation tasks, including: The filling module 710 is used to extract placeholders from the report template component tree associated with the security event in response to the report generation request of the security event, and generate placeholder mapping data using the task result and structured execution summary of the security event as the data source. The placeholder mapping data includes the mapping relationship between placeholders and filling values. The verification module 720 is used to verify the placeholder mapping data according to the component type of the component to which each placeholder belongs in order to obtain the verification result; The generation module 730 is used to generate degradation meta-information based on the verification result. In the case of verification failure, the padding value of the corresponding placeholder is set to the default value corresponding to the component type of the placeholder that failed the verification. The degradation meta-information includes degradation items. Degradation items include at least one of illegal items and missing items. Illegal items indicate that the padding value of the corresponding placeholder mapping in the placeholder mapping data is illegal, and missing items indicate that the padding value of the corresponding placeholder mapping in the placeholder mapping data is missing. The completion module 740 is used to trigger the completion of the fill value in the placeholder mapping data based on the degradation meta information when the degradation meta information includes degradation items. It regenerates the fill value of the placeholder corresponding to the degradation item and re-executes the verification of the placeholder mapping data until all placeholder mapping data are successfully verified or the number of completions reaches the upper limit of rounds. The reporting module 750 is used to fill the report template component tree with the fill values ​​of the successfully verified placeholder mapping data when all placeholder mapping data are successfully verified, and obtain a report of the security event; when the number of completions reaches the round limit and there are still degraded items, the report template component tree is filled with the default value for the placeholder corresponding to the degraded item, and a report of the security event containing the exception marker is generated.

[0251] The system for backfilling and generating verification of security operation task results provided in the above embodiments can execute the method for backfilling and generating verification of security operation task results provided in any of the aforementioned method embodiments. The above-described division of program modules is merely an example; in practical applications, the above steps can be assigned to different program modules or processors as needed. That is, the internal structure of the system can be divided into different program modules or processors to complete all or part of the processing described above. Furthermore, the system for backfilling and generating verification of security operation task results provided in the above embodiments and the method for backfilling and generating verification of security operation task results belong to the same concept. The specific implementation process is detailed in the method embodiments and will not be repeated here.

[0252] To achieve the above objectives, embodiments of this application also provide an electronic device, such as... Figure 8 As shown, the electronic device may include a processor 801 and a memory 803 connected to the processor 801 via a communication bus 802; wherein, the memory 803 is used for an executable program; the processor 801, through the execution of the executable program, can implement the backfilling and report generation verification method for security operation task results provided in any of the foregoing embodiments.

[0253] Another embodiment of this application provides a computer-readable storage medium storing an executable program. When executed by a processor 801, the executable program can implement the steps of the aforementioned method for backfilling and verifying the results of security operation tasks. For example, as... Figures 1-3 One or more of the methods shown.

[0254] In some embodiments, the computer-readable storage medium may include various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0255] Those skilled in the art, upon considering the specification and practicing the technical solutions disclosed in this application, will readily conceive of other embodiments of this application. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary technical means in the art not specifically described in this application. The specification and embodiments are considered exemplary only, and the scope of protection of this application is determined by the claims.

Claims

1. A method for backfilling and report generation verification of results for safe operation tasks, characterized in that, The method includes: In response to a security incident report generation request, placeholders are extracted from the report template component tree associated with the security incident, and placeholder mapping data is generated using the task result and structured execution summary of the security incident as the data source. The placeholder mapping data includes the mapping relationship between placeholders and fill values. Based on the component type of the component to which each placeholder belongs, the placeholder mapping data is validated to obtain the validation result; Based on the verification result, degradation meta-information is generated. In the case of a verification failure, the padding value of the corresponding placeholder is set to a default value corresponding to the component type of the failed placeholder. The degradation meta-information includes degradation items; each degradation item includes at least one of illegal items and missing items. An illegal item indicates that the padding value of the corresponding placeholder mapping in the placeholder mapping data is illegal, and a missing item indicates that the padding value of the corresponding placeholder mapping in the placeholder mapping data is missing. When the degradation meta information includes the degradation item, the padding value in the placeholder mapping data is triggered based on the degradation meta information. The padding value of the placeholder corresponding to the degradation item is regenerated and the verification of the placeholder mapping data is re-executed until all the placeholder mapping data are successfully verified or the number of padding times reaches the round limit. If all the placeholder mapping data are successfully verified, the report template component tree is filled with the fill value of the successfully verified placeholder mapping data to obtain the report of the security event; if the number of completions reaches the upper limit of the round and the degradation item still exists, the report template component tree is filled with the default value for the placeholder corresponding to the degradation item, and a report of the security event containing the exception marker is generated.

2. The method according to claim 1, characterized in that, The task results are obtained in the following ways: An execution record is generated based on the execution results of various heterogeneous tools; the execution record includes at least the execution results. Generate the execution summary of the execution record, populate the execution summary into the task context associated with the execution record, and mark the summary status of the execution record as summary completion status; After all execution records in the same task round have reached the summary completion state, the task context is written into the task result.

3. The method according to claim 2, characterized in that, The process of generating execution records based on the execution results of multiple heterogeneous tools includes: The action to be executed is encapsulated as a command object, which contains a command type field for recording the execution path. The command type includes at least two of the following: script execution type, agent invocation type, tool invocation type, manual processing type, load analysis type, security log query type, and relational data query type. Based on the execution path recorded in the command type field, the command object is routed to the corresponding execution tool among various heterogeneous tools; Based on the execution result of the execution tool, an execution object associated with the command object is created, and the execution result is recorded in the execution object.

4. The method according to claim 2, characterized in that, The execution digest for generating the execution record includes: For the execution results of structured queries, extract the return status and return result from the execution results, and generate the execution summary according to a preset template based on the return status and return result; or, For execution results of unstructured queries, a preset agent is invoked based on the execution record to obtain a summary response returned by the preset agent, and the execution summary is generated based on the summary response.

5. The method according to claim 2, characterized in that, The step of backfilling the execution summary into the task context associated with the execution record includes: When all execution records associated with the same command object reach either a summary completion state or a failure state, the summary states of the execution records are aggregated to update the command state of the corresponding command object; wherein, if there is at least one failed execution, the command state is updated to failure; if all executions are successful and all summaries are completed, the command state is updated to completion. When the security event is a collaborative event and the command type of the command object is an agent invocation type, after the command status of each command object under the current event round associated with the security event reaches the completion state or failure state, the security event is resent into the event processing queue to trigger the event-level processing flow. The event-level processing flow is used to re-evaluate the overall status of the security event and / or plan the handling action based on the execution summary of all tasks under the security event. When the security event is a non-cooperative event or the command type of the command object is not an agent invocation type, after the command status of each command object in the current task round reaches the completed state or the failed state, the corresponding task is re-sent to the task processing queue so that the task can determine whether the task objective has been achieved based on the execution digest; wherein, if the task objective has not been achieved, a new command object is generated and sent to the operation execution queue; if the task objective has been achieved, the task result is written and the task is terminated.

6. The method according to any one of claims 1 to 5, characterized in that, The step of performing data structure validation corresponding to the component type of each placeholder on each fill value to obtain a validation result includes: When the component type to which the placeholder belongs is statistical, check whether the fill value of the placeholder of the statistical type is a numerical value; When the component type to which the placeholder belongs is a chart type, check whether the fill value of the placeholder of the chart type is a structured record set, and whether each element in the structured record set is a structured record that conforms to the data specifications of the chart type; When the component type to which the placeholder belongs is a table type, check whether the fill value of the placeholder of the table type is a row record set, and whether the fields of each row record in the row record set are aligned with the column definitions configured by the component of the table type; When the component type to which the placeholder belongs is text, check whether the fill value of the text type placeholder is a single value data; Generate a verification result, wherein the verification result is either successful or unsuccessful.

7. The method according to claim 6, characterized in that, When the component type to which the placeholder belongs is a chart type, verify whether the fill value of the placeholder of the chart type is a structured record set, including: performing one of the following verifications according to the chart subtype of the chart type: When the chart subtype is a line chart or an area chart, verify whether the structured record contains a time field and a value field; When the chart subtype is a bar chart, verify whether the structured record contains a category field and a value field; When the chart subtype is a pie chart, verify whether the structured record contains a name field and a value field; When the chart subtype is a scatter plot, verify whether the structured record contains horizontal and vertical coordinate values.

8. The method according to claim 6, characterized in that, The padding value corresponding to the placeholder that failed the validation is set to a default value corresponding to the component type to which the placeholder belongs, including at least one of the following: When the component type to which the placeholder of the failed verification belongs is the statistical type, the corresponding default value is empty or a preset value; When the component type of the placeholder that failed the validation is the chart type or the table type, the corresponding default value is an empty set; When the component type of the placeholder that failed the validation is the text type, the corresponding default value is the preset placeholder text; When the degradation metadata includes the degradation item, the process triggers the completion of the fill value in the placeholder mapping data based on the degradation metadata, regenerates the fill value of the placeholder corresponding to the degradation item, and re-executes the verification of the placeholder mapping data until all the placeholder mapping data are successfully verified or the number of completions reaches the round limit, including: When the degradation metadata contains the degradation item, a report generation task is created and the event round identifier is incremented based on the completion round. A data query task is dispatched based on the placeholders that failed the verification to regenerate the filling value of the corresponding placeholder, and then the data structure verification is re-executed. When the event round identifier exceeds the round limit, the completion process ends.

9. A system for backfilling and generating / verifying reports on the results of safe operation tasks, characterized in that, The system includes: The filling module is used to respond to a security event report generation request, extract placeholders from the report template component tree associated with the security event, and generate placeholder mapping data using the task result and structured execution summary of the security event as the data source. The placeholder mapping data includes the mapping relationship between placeholders and filling values. The verification module is used to verify the placeholder mapping data according to the component type of the component to which each placeholder belongs in order to obtain the verification result; A generation module is used to generate degradation metadata based on the verification result. In the case of a verification failure, the padding value of the corresponding placeholder is set to a default value corresponding to the component type of the failed placeholder. The degradation metadata includes degradation items; each degradation item includes at least one of illegal items and missing items. An illegal item indicates that the padding value of the corresponding placeholder mapping in the placeholder mapping data is illegal, and a missing item indicates that the padding value of the corresponding placeholder mapping in the placeholder mapping data is missing. The completion module is used to trigger the completion of the fill value in the placeholder mapping data based on the degradation meta information when the degradation meta information includes the degradation item, regenerate the fill value of the placeholder corresponding to the degradation item and re-execute the verification of the placeholder mapping data until all the placeholder mapping data are successfully verified or the number of completions reaches the round limit. The reporting module is used to fill the report template component tree with the fill value of the successfully verified placeholder mapping data when all the placeholder mapping data are successfully verified, so as to obtain a report of the security event; when the number of completions reaches the upper limit of the round and the degradation item still exists, the report template component tree is filled with the default value for the placeholder corresponding to the degradation item, and a report of the security event containing the exception marker is generated.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, enable the implementation of the method described in any one of claims 1-8.

Images