A method and system for task flow execution of security event automatic response

Abstract

This invention discloses a task flow execution method and system for automated security incident response, relating to the fields of network security and automated response technology. Addressing the problems of high configuration barriers, single execution modes, chaotic context management, and weak exception handling capabilities in existing security response systems, this invention generates an enhanced directed acyclic graph (DAG) containing three types of directed edges through declarative description compilation. After verification by the pre-graph, it is released. Combined with versioned context management using lazy dependency resolution, a multi-mode triggering mechanism, and separate exception handling for error propagation edges, this achieves low-barrier, highly reliable, and auditable automated security incident response. This invention allows for the design of security response task flows without requiring programming skills, reducing reliance on professional developers, significantly lowering learning costs and usage barriers. It also supports four triggering modes, covering various security operation scenarios and offering greater adaptability.

Description

Technical Field

[0001] This invention relates to the fields of network security and automated response technology, specifically to a task flow execution method and system for automatic response to security incidents. Background Technology

[0002] As cyberattacks become more diverse and complex, the number of alerts faced by enterprises in their security operations continues to grow. Traditional manual response methods suffer from problems such as delayed responses, inconsistent handling standards, and high labor costs. Security Orchestration Automation and Response (SOAR) systems, through task flow technology, automate the security response process, becoming a core tool for improving security operation efficiency.

[0003] Existing security response task flow systems are highly complex to configure. Most systems rely on code writing or complex configuration files to define task flows, requiring operators to have programming skills. The learning cost for ordinary security operations and maintenance personnel is high, and custom development by professional developers is required. Moreover, the execution mode is singular, generally only supporting event-driven automatic execution mode, lacking native support for multiple trigger modes such as manual execution and scheduled execution, making it difficult to adapt to diverse emergency response and compliance inspection scenarios. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides a task flow execution method and system for automatic response to security incidents, which solves the problems mentioned in the background section.

[0005] To achieve the above objectives, the present invention provides a task flow execution method for automatic response to security incidents, comprising the following steps:

[0006] S1. Receive a platform-independent declarative task flow description file, extract the node set, node parameters and connection relationships between nodes in the task flow, compile the original jump logic into three types of directed edges: ordinary success edges, conditional branch edges, and error propagation edges, and generate an enhanced directed acyclic graph for security response scenarios based on the node set and the three types of directed edges.

[0007] S2. Perform acyclic detection and full node reachability analysis on the enhanced directed acyclic graph to verify that each node in the graph has at least one valid execution path to the end node, and only publish the enhanced directed acyclic graph that has passed the verification as an executable task flow;

[0008] S3. Match the preset trigger conditions to trigger the task flow execution, create a dedicated execution context for this execution, and write the initial data of the trigger event into the execution context;

[0009] S4. Execute each node according to the topological order of the enhanced directed acyclic graph. Before a node executes, it resolves the upstream variable references in its parameters and converts the variable references into dependency descriptors. If the dependent upstream node has not completed execution, the scheduling of the current node is paused and a completion listener callback is registered with the context manager. After the upstream node completes execution and writes the result to the execution context, the listener callback is triggered to activate the current node to continue execution.

[0010] S5. After a node is executed, the corresponding outgoing edge is matched in the enhanced directed acyclic graph according to the final execution status of the node to determine the next node to be executed. When a node fails, times out, or returns a preset error code, the corresponding error handling node path is activated along the error propagation edge to achieve the separation of business logic and exception handling logic.

[0011] S6. After all nodes have been executed, generate an execution report for this task flow and synchronously store the full-process execution log and audit trail data.

[0012] Furthermore, the definitions of the three types of directed edges in step S1 are as follows:

[0013] The next node after the normal successful edge node completes its execution without any additional conditions is used for the chaining of linear execution processes;

[0014] The conditional branch edge corresponds to the decision-type node, which, based on the Boolean condition calculation result, points to the target node when the condition is true and when the condition is false, respectively, for branch judgment scenarios.

[0015] The error propagation edge corresponds to the target error handling node to which the node jumps when it fails, times out, or returns a specified error code, and is used for targeted handling of abnormal scenarios.

[0016] Furthermore, the specific process of the acyclic detection and full node reachability analysis in step S2 is as follows:

[0017] A topology sorting algorithm is used to detect loops in the enhanced directed acyclic graph. If a cyclic dependency link is detected, the verification fails and the graph is rejected.

[0018] A depth-first search algorithm is used to perform a full reachability traversal starting from the starting node. At the same time, it is verified in reverse that each node can reach the ending node. If there is a node that has no valid path to the ending node, the verification is deemed to have failed.

[0019] When validation fails, a detailed error report containing the location of the error and the type of problem is generated and returned to the front-end designer for prompts.

[0020] Furthermore, the preset triggering conditions in step S3 include any one or more combinations of the following:

[0021] Execution commands manually triggered by the user through the front-end interface;

[0022] A timed trigger rule defined by a Cron expression will automatically start and execute when the set time point is reached.

[0023] Event-driven instructions triggered by the complex event processing engine after matching security alert rules;

[0024] The request is triggered by a call initiated by an external system through the Webhook interface.

[0025] Furthermore, the dependency descriptor in step S4 includes at least three types of information: source node ID, source result field path, and target node parameter name; the execution context adopts a versioned snapshot storage mechanism, and a new version snapshot is generated whenever a node writes the execution result to the context. All node read operations are performed based on the snapshot ID of the corresponding version, ensuring data consistency during parallel branch execution.

[0026] Furthermore, the final execution status of the node in step S5 includes any one of the following: execution successful, execution failed, execution timed out, condition determined to be true, and condition determined to be false.

[0027] For ordinary action nodes, if the execution is successful, jump along the normal success path; if the execution fails or times out, jump along the error propagation path.

[0028] For decision nodes, jump along the corresponding condition branch edge according to the condition calculation result, and jump along the error propagation edge when the condition calculation is abnormal.

[0029] Furthermore, step S5 also includes a node-level fault tolerance mechanism, specifically:

[0030] It supports configuring retry policies independently for each node. The retry policy includes the maximum number of retries, the retry interval duration, and the set of retryable error types.

[0031] It supports configuring degradation execution actions for each node, and the degradation execution actions include at least one of calling the backup interface, using historical cached data, and skipping the current node;

[0032] An abnormal error that is not caught by the error propagation edge triggers a global fallback process, which includes at least one of the following: sending an alarm notification to the administrator, pausing the execution of the current task flow, and recording the exception stack information.

[0033] Furthermore, the node in step S4 includes at least one of the following: action node, decision node, aggregation node, waiting node, and log node.

[0034] The variable parsing before node execution supports nested path references and expression evaluation. During the parsing process, placeholder variables in the parameters are replaced with actual data in the execution context. After the replacement is completed, the business logic corresponding to the node is executed.

[0035] A task flow execution system for automatic response to security incidents, wherein the system applies the aforementioned task flow execution method for automatic response to security incidents.

[0036] This invention provides a task flow execution method and system for automatic response to security incidents, which has the following beneficial effects:

[0037] 1. The task flow execution method and system for automatic security incident response combines declarative description with visual drag-and-drop design, allowing users to design security response task flows without programming skills. Security operations personnel can complete process configuration and maintenance independently, reducing reliance on professional developers, significantly lowering learning costs and usage thresholds. It also supports four trigger modes: manual, scheduled, event-driven, and Webhook, covering various security operation scenarios such as automatic intrusion alarm handling, scheduled compliance checks, manual emergency response, and cross-system linkage, making it more adaptable.

[0038] 2. The task flow execution method and system for automatic response to security incidents adopts lazy dependency resolution and versioned snapshot mechanism to automatically handle parameter dependencies and data transfer between nodes. It supports data consistency in complex branching and parallel scenarios, solves the problem of chaotic dynamic parameter transfer in traditional task flows, and achieves separation of business logic and exception logic through an independent error propagation side mechanism. Combined with a three-level fault tolerance system of node-level retry, degraded execution, and global fallback, it significantly improves the reliability of task flow execution and reduces the probability of failure interruption. Moreover, the pre-emptive graph verification can discover logical defects in the design stage, and the full-process execution log and audit trace can realize full backtracking of the execution process, which is convenient for fault investigation and compliance auditing. Attached Figure Description

[0039] Figure 1 This is a schematic diagram of the overall architecture of the workflow system of the present invention;

[0040] Figure 2 This is a schematic diagram of the workflow execution process of the present invention;

[0041] Figure 3 This is a schematic diagram of the execution context data flow of the present invention. Detailed Implementation

[0042] The embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples. The following examples are for illustrative purposes only and should not be construed as limiting the scope of the invention.

[0043] like Figures 1-3As shown, this invention provides a technical solution: a task flow execution method for automatic response to security events. This method achieves automated execution of security response task flows through a four-layer architecture: declarative description compilation, execution graph verification, lazy context management, runtime routing, and error handling. The specific steps are as follows:

[0044] S1. Declarative Description Compilation: Receives a platform-independent declarative task flow description file, extracts all nodes in the task flow, the configuration parameters of each node, and the connection relationships between nodes, and compiles the original conditional jump, success jump, and error jump logic into three types of directed edges: ordinary success edges, conditional branch edges, and error propagation edges. Based on the node set and the three types of directed edges, an enhanced directed acyclic graph optimized for security response scenarios is constructed.

[0045] The declarative task flow description file can be generated by dragging and dropping in the visual designer, eliminating the need for manual coding. It supports common formats such as JSON and YAML and is platform-independent. Three types of directed edges correspond to different execution jump logics, physically separating business logic, conditional logic, and exception logic within the graph structure, thus improving the maintainability of the process.

[0046] The three types of directed edges are defined as follows: ordinary success edges correspond to the next node after the node completes normal execution without additional conditions, and are used to connect linear execution processes; conditional branch edges correspond to decision-making nodes that point to the target nodes when the condition is true and false, respectively, based on the calculation results of the Boolean conditions, and are used to implement branch judgment logic; error propagation edges correspond to the target error handling node to which the node jumps when the node fails to execute, times out, or returns a specified error code, and are used to handle abnormal scenarios in a targeted manner.

[0047] S2. Execution Graph Verification and Publication: Perform two rounds of verification on the compiled enhanced directed acyclic graph. The first round is acyclic detection, and the second round is full node reachability analysis to ensure that each node in the graph has at least one valid execution path to the end node. Only when both verifications pass will the task flow be published as executable. If the verification fails, detailed error location information will be returned.

[0048] By using a pre-defined graph verification mechanism, logical defects in the process can be identified during the design phase, avoiding issues such as process dangling or infinite loops during execution and improving the reliability of the task flow.

[0049] Acyclic detection is implemented using a topology sorting algorithm. If a cyclic dependency link is detected, the verification is deemed unsuccessful. The full node reachability analysis uses a depth-first search algorithm, traversing all reachable nodes from the starting node and simultaneously verifying that each node can reach the ending node. If there is a node without a valid path to the ending node, the verification is deemed unsuccessful. When the verification fails, a detailed error report containing the abnormal location and problem type is generated and returned to the front-end designer for visual prompts.

[0050] S3, Multi-mode Triggering and Context Initialization: Supports multiple triggering modes, starts task flow execution after matching preset triggering conditions; creates a dedicated execution context instance for each execution, and writes the initial data carried by the triggering event into the execution context as the data basis for the entire task flow execution.

[0051] The multi-trigger mode can cover various security operation scenarios such as event-driven response, scheduled compliance checks, manual emergency handling, and external system linkage, thereby improving the system's adaptability.

[0052] Triggering conditions include any one or more combinations of manual triggering, timed triggering, event-driven triggering, and Webhook triggering: manual triggering is an execution command initiated by the user by clicking the execute button on the front-end interface; timed triggering is a timed rule defined by a Cron expression that automatically starts execution at the set time point; event-driven triggering is an execution command automatically initiated by a complex event processing engine after matching security alarm rules; and Webhook triggering is a call triggering request initiated by an external system through the standard Webhook interface.

[0053] S4. Topology Scheduling and Lazy Dependency Resolution: Nodes are scheduled for execution according to the topological order of the enhanced directed acyclic graph. Before each node executes, the variable expressions in its parameters are parsed, and the variable references of upstream nodes are converted into structured dependency descriptors. If the dependent upstream node has not yet completed execution, the scheduling of the current node is paused, and the completion listener callback of the upstream node is registered with the context manager. When the upstream node completes execution and writes the result to the execution context, all callback functions listening to that node are automatically triggered, activating the corresponding node to continue execution.

[0054] It adopts a lazy dependency resolution mechanism, which eliminates the need to pre-calculate the dependency order of all nodes. It can dynamically adapt to scenarios with parallel branches and dynamic parameters. At the same time, it combines an event-driven listening and waking mechanism to improve execution efficiency and concurrent processing capabilities.

[0055] The dependency descriptor contains at least three types of information: source node ID, source result field path, and target node parameter name. The execution context adopts a versioned snapshot storage mechanism. Whenever a node writes the execution result to the context, a new version snapshot is generated. All node read operations are performed based on the snapshot ID of the corresponding version, ensuring data consistency during parallel branch execution and avoiding read-write conflicts.

[0056] Nodes include at least one of action nodes, decision nodes, aggregation nodes, waiting nodes, and log nodes; variable parsing before node execution supports nested path references and expression calculations. During the parsing process, placeholder variables in the parameters are replaced with actual data in the execution context, and the business logic corresponding to the node is executed after the replacement is completed.

[0057] S5. Runtime routing and error propagation handling: After a node is executed, the corresponding outgoing edge is matched in the enhanced directed acyclic graph according to the final execution state of the node to determine the next node to be executed; when a node fails to execute, times out, or returns a preset specific error code, it automatically jumps to the corresponding error handling node along the error propagation edge, realizing the separation design of business execution logic and exception handling logic.

[0058] With an independent error propagation edge mechanism, differentiated exception handling processes can be configured for different nodes and different error types, avoiding coupling between exception handling logic and business logic, and improving the maintainability and fault tolerance of the process.

[0059] The final execution status of a node includes any one of the following: execution successful, execution failed, execution timed out, condition is true, and condition is false. For ordinary action nodes, if execution is successful, jump along the normal success edge; if execution fails or times out, jump along the error propagation edge. For decision nodes, jump along the corresponding condition branch edge according to the condition calculation result; if the condition calculation is abnormal, jump along the error propagation edge.

[0060] It also includes a node-level fault tolerance mechanism: it supports configuring retry policies independently for each node, including the maximum number of retries, retry interval duration, and set of retryable error types; it supports configuring degradation execution actions for each node, including calling backup interfaces, using historical cached data, and skipping at least one of the following: abnormal errors not caught by the error propagation edge trigger global fallback processing, including sending alarm notifications to the administrator, pausing the execution of the current task flow, and recording exception stack information.

[0061] S6. Execution Report Generation and Audit Storage: After all nodes have completed execution, the entire process execution data is automatically summarized to generate an execution report for this task flow; at the same time, the execution logs, node status, parameter changes, operator information and other data of the entire chain are persistently stored to form a complete audit trace chain.

[0062] like Figure 1 As shown, the task flow execution system for automatic response to security events provided in this embodiment includes a front-end visual designer, a task flow definition module, a DLS parser, a DAG construction module, a topology sorting module, a trigger management module, a task flow execution engine, a node executor, an execution context management module, an error handling module, and a logging and auditing module.

[0063] The system comprises several components: a front-end visual designer providing a drag-and-drop interface for workflow design, allowing users to generate declarative task flow definition files by dragging and dropping nodes and connecting them to configure jump relationships; a task flow definition module storing and managing different versions of task flow definitions; a DLS parser responsible for parsing declarative task flow descriptions and extracting nodes, parameters, and connection relationships; a DAG construction module building an enhanced directed acyclic graph (DAG) containing three types of directed edges based on the parsing results; a topology sorting module for detecting acyclicity in the graph and calculating the execution order; a trigger management module managing various trigger rules and initiating execution after matching conditions; a task flow execution engine as the core scheduling unit, responsible for node scheduling and execution control; a node executor responsible for executing the business logic of various nodes; an execution context management module maintaining context data for each execution and handling dependency monitoring and version snapshots; an error handling module responsible for exception capture, retries, degradation, and error routing; and a log and audit module responsible for full-process log recording and audit data storage.

[0064] Combination Figure 2 and Figure 3 The task flow execution method for automatic response to security events described in this embodiment is implemented in the following specific steps:

[0065] Step 1: Visual Design and Declarative Definition of Task Flow

[0066] Users can drag and drop desired node types from the node library using the front-end visual designer, including action nodes, aggregation nodes, waiting nodes, and decision nodes. They can then configure the jump relationships between nodes by connecting them, including three types of connections: normal execution jumps, conditional branch jumps, and error jumps. After configuration, the system automatically generates a declarative task flow description file in JSON format and stores it in the task flow definition module, while also supporting version management and canary releases.

[0067] This process requires no coding; users can complete the process design simply through visual operations, lowering the barrier to entry. Security operations personnel can independently build and iterate response processes.

[0068] Step 2: Declarative Description Compilation and Enhanced DAG Generation

[0069] The DLS parser reads the declarative task flow description file and extracts information such as the ID, type, configuration parameters, and jump rules of all nodes. The DAG construction module maps the parsed jump rules into three types of directed edges: ordinary sequential jumps are mapped to ordinary success edges, true / false branches of decision nodes are mapped to conditional branch edges, and erroneous jump configurations of nodes are mapped to error propagation edges. Finally, an enhanced directed acyclic graph is constructed.

[0070] The three types of directed edges are independent of each other in the graph structure, and the business logic and exception logic are physically separated, which facilitates subsequent maintenance and adjustment.

[0071] Step 3: Perform graph verification and release

[0072] The topology sorting module performs acyclic detection on the enhanced directed acyclic graph: using the Kahn topology sorting algorithm, if the number of nodes after the final sort is inconsistent with the total number of nodes, it is determined that there is a circular dependency and the verification fails.

[0073] Then, a depth-first search algorithm is used to perform reachability verification: starting from the starting node, traverse forward and mark all reachable nodes; then start from the ending node and traverse backward and mark all nodes that can reach the ending node; if a node is not marked at the same time, it is determined that the node has a path defect and the verification fails.

[0074] Validated workflows are marked as publishable and can be triggered for execution; if validation fails, an error report containing the abnormal node ID, problem type, and repair suggestions is generated and returned to the front-end visual designer for highlighting.

[0075] Step 4: Trigger matching and context initialization

[0076] The trigger management module monitors various trigger sources in real time: for event-driven triggers, it listens to the alarm data stream of the SIEM system and automatically triggers the corresponding task stream after matching the preset alarm rules; for timed triggers, it counts the time according to the Cron expression and automatically triggers when the specified time point is reached; for manual triggers, it receives the user's execution command and triggers after verifying the permissions; for Webhook triggers, it receives the HTTP request from the external system and triggers after verifying the signature.

[0077] After the task flow is triggered and started, the execution context management module creates a unique context instance for this execution, generates a unique execution ID, and writes all the initial data carried by the triggering event, such as alarm information and request parameters, into the initial version of the context as the data base for the entire process execution.

[0078] Step 5: Node Scheduling and Lazy Dependency Resolution

[0079] The task flow execution engine schedules each node for execution sequentially according to the topological order of the enhanced directed acyclic graph. For each node to be executed, the node executor first parses the variable expressions in its configuration parameters, identifies all variables that reference the results of upstream nodes, and generates the corresponding dependency descriptor, which contains the source node ID, source field path, and target parameter name.

[0080] If all upstream nodes corresponding to the dependency descriptor have been executed, the corresponding data is read directly from the context, the variable is replaced, and the node logic is executed. If there are unfinished upstream dependency nodes, the scheduling of the current node is paused, and the completion listener callback of the corresponding upstream node is registered with the execution context management module.

[0081] When the upstream node finishes execution and writes the result to the context, the execution context management module updates the context version snapshot and triggers all callback functions listening to that node, notifying the task flow execution engine to activate the corresponding waiting node and continue the execution process.

[0082] The context storage uses a versioned snapshot mechanism. Each write operation generates a new version number, and read operations are bound to the corresponding version snapshot to avoid read-write conflicts during parallel branch execution and ensure data consistency.

[0083] Step 6: Execution Result Routing and Error Handling

[0084] After a node completes execution, execution status and result data are generated. The task flow execution engine matches the corresponding outgoing edges in the enhanced directed acyclic graph based on the node type and execution status.

[0085] For action-type nodes, if the execution is successful, the next node is scheduled along the normal success edge; if the execution fails, times out, or returns a specified error code, the corresponding error handling node is scheduled along the error propagation edge.

[0086] For decision-making nodes, if the condition calculation is successful, the next node is scheduled along the corresponding condition branch edge based on the Boolean result; if the condition calculation is abnormal, the error handling node is scheduled along the error propagation edge.

[0087] The error handling module provides a three-level fault tolerance mechanism: The first level is node-level retry, which automatically retries retryable errors according to the retry policy configured on the node, with retry intervals supporting fixed intervals and exponential backoff; the second level is degradation execution, which performs degradation actions according to the configuration after a retry failure, such as calling a backup interface, using cached data, or skipping the node; the third level is global fallback, which triggers global fallback logic if the error is not captured by the error propagation edge, sends an alarm notification to the administrator, and records the exception stack.

[0088] Step 7: Execution Completion and Audit Storage

[0089] When all nodes have completed execution or the process has terminated early, the log and audit module summarizes the execution data of the entire process, including execution ID, trigger time, execution status and time of each node, parameter change records, operator information, etc., and generates a structured execution report; at the same time, the execution log of the entire chain is persistently stored in the database to form a complete audit trace chain, supporting subsequent fault investigation and compliance audit.

[0090] The implementation process of the present invention will be further explained below through three specific application examples.

[0091] Example 1: Automatic Intrusion Alarm Response Task Flow

[0092] This embodiment is applied to the automatic handling scenario of intrusion alarms in the security operations center. When the SIEM system detects a high-risk intrusion alarm, it automatically executes the entire process of alarm verification, information query, blocking and handling, and notification reporting.

[0093] The specific execution process is as follows:

[0094] Task flow design and deployment: Users can drag and drop to configure task flow nodes through a visual designer, which are, in order: alarm receiving node, alarm validity judgment node, source IP historical event query node, event aggregation statistics node, blocking decision node, firewall blocking node, notification node, and log recording node; at the same time, error propagation edges are configured for the firewall blocking nodes, connecting to the blocking failure alarm nodes. After configuration, a declarative description file is generated, which is then compiled, verified, and deployed.

[0095] Trigger Startup: The SIEM system generates an intrusion alarm of type intrusion and severity level 8, which meets the preset triggering conditions alert.type=='intrusion' AND alert.severity>=7. This triggers the management module to automatically start the corresponding task flow, create an execution context, and write initial data such as alarm ID, source IP, target IP, and attack type into the context.

[0096] Alarm validity judgment node execution: Before the node executes, it parses the parameters, references the alarm data in the context, calculates the alarm confidence and source IP blacklist status, and determines whether the condition confidence > 0.8 AND not_blacklisted(src_ip) is true. If the condition is true, it proceeds to the next node along the branch edge where the condition is true; if the condition is false, it jumps directly to the end node.

[0097] The source IP historical event query node execution: The query statement in the node parameters contains the variable ${alert.src_ip}, which is parsed and replaced with the source IP address in the context. The Elasticsearch interface is called to query all security events of this IP in the past 24 hours, and the query results are written to the execution context.

[0098] Event aggregation statistics node execution: Read the result data from the query node, group and statistically analyze the events by event type and target IP, calculate the total number of events and average severity for each group, and write the statistical results into the context.

[0099] Block the execution of the decision node: Read the aggregated statistics results and judge the condition total_events>100 AND avg_severity>5. In this embodiment, the condition is true, and the firewall blocks the node along the branch where the condition is true.

[0100] Firewall blocking node execution: Parses variables such as IP and duration in the parameters, calls the firewall API to perform IP blocking operations. If execution is successful, it proceeds along the normal success edge to the notification node; if execution fails, it proceeds along the error propagation edge to the blocking failure alarm node, executes retry and degradation logic, and then notifies the administrator.

[0101] The notification node executes by reading data such as alarm ID, source IP, number of events, and blocking results from the context, filling in the notification template, and sending email and DingTalk notifications to the security team.

[0102] Log recording node execution: Records the entire process execution results, generates execution reports, and stores audit logs.

[0103] Example 2: Scheduled Database Compliance Check Task Flow

[0104] This embodiment is applied to routine compliance audit scenarios, automatically performing database permission checks every morning at midnight, and automatically issuing an alert when unauthorized accounts are found.

[0105] The specific execution process is as follows:

[0106] Task flow configuration: The task flow trigger type is configured as timed trigger. Timed trigger is formed by configuring timed parameters in the dimensions of minutes, hours, days, months, and weeks to form Cron scheduling rules. The task flow will be automatically started and executed according to the preset period. The time zone is Asia / Shanghai. The task flow nodes are as follows: unauthorized user query node, result judgment node, alarm notification node, and success log node.

[0107] Scheduled Trigger: Every day at 2:00 AM, the trigger management module will automatically start this task flow and create an execution context.

[0108] Unauthorized user query node execution: Executes a preset SQL query statement to retrieve a list of users with super privileges added within the last 24 hours from the database, and writes the query results into the context.

[0109] The result judgment node executes the following: it parses the expression ${query_unauthorized_users.result.length}>0. If the length of the query result is greater than 0, it proceeds to the alarm notification node along the branch where the condition is true; otherwise, it proceeds to the success log node along the branch where the condition is false.

[0110] The alarm notification node executes the following steps: read the number of users from the query results, populate the notification message, and send an email to the DBA team.

[0111] Successful log node execution: Records the log message "Compliance check passed, no anomalies found".

[0112] Upon completion, an execution report is generated, and the inspection results and execution logs are stored to support subsequent compliance audits.

[0113] Example 3: Node Anomaly Handling Example

[0114] This example illustrates the execution process of error propagation edges and fault tolerance mechanisms:

[0115] In the firewall blocking node of the above embodiment 1, the retry policy is configured to retry a maximum of 3 times, with a retry interval of 5 seconds, and the retry error types are network timeout and interface rate limiting; at the same time, the degradation action is configured to call the backup firewall interface.

[0116] When a node encounters a network timeout during its first call to the firewall API, the error handling module captures the error, matches it to a retryable error type, and executes the first retry after waiting 5 seconds. If all three consecutive retries fail, the degradation logic is triggered, and the backup firewall interface is called to block the connection. If the backup interface also fails, the system jumps along the error propagation edge to the error handling node, records the error information, and sends an emergency alarm to the administrator.

[0117] The three-level fault tolerance mechanism can significantly improve the success rate of handling abnormal scenarios and avoid the interruption of the entire response process due to a single point of failure.

[0118] In summary, this automated security incident response task flow execution method and system, through a combination of declarative description and visual drag-and-drop design, allows for the design of security response task flows without programming skills. Security operations personnel can complete process configuration and maintenance independently, reducing reliance on professional developers, significantly lowering learning costs and usage barriers. It also supports four trigger modes: manual, scheduled, event-driven, and Webhook, covering various security operation scenarios such as automated intrusion alarm handling, scheduled compliance checks, manual emergency response, and cross-system linkage, making it more adaptable.

[0119] Employing lazy dependency resolution and versioned snapshot mechanisms, it automatically handles parameter dependencies and data transfer between nodes, supports data consistency in complex branching and parallel scenarios, and solves the problem of chaotic dynamic parameter transfer in traditional task flows. It achieves separation of business logic and exception logic through an independent error propagation side mechanism. Combined with a three-level fault tolerance system of node-level retries, degraded execution, and global fallback, it significantly improves the reliability of task flow execution and reduces the probability of failure interruption. Furthermore, the upfront graph verification can discover logical defects in the design phase, and the full-process execution logs and audit trails enable full backtracking of the execution process, facilitating fault investigation and compliance auditing.

[0120] The embodiments of the present invention are given for illustrative and descriptive purposes only, and are not intended to be exhaustive or to limit the invention to the forms disclosed. Many modifications and variations will be apparent to those skilled in the art. The embodiments were chosen and described in order to better illustrate the principles and practical application of the invention, and to enable those skilled in the art to understand the invention and to design various embodiments with various modifications suitable for a particular purpose.

Claims

1. A task flow execution method for automatic response to security incidents, characterized in that: Includes the following steps: S1. Receive a platform-independent declarative task flow description file, extract the node set, node parameters and connection relationships between nodes in the task flow, compile the original jump logic into three types of directed edges: ordinary success edges, conditional branch edges, and error propagation edges, and generate an enhanced directed acyclic graph for security response scenarios based on the node set and the three types of directed edges. S2. Perform acyclic detection and full node reachability analysis on the enhanced directed acyclic graph to verify that each node in the graph has at least one valid execution path to the end node, and only publish the enhanced directed acyclic graph that has passed the verification as an executable task flow; S3. Match the preset trigger conditions to trigger the task flow execution, create a dedicated execution context for this execution, and write the initial data of the trigger event into the execution context; S4. Execute each node according to the topological order of the enhanced directed acyclic graph. Before the node is executed, resolve the upstream variable references in its parameters and convert the variable references into dependency descriptors. If the upstream node it depends on has not completed execution, the scheduling of the current node is paused and a completion listener callback is registered with the context manager; after the upstream node completes execution and writes the result to the execution context, the listener callback is triggered to activate the current node to continue execution; S5. After a node is executed, the corresponding outgoing edge is matched in the enhanced directed acyclic graph according to the final execution status of the node to determine the next node to be executed. When a node fails, times out, or returns a preset error code, the corresponding error handling node path is activated along the error propagation edge to achieve the separation of business logic and exception handling logic. S6. After all nodes have been executed, generate an execution report for this task flow and synchronously store the full-process execution log and audit trail data.

2. The task flow execution method for automatic response to security incidents according to claim 1, characterized in that: The three types of directed edges mentioned in step S1 are specifically defined as follows: The next node after the normal successful edge node completes its execution without any additional conditions is used for the chaining of linear execution processes; The conditional branch edge corresponds to the decision-type node, which, based on the Boolean condition calculation result, points to the target node when the condition is true and when the condition is false, respectively, for branch judgment scenarios. The error propagation edge corresponds to the target error handling node to which the node jumps when it fails, times out, or returns a specified error code, and is used for targeted handling of abnormal scenarios.

3. The task flow execution method for automatic response to security incidents according to claim 1, characterized in that: The specific process of acyclic detection and full node reachability analysis in step S2 is as follows: A topology sorting algorithm is used to detect loops in the enhanced directed acyclic graph. If a cyclic dependency link is detected, the verification fails and the graph is rejected. A depth-first search algorithm is used to perform a full reachability traversal starting from the starting node. At the same time, it is verified in reverse that each node can reach the ending node. If there is a node that has no valid path to the ending node, the verification is deemed to have failed. When validation fails, a detailed error report containing the location of the error and the type of problem is generated and returned to the front-end designer for prompts.

4. The task flow execution method for automatic response to security events according to claim 1, characterized in that: The preset triggering conditions in step S3 include any one or more of the following combinations: Execution commands manually triggered by the user through the front-end interface; A timed trigger rule defined by a Cron expression will automatically start and execute when the set time point is reached. Event-driven instructions triggered by the complex event processing engine after matching security alert rules; The request is triggered by a call initiated by an external system through the Webhook interface.

5. The task flow execution method for automatic response to security incidents according to claim 1, characterized in that: The dependency descriptor in step S4 contains at least three types of information: source node ID, source result field path, and target node parameter name. The execution context adopts a versioned snapshot storage mechanism. Whenever a node writes the execution result to the context, a new version snapshot is generated. All node read operations are performed based on the snapshot ID of the corresponding version, ensuring data consistency during parallel branch execution.

6. The task flow execution method for automatic response to security incidents according to claim 1, characterized in that: The final execution status of the node in step S5 includes any one of the following: execution successful, execution failed, execution timed out, condition determined to be true, and condition determined to be false. For ordinary action nodes, if the execution is successful, jump along the normal success path; if the execution fails or times out, jump along the error propagation path. For decision nodes, jump along the corresponding condition branch edge according to the condition calculation result, and jump along the error propagation edge when the condition calculation is abnormal.

7. The task flow execution method for automatic response to security incidents according to claim 1, characterized in that: Step S5 also includes a node-level fault tolerance mechanism, specifically: It supports configuring retry policies independently for each node. The retry policy includes the maximum number of retries, the retry interval duration, and the set of retryable error types. It supports configuring degradation execution actions for each node, and the degradation execution actions include at least one of calling the backup interface, using historical cached data, and skipping the current node; An abnormal error that is not caught by the error propagation edge triggers a global fallback process, which includes at least one of the following: sending an alarm notification to the administrator, pausing the execution of the current task flow, and recording the exception stack information.

8. The task flow execution method for automatic response to security incidents according to claim 1, characterized in that: The node in step S4 includes at least one of action node, decision node, aggregation node, waiting node, and log node; The variable parsing before node execution supports nested path references and expression evaluation. During the parsing process, placeholder variables in the parameters are replaced with actual data in the execution context. After the replacement is completed, the business logic corresponding to the node is executed.

9. A task flow execution system for automatic response to security incidents, characterized in that: The system application includes a task flow execution method for automatic response to security events as described in any one of claims 1-8.

Images