Method for dynamic configuration management of verification nodes based on security domain labels and multi-level association

Abstract

The application relates to the technical field of network security testing, and discloses a kind of based on security domain label and multi-level association's verification node dynamic configuration management method, comprising: constructing security domain label system and configuring security domain attribution for verification node;Based on security domain label, the dynamic filtering of same-domain security assets is carried out, and multi-to-multi association binding is realized;The three-dimensional task availability check of online state, operating system compatibility and security domain configuration integrity is carried out on the verification node;In the task execution context construction stage, the complete configuration information of the verification node is automatically read and injected;Based on the access control strategy matrix between security domains, the path compliance verification of cross-domain node combination is carried out, and a plurality of ordered execution sequences are generated.

Description

Technical Field

[0001] This invention relates to the field of network security testing technology, specifically to a dynamic configuration management method for verification nodes based on security domain labels and multi-level associations. Background Technology

[0002] The Intrusion and Attack Simulation (BAS) system deploys verification nodes in a distributed manner across various regions of the enterprise network. These nodes are responsible for functions such as simulating attack traffic initiation, attack behavior detection, and hosting of target range services. The management end configures and monitors each verification node through a centralized interface.

[0003] In existing BAS systems, the association between verification nodes and security assets relies on manual input by the administrator during each task creation phase. Verification nodes lack standardized network area attribution labels, and the system lacks pre-verification capabilities for the completeness of node configurations during the task creation process. Furthermore, the configuration information of verification nodes is coupled with the task lifecycle, requiring repeated input of information such as the node's security domain attribution, associated assets, and security device names for each task creation.

[0004] The above approach leads to the following technical problems: verification nodes in different network areas cannot establish semantic associations with security assets in the same domain through a unified classification identifier; erroneous cross-security domain association operations lack effective constraints during the configuration phase; incompletely configured nodes are included in the task and the problem is only exposed during the execution phase, resulting in distorted task results and ineffective consumption of test resources; the compliance of communication paths for cross-security domain node combinations cannot be perceived during the node combination confirmation phase, and configuration conflicts are delayed until the task execution phase. Summary of the Invention

[0005] This invention provides a dynamic configuration management method for verification nodes based on security domain labels and multi-level associations, which solves the technical problems in related technologies such as lack of constraints in the security domain ownership configuration of verification nodes, difficulty in maintaining the association between nodes and security assets, inaccurate judgment of the availability of candidate nodes during the task creation stage, and the need to manually fill in the task execution context configuration information.

[0006] This invention discloses a dynamic configuration management method for verification nodes based on security domain labels and multi-level associations, comprising the following steps: Construct a security domain label system and persistently store the security domain label metadata in the security domain label table. The security domain label table includes fields for unique label identifier, label name, label type, and enabled status. In the verification node configuration pop-up window, render the list of security domain labels in the enabled state using single-selection constraints, receive the security domain label selection results submitted by the administrator, and update the security domain label identifier field of the verification node configuration table. The system queries the list of security assets in the same domain that are enabled, using the selected security domain label as the filtering parameter. The filtered asset list is then rendered to a multi-select control. After the administrator confirms and submits, the old association record of the verification node in the intermediate association table is deleted and new binding records are inserted in batches using a database transaction. In the node selection stage of the task creation process, online status verification, operating system compatibility verification, and security domain configuration integrity verification are performed sequentially for each candidate node. The node selection control that fails the verification is set to a disabled state and a grayed-out reason prompt text is bound to it. During the task execution context construction phase, the security domain affiliation, associated security assets, and range service status of the selected verification node are read from the persistent configuration table, injected into the task execution context, and the names of the associated security assets are automatically populated into the security device name field of the log matching configuration item.

[0007] Furthermore, the security domain label types include system-built-in labels and administrator-defined labels; when a custom label creation request is received, the system sequentially performs checks for name non-empty, name length not exceeding a preset upper limit, and name duplication with existing labels. After all checks pass, the custom label is written to the security domain label table with the custom type and enabled status.

[0008] Furthermore, when rendering the list of verification nodes, the online status field of each node is read, and the configuration control of offline nodes is set to disable the attribute; the online status is dynamically calculated by the management terminal by comparing the difference between the current time and the timestamp of the last heartbeat of the node with a preset threshold.

[0009] Furthermore, the security domain configuration integrity verification is performed after both the online status verification and the operating system compatibility verification have passed; the three verification dimensions adopt short-circuit logic, and the verification of subsequent dimensions is stopped if any dimension fails.

[0010] Furthermore, before the task is executed, the target device type attribute of the selected attack case is automatically read, and a set matching operation is performed on the security asset device type field associated with the target verification node; if a matching asset exists, the asset is highlighted as an adapted asset, and if no matching asset exists, an adaptation warning is displayed in the verification configuration area.

[0011] Furthermore, it also includes the following steps: constructing a security domain access control policy matrix with security domain label identifiers as row and column indices. Matrix elements Storage source security domain To the target security domain The reachability status value, which can be either reachable, restricted, or unreachable; after the administrator determines the preferred node, the source security domain index of that node is read. For the matrix Perform row vector extraction to obtain reachability state vectors ,in and will Cache to the current configuration session context; traverse the candidate list of collaboration nodes, indexed by the target security domain of each candidate node. Search When the value is unreachable, the candidate node selection control is disabled; when the value is restricted, the constraint description field of the access control matrix table is read and the node is rendered in a warning style; when the value is reachable, normal optional rendering is maintained.

[0012] Furthermore, when the administrator selects the target endpoint corresponding to... When the value is restricted, query the transit security domain label identifier of the corresponding record in the access control matrix table. The security domain label is selected as The set of nodes that are active online and have passed the three-dimensional configuration integrity verification is used as the relay candidate node set. Generate a tag containing the source domain identifier. transit domain label identifier Target domain label identifier The path description object of the triplet .

[0013] Furthermore, when generating path description objects, with For the new source security domain index pair matrix Perform row vector extraction to obtain retrieval The value is specified; if the value is still restricted, the transit security domain query process is executed recursively and the new transit domain label is appended to the path description object until the reachability status of the path end domain to the target domain is reachable or the preset maximum hop limit is reached.

[0014] Furthermore, during the task execution context construction phase, the path description field in the task configuration record is read, and an execution sequence is generated when the path description object is a single-hop structure. When the path description object is a multi-hop structure, an execution sequence is generated. ,in The number of relay nodes is specified, and the execution sequence is written into the task scheduling configuration.

[0015] This invention discloses a dynamic configuration management system for verification nodes based on security domain labels and multi-level associations, comprising: The security domain label management module is used to build and persist the security domain label system, control the rendering logic of the single-selection constraint of the security domain drop-down list in the configuration pop-up window, and receive the security domain label selection results submitted by the administrator to update the verification node configuration table. The multi-level association binding module is used to perform dynamic filtering queries on security assets within the same domain using security domain labels as filtering parameters, and to manage the addition, deletion, and modification operations of many-to-many binding relationships between verification nodes and security assets in a database transaction manner. The task availability verification module is used to perform online status verification, operating system compatibility verification, and security domain configuration integrity verification on each candidate node in the node selection stage of the task creation process. The node selection control that fails the verification is set to a disabled state and a grayed-out reason prompt text is bound to it. The configuration information reuse module is used to read the security domain affiliation, associated security assets, and range service status of the selected verification node from the persistent configuration table during the task execution context construction phase, inject them into the task execution context, and perform compatibility verification between the security asset device type and the target device type of the attack case, as well as automatic filling of the security device name.

[0016] The beneficial effects of this invention are as follows: This invention solves the technical problem of lack of constraints on cross-security domain error association operations during the configuration phase by constructing a security domain label system and using security domain labels as filtering conditions to constrain the set of selectable security assets, and achieves the technical effect of eliminating cross-security domain error association operations from the configuration entry point.

[0017] This invention solves the technical problem that incompletely configured nodes are included in the task and the problem is only exposed during the execution phase by performing a three-dimensional configuration integrity check on the verification node during the task creation phase. It achieves the technical effect of moving the identification of configuration missing problems forward to before the task execution phase and avoiding the ineffective consumption of test resources.

[0018] This invention solves the technical problem of repeatedly entering configuration information for each task creation and causing configuration deviations due to manual entry by storing the verification node configuration information in a persistent configuration table decoupled from the task lifecycle and automatically injecting it during the task execution context construction phase. It achieves the technical effect of one-time configuration, reuse for multiple tasks, and automatic effect of configuration changes on subsequent tasks.

[0019] This invention solves the technical problem that path configuration conflicts in cross-security domain node combinations are delayed until the task execution stage by persistently maintaining the inter-security domain access control policy matrix and performing cross-domain path compliance verification during the node combination configuration stage. It achieves the technical effect of moving the path compliance verification sequence to the node combination confirmation stage and reducing task execution failures caused by cross-domain path configuration conflicts. Attached Figure Description

[0020] Figure 1 This is a flowchart of the verification node dynamic configuration management method provided in an embodiment of the present invention; Figure 2 This is a flowchart of the method for verifying the compliance of cross-domain paths of verification nodes provided in an embodiment of the present invention. Detailed Implementation

[0021] The subject matter described herein will now be discussed with reference to exemplary embodiments. It should be understood that these embodiments are discussed only to enable those skilled in the art to better understand and implement the subject matter described herein, and changes may be made to the function and arrangement of the elements discussed without departing from the scope of this specification. Various processes or components may be omitted, substituted, or added as needed in the examples. Furthermore, some features described in the examples may be combined in other examples.

[0022] Example 1 At least one embodiment of the present invention discloses a dynamic configuration management method for verification nodes based on security domain labels and multi-level associations, see [link to relevant documentation]. Figure 1 The process includes the following steps: Step 1: Build a security domain labeling system and configure the security domain affiliation for the verification nodes.

[0023] During the initialization phase, the management system constructs a unified security zone tag system and persistently stores tag metadata in the security zone tag table (security_zone_tag). The core fields of the security zone tag table include: tag unique identifier (tag_id, primary key, auto-incrementing integer), tag name (tag_name, string, maximum length 64 bytes), tag type (tag_type, enumeration, value is system or custom, corresponding to system built-in tags and administrator-defined tags respectively), creation time (create_time, timestamp), and tag activation status (status, boolean).

[0024] The system has seven built-in standard area labels, which correspond to typical functional areas in the enterprise network topology: office area, core area, business application area, DMZ area, Internet, testing area, and internal interconnection area.

[0025] The management console queries the list of verification nodes via a RESTful API (GET / api / v1 / agents). The API response data includes the online status field (online_status) for each verification node. When rendering the operation column, the frontend reads the online_status field value from each row of data objects and renders the interactive configuration button only for verification nodes with an online status of Online. For offline nodes, the button is either not rendered or grayed out.

[0026] After the administrator clicks the configuration button for the target verification node, the frontend sends an asynchronous request to the management system (GET / api / v1 / agents / {agent_id} / config) to retrieve the node's current complete configuration information and displays the configuration page as a modal pop-up. During the pop-up loading process, the system simultaneously sends a security zone label list query request (GET / api / v1 / security-zones), rendering all enabled security zone labels into a radio button dropdown list control and marking the security zone field as required. This radio button constraint ensures that the same verification node can belong to only one security zone label at any given time, eliminating ambiguity in subsequent asset filtering and task availability verification logic.

[0027] After the administrator completes the security zone selection, the frontend encapsulates the configuration data into a JSON request body and submits a configuration update request to the management end via HTTPS (PUT / api / v1 / agents / {agent_id} / config). The core fields of the request body include agent_id (the unique identifier of the verification node) and security_zone_tag_id (the unique identifier of the selected security zone tag). After receiving the request, the management end performs permission verification to confirm that the current operating account has the permission to manage the verification node configuration. Then, it updates the value of the security_zone_tag_id field of the corresponding node in the database verification node configuration table (agent_config) and records the configuration change timestamp. It then returns an HTTP 200 response to the frontend. After receiving the successful response, the frontend closes the configuration pop-up window and refreshes the verification node list, so that the security zone field displays the updated configuration result in real time.

[0028] It should be noted that the custom tags mentioned above in the security domain labels refer to non-system-built-in tags created by administrators through the security domain management function page by entering a custom name. When the management terminal receives a custom tag creation request, it sequentially performs name non-empty validation, name length validation (not exceeding 64 characters), and name duplication validation with existing tag names (including system-built-in and historical custom tags). After all validations pass, the tag is written to the database with a tag_type value of "custom" and a status value of "true". The newly added custom tag is then rendered in real-time in the front-end security domain selection list for subsequent use. This extension method enables the system to adapt to organizations with special network topology division requirements, such as non-standard area types like intra-city active-active zones in the financial industry or dedicated network isolation zones in government networks.

[0029] In this embodiment of the application, in order to prevent administrators from accidentally operating offline nodes, based on step 1, when the front end renders the verification node list, it reads the online_status field value of each node and sets the disabled attribute of the configuration button of the offline node, making it unclickable at the user interface level. This restricts the administrator to only perform configuration operations on nodes that can communicate normally from the configuration entry level, avoiding the problem of inconsistent configuration data and actual node status due to the configuration request not being able to reach the target node.

[0030] Step 2: Implement multi-level association and binding between verification nodes and security assets.

[0031] Based on the completed security domain configuration, the system manages many-to-many relationships between verification nodes and security assets using security domain tags, constructing a three-layer relationship architecture of security domains, security assets, and verification nodes. The system maintains an intermediate relationship table (agent_asset_mapping) to record the binding relationship between verification nodes and security assets. The core fields of the intermediate relationship table include: a unique identifier for the relationship record (mapping_id, primary key), a verification node identifier (agent_id, foreign key, associated verification node table), a security asset identifier (asset_id, foreign key, associated security asset table), a relationship creation time (bind_time, timestamp type), and an operator identifier (operator_id, associated account table).

[0032] The core fields of the security asset table include: asset unique identifier (asset_id), asset name (asset_name), security zone tag (security_zone_tag_id, foreign key related to the security zone tag table), asset device type (device_type, such as firewall, IDS / IPS, WAF, endpoint protection, etc.), asset IP address (asset_ip), and asset online status (asset_status).

[0033] Once the administrator selects a security zone tag in the configuration pop-up, the system immediately triggers a dynamic filtering operation on the security asset list: the front-end sends an asset list query request to the management end using the currently selected `security_zone_tag_id` as the filter parameter (GET / api / v1 / assets?security_zone_tag_id={tag_id}). The management end performs conditional filtering at the SQL query level (WHERE security_zone_tag_id = {tag_id} AND asset_status ='active'), returning only the list of security assets that have the same security zone tag as the current verification node and are in an enabled state. The front-end renders the filtered asset list into the multi-select list control of the security asset configuration item, ensuring that the set of assets visible to the administrator when making associated selections is strictly limited to the same security zone.

[0034] After an administrator selects one or more assets from the same-domain asset list, the front-end displays the names of the selected assets in a labeled format in the selected asset area of ​​the configuration pop-up window. Users can undo individual selections by clicking the remove icon on the label. After the administrator clicks the save button, the front-end encapsulates the list of selected asset `asset_id` values ​​as an integer array in the configuration update request body (field name: `asset_ids`), and submits it to the management end along with the security domain configuration information. The management end performs the following operations sequentially using database transactions: updates the `security_zone_tag_id` field in the verification node configuration table, deletes all old association records corresponding to the current `agent_id` in the intermediate association table, and batch inserts new association records. Each record contains the binding relationship between the current `agent_id` and each selected `asset_id`, as well as the `bind_time` timestamp and `operator_id`. The above operations are atomically guaranteed using database transactions, ensuring that the update of association relationships does not involve any intermediate dirty data states.

[0035] It should be noted that the cascading clear operation in the aforementioned same-domain asset filtering refers to the following operations performed by the system when an administrator modifies the security domain label after selecting a security domain and associating several security assets: clearing the currently selected security asset association list, re-querying and rendering the available asset list using the newly selected security domain label ID as the filtering condition, and displaying a prompt in the configuration pop-up window informing the administrator that the selected security assets have been automatically cleared after the security domain change. This cascading clear operation is only executed in the front-end memory before the user confirms the submission. The administrator can restore the original configuration by canceling the operation before confirming the submission, avoiding data pollution caused by asset association data under the old security domain being carried over to the new security domain configuration.

[0036] In this embodiment, to support scenarios where multiple verification nodes reference the same security asset in parallel, the intermediate association table allows multiple association records with the same asset_id but different agent_ids to coexist at the storage level. This approach is based on the fact that in actual BAS task scenarios, the same firewall device may simultaneously act as a protection node in multiple attack paths and be referenced by different verification node tasks. Restricting an asset to be associated with only one verification node would severely limit the system's parallel testing capabilities.

[0037] Step 3: Implement independent configuration and dynamic activation of the malicious simulation service.

[0038] The system supports configuring malicious simulation services (MSS) independently on the verification node configuration page. Two types of simulation services are available: RASP and HIDS. Administrators control the enabling or disabling of each simulation service using the corresponding toggle controls on the configuration page. When an administrator triggers the enabling of a simulation service, the system immediately displays a secondary confirmation prompt, requiring the administrator to explicitly confirm the operation intention to effectively prevent accidental triggering. After administrator confirmation, the system sends a service start command to the target verification node via asynchronous communication and displays the message "Range start command successfully sent, range status will synchronize shortly!" to the administrator, informing them that the command has been successfully sent but status synchronization requires a short wait. Subsequently, the system asynchronously updates the simulation service status on the front end, changing the service status icon from gray to blue to visually indicate that the range service has been successfully enabled. The RASP and HIDS range services will automatically provide the service address configuration basis when executing corresponding attack cases.

[0039] Step 4: Real-time synchronization and list display of the configuration status of verification nodes.

[0040] When the frontend initially loads the verification node list, it sends a full query request to the management console (GET / api / v1 / agents?page={page}&page_size={page_size}). The management console performs a combined query on the verification node table (agent), the verification node configuration table (agent_config), the intermediate association table (agent_asset_mapping), and real-time system performance data, returning the aggregated complete list of node information as a JSON array. Subsequent data updates employ an incremental update strategy. The management console only pushes or returns changed node data, and the frontend precisely locates and updates the corresponding row's display data in its local data cache based on the agent_id, avoiding page repainting and unnecessary bandwidth consumption caused by a full refresh.

[0041] The verification node list page includes the following data display fields: Node Name (agent_name field, sourced from the verification node table), Online Status (online_status field, dynamically calculated by the management based on the last heartbeat response time; if no heartbeat is received for more than 60 seconds beyond a preset threshold, it is considered offline), Operating System (os_type field, reported by the verification node during installation and registration and stored in the verification node table), Host Name (hostname field, sourced from the verification node table), IP Address (ip_address field, sourced from the verification node table, supports IPv4 and IPv6 formats), Security Zone (obtained by querying the security zone tag table from the security zone tag table via the security_zone_tag_id field in the verification node configuration table; if not configured, placeholder text is displayed with orange font to indicate missing configuration), and Security Assets (obtained by querying the security asset table via an intermediate association table to retrieve bound assets). The following data categories are displayed: Name list (placeholders are shown if no association is specified), HTTPS usage (use_https field, sourced from the verification node configuration table), SSL certificate verification status (ssl_verify field, sourced from the verification node configuration table), version (agent_version field, carried and reported by the verification node in heartbeat data), CPU usage (collected periodically by the verification node and reported via heartbeat data; displayed in orange when exceeding 80% and in red when exceeding 90%), memory usage (displayed and alerted in the same logic as the CPU usage field), disk usage (displayed and alerted in the same logic as the CPU usage field), network status (displayed by the management end based on the network connectivity self-check results carried in the node heartbeat data), process status (process liveness detection results carried and reported by the verification node in heartbeat data; the management end displays normal or abnormal based on this result), and installation time (register_time field, displayed in YYYY-MM-DD HH:mm:ss format, sourced from the verification node table).

[0042] It should be noted that the above-mentioned dynamic calculation of online status refers to the management end maintaining the timestamp of the last successful heartbeat of each verification node, updating the timestamp each time a node heartbeat is received, and comparing the difference between the current time and the last heartbeat timestamp with a preset threshold when responding to the list query interface. If the difference exceeds the threshold, the online_status field value is set to false in the response data. After the front end receives this value, it displays the node status as a red offline indicator.

[0043] Step 5: Implement availability verification of verification node tasks based on configuration integrity.

[0044] In the attack node selection and defense node selection stages of the task creation process, the system performs automated verification on each verification node in three dimensions. Nodes that pass the verification are rendered as optional, while nodes that fail the verification are rendered as grayed out and unselectable, and a prompt text explaining the reason for graying out is displayed when the mouse hovers over them.

[0045] The processing logic for the three verification dimensions is as follows.

[0046] The first dimension is node online status verification: The `online_status` field is read from the node list data. Only online nodes can pass this verification. For offline nodes, the front end renders a grayed-out state in their selection box, with a hover tooltip indicating that the node is currently offline. This guides the administrator to confirm that the node service is running normally and that it is network reachable from the management terminal before retrying.

[0047] The second dimension is operating system compatibility verification: Attack cases maintain an `os_compatibility` attribute in the system. This attribute defines the set of target operating system types supported by the attack case, with values ​​including Windows, Linux, macOS, or All. The system matches the `os_type` field value of the verification node with the `os_compatibility` set of the currently selected attack cases. If the verification node's operating system type is included in the set of compatible operating systems for the attack case, it passes this dimension's verification; otherwise, it is grayed out, and a hover message indicates that the node's operating system does not match the compatibility requirements of the current attack case.

[0048] The third dimension is the security zone configuration integrity verification: read the security_zone_tag_id field in the verification node configuration data. If the value of this field is null or empty, it is determined that the verification node has not completed the security zone configuration. Even if the verification of the first two dimensions passes, its selection box will still be grayed out and set to an uninteractive state. The hover prompt text indicates that the node has not yet been configured with a security zone, guiding the administrator to complete the security zone configuration before creating the task.

[0049] The verification logic for the above three dimensions is implemented in the front end using a combined judgment function. For each candidate node, the system performs the following judgments in sequence: if the online_status field value is not true, an unavailable status is returned with an explanation of "node offline"; if the node's operating system type does not match the os_compatibility set of the selected attack case, an unavailable status is returned with an explanation of "operating system incompatibility"; if the security_zone_tag_id field value is empty, an unavailable status is returned with an explanation of "security zone not configured"; if all three items pass, an available status is returned. When rendering the node selection list, the front end performs the above judgments for each node, determines the disabled attribute status of the node selection box based on the returned available status, and binds the explanation to the hover tooltip attribute of the selection box to display the explanation when the mouse hovers over it. The three-dimensional verification adopts short-circuit logic, that is, once the verification of a certain dimension fails, the verification of subsequent dimensions stops, reducing unnecessary computational overhead.

[0050] It should be noted that the aforementioned third-dimensional security domain configuration integrity verification, acting as a pre-interception gate, is a verification step performed only after the first and second-dimensional verifications have passed. In other words, security domain configuration integrity verification is only performed on online nodes that are compatible with the operating system. The verification order of the three dimensions is arranged from lowest to highest verification cost: online status verification only requires reading a single field, operating system compatibility verification requires performing set matching operations, and security domain configuration integrity verification requires reading configuration data. Short-circuit logic ensures that verifications with lower costs are executed first.

[0051] In this embodiment, to prevent incompletely configured nodes from being incorrectly included in the selectable state when the front-end fails to obtain the latest node configuration data due to interface anomalies, based on step 5, when the front-end detects an abnormality in node configuration data loading while rendering the node selection list, the system grays out the corresponding node by default and displays a global prompt at the top of the page explaining the node configuration data loading error, guiding the administrator to refresh the page and retry. This conservative strategy ensures that nodes with unknown states are not incorrectly marked as available in the event of missing data.

[0052] Step 6: Enable the automatic transfer and reuse of verification node configuration information during task execution.

[0053] Once a task is created and enters the execution phase, the system automatically reads the complete configuration information of each verification node selected for this task from the database when constructing the TaskExecution Context, and injects the complete configuration information into the TaskExecution Context data structure. The TaskExecution Context is constructed in the management terminal's memory as a JSON object and passed to the task scheduling engine through task execution parameters.

[0054] The following is an example of the field structure related to the verification node configuration information in the task execution context. The attacker_agents field stores the list of attacker verification nodes. Each record contains agent_id (unique node identifier), agent_name (node ​​name), security_zone (security zone name), security_zone_tag_id (security zone tag identifier), associated_assets (list of associated security assets, each asset contains asset_id, asset_name, device_type, and asset_ip fields), rasp_service_status (RASP range service enabled status), hids_service_status (HIDS range service enabled status), and the corresponding service access address field. The target_agents field stores the list of target verification nodes, and the field structure is consistent with that of the attacker nodes.

[0055] The system reads the security_zone field values ​​of the attacker's and target's verification nodes from the task execution context, and populates the attacker's security zone and target's security zone display fields in the verification configuration area of ​​the task details page, respectively. It also automatically reads the associated_assets list of each verification node and displays key information such as the name, device type and IP address of each associated security asset in the form of asset cards.

[0056] Before task execution, the system automatically performs device type compatibility checks between security assets and attack test cases. It reads the `target_device_type` attribute of the selected attack test case (indicating the target device type, such as WAF, IDS, firewall, etc.) and performs a set matching operation with the `device_type` field of the security assets associated with the target verification node. If an asset with a `device_type` matching the test case's `target_device_type` exists in the set of security assets associated with the target verification node, that asset is highlighted as a compatible asset. If no matching asset is found, a compatibility warning is displayed in the verification configuration area, indicating that no asset matching the selected test case type was found among the security assets associated with the current target node, guiding the administrator to confirm whether the asset configuration is complete or the test case selection is correct. This check provides compatibility warning information to the administrator without interrupting task execution.

[0057] When log matching is enabled for a task, the system reads the list of security assets associated with the target verification node from the task execution context. The `asset_name` field value of each security asset is automatically populated into the security device name input field of the log matching configuration item. If multiple associated assets exist, a dropdown selection is provided for the administrator to choose which asset's corresponding security device to use for log matching. This auto-fill operation is completed during the task execution context initialization phase. When the administrator enters the log matching configuration interface, the device name field is already pre-filled with the corresponding security asset name; only confirmation or minor adjustments are required.

[0058] It should be noted that the single data source principle for the automatic transmission of configuration information mentioned above means that the configuration information of the verification node (security domain affiliation, associated security assets, range service status and service address) is uniformly stored in the persistent configuration table of the database, decoupled from the lifecycle of specific tasks. Each time a task is created, the system reads the latest verification node configuration information from the database and injects it into the execution context of the current task, rather than copying the configuration information to the task storage. This ensures that multiple tasks involving the same verification node always reference the same persistent configuration data, and changes to the configuration information automatically take effect on all subsequent tasks based on that node.

[0059] In this embodiment of the application, in order to improve the integrity of automatic transmission of configuration information, in addition to step 6, the following steps are also included: When constructing the task execution context, the system reads the values ​​of the rasp_service_status and hiddens_service_status fields of the target verification node from the verification node configuration table, and automatically fills the corresponding service access address (rasp_service_url or hiddens_service_url) into the corresponding field of the task execution context according to the service enabling status. This enables the task scheduling engine to directly obtain the access address of the target service from the task execution context as the attack target address configuration parameter when executing attack cases that require the participation of the target service, without having to initiate a service address query to the database again during the task execution phase.

[0060] On the other hand, this invention also proposes a dynamic configuration management system for verification nodes based on security domain labels and multi-level associations, including: The security domain label management module is used to build and persist the security domain label system. It supports the storage of the system's built-in standard area labels and the creation, verification, and activation status maintenance of administrator-defined labels. It also controls the rendering logic of the security domain drop-down list in the configuration pop-up window and the interactive implementation of single-selection constraints. The multi-level association binding module is used to perform dynamic filtering queries on security assets within the same domain based on security domain labels, manage the addition, deletion, and modification operations of many-to-many binding relationships between verification nodes and security assets, and ensure the atomicity of updating association records with database transactions. The simulation service configuration module is used to control the start / stop status of the RASP range service and the HIDS range service, trigger a secondary confirmation prompt box, send a service start command to the target verification node through asynchronous communication, and synchronously update the service status icon from gray to blue. The configuration status display module is used to perform a joint query of the verification node table, verification node configuration table, intermediate association table and real-time performance collection data, and push the configuration status fields of the verification node list to the front end with an incremental update strategy, including information such as security domain, security assets, online status and resource utilization. The task availability verification module is used to perform online status verification, operating system compatibility verification, and security domain configuration integrity verification on each candidate node in the node selection stage of the task creation process. The node selection box that fails the verification is set to the disabled state and a grayed-out prompt text is attached. The configuration information reuse module is used to automatically read complete configuration information such as the security domain affiliation, associated security assets, and range service status of the selected verification node from the persistent configuration table during the task execution context construction phase, inject it into the task execution context, and perform compatibility verification between the security asset device type and the target device type of the attack case, as well as automatic filling of the security device name in the log matching configuration item.

[0061] By way of example, the system proposed in this invention may also include various features and combinations thereof in the method embodiments, which will not be elaborated here.

[0062] This invention establishes a security domain labeling system within the BAS system, enabling each verification node to obtain a clear network region affiliation label. During the security asset association configuration phase, security domain labels are used as filtering conditions to constrain the set of selectable assets, eliminating erroneous cross-security domain association operations at the configuration entry point. Security domain labels also serve as a third dimension for task availability verification, performing pre-interception on nodes with incomplete configurations during the task creation phase. This ensures that configuration deficiencies are identified before the task enters the execution phase, avoiding task execution anomalies and ineffective consumption of test resources due to incomplete node configurations.

[0063] By storing the configuration information of verification nodes in a persistent configuration table decoupled from the task lifecycle, and automatically reading and injecting relevant configuration information during the task execution context construction phase, the system automatically displays fields such as security domain affiliation, associated asset information, and security device name in the verification configuration area of ​​the task details page. This eliminates the need for administrators to repeatedly enter this information each time a task is created, and also eliminates the risk of configuration deviations such as spelling errors and asset omissions caused by manual entry. The single data source principle ensures that multiple tasks involving the same verification node reference the same persistent configuration data, and changes to the configuration information automatically take effect for subsequent tasks, achieving the engineering effect of "configure once, reuse for multiple tasks".

[0064] Example 2 Building upon the security domain labeling system and multi-level associated configuration management method established in Example 1, Example 1 uses a single verification node as the smallest verification granularity, confirming the availability of a single node through three-dimensional verification during the task creation phase. However, in actual BAS task scenarios, attack and defense confrontation tests often require combining verification nodes belonging to different network areas into collaborative configuration units. The above method only performs security domain configuration integrity verification at the single node level, without verifying the compliance of cross-security domain communication paths at the node combination level. When two nodes belonging to different security domains are combined into a collaborative configuration unit, if there are access control policy constraints between the two security domains (such as restricted paths or completely unreachable paths restricted by firewall policies), these constraints cannot be perceived during the node combination confirmation phase. This causes configuration conflicts to be delayed until the task execution phase, resulting in invalid task execution results and misleading configuration status feedback.

[0065] Based on the security domain labeling system and verification node configuration management method established in Example 1, this embodiment further provides a cross-domain node combination path compliance verification method based on the inter-security domain access control policy matrix, which moves the verification timing of cross-security domain communication path constraints from the task execution stage to the node combination configuration stage.

[0066] At least one embodiment of the present invention discloses a dynamic configuration management method for verification nodes based on security domain labels and multi-level associations, see [link to relevant documentation]. Figure 2 This includes the following steps: Step 2-1: Build and persist the security domain access control policy matrix.

[0067] The management system maintains a two-dimensional matrix indexed by security zone tag IDs (security_zone_tag_id), denoted as the inter-zone access control policy matrix. , where matrix elements Storage source security domain To the target security domain The direct reachability state value, and All are enumerated indices identifying enabled state security domain labels. The state value range is limited to three discrete values: REACHABLE, RESTRICTED, and UNREACHABLE. The number of rows and columns of the matrix equals the total number of currently enabled security domain labels in the system, i.e., the matrix size is [matrix size missing]. ,in The number of state-secure domain labels enabled.

[0068] The system writes data to the inter-zone access control policy matrix in two ways: First, through automatic parsing, the system parses the source address range, target address range, and action field from the enterprise firewall policy configuration file (such as an ACL rule list or a security policy export file), maps the parsing results to the corresponding security zone label identifier, and updates the status value of the corresponding element in the inter-zone access control policy matrix using the mapped row and column index as the locator key. Second, through manual input, the administrator submits the source security zone identifier, target security zone identifier, and corresponding reachability status value one by one through the security zone access control policy configuration interface (PUT / api / v1 / security-zone-matrix) provided by the management terminal. After receiving the request, the management terminal performs parameter validity verification to confirm that both the source and target domain identifiers exist in the enabled records of the security zone label table. Then, it updates the entry to the inter-zone access control policy matrix data structure and persists it to the access control matrix table (zone_access_matrix) in the configuration management storage layer.

[0069] The core fields of the access control matrix table include: a unique record identifier (matrix_id, primary key, auto-incrementing integer), a source security zone tag identifier (src_zone_tag_id, foreign key, associated with the security zone tag table), a destination security zone tag identifier (dst_zone_tag_id, foreign key, associated with the security zone tag table), a reachability status value (reachability, enumeration type, values ​​are REACHABLE, RESTRICTED, or UNREACHABLE), a restricted path constraint description (restriction_desc, string type, only populated when reachability is RESTRICTED), a transit security zone tag identifier (transit_zone_tag_id, integer type, can be null, only populated when reachability is RESTRICTED, foreign key associated with the security zone tag table), and the last update time (update_time, timestamp type).

[0070] It should be noted that the aforementioned restricted path constraint description field (restriction_desc) refers to a textual description of the access constraints between the source security domain and the target security domain, such as allowing communication only on specific ports, requiring forwarding through a proxy device, or having bandwidth limitations. This description field is read and displayed to the administrator in the rendering prompt of the restricted node combination, enabling the administrator to understand the specific path constraint content during the configuration phase, rather than just receiving an abstract restricted status label.

[0071] In this embodiment of the application, in order to enable the inter-domain access control policy matrix to automatically keep synchronized with changes in enterprise network security policies, based on step 2-1, a periodic task of automatically re-parsing the firewall policy configuration file can be configured to be executed periodically. After each re-parsing is completed, the new parsing result is compared with the existing records in the access control matrix table one by one, the records that have changed are updated and written, and a change summary log is generated for the administrator to review. This allows the inter-domain access control policy matrix to track policy changes without the need for manual maintenance by the administrator in the automatic parsing scenario.

[0072] Step 2-2: Extract the source security domain reachability state vector of the preferred node.

[0073] In the node selection phase of the task creation process, the system has already distinguished candidate nodes into available and unavailable states through the three-dimensional verification in step 5 of Example 1. After the administrator determines the preferred node (i.e., the source node in the collaborative configuration unit, such as the attack node) from the available nodes, the system reads the security domain label identifier of that node from the node configuration data and records it as the source security domain index. .

[0074] by For row indexing, the inter-security domain access control policy matrix Perform row vector extraction to obtain the source security domains into the entire system. Reachability state vectors of each security domain ,in , An enumeration index for identifying the target security domain label. The range of values ​​is all in the system. An enabled state security domain label identifier. The cache is stored in the current configuration session context so that subsequent steps can read it directly within the same configuration session, avoiding repeated queries to the security domain access control policy matrix.

[0075] It should be noted that the above-mentioned configuration session context refers to the temporary data structure maintained by the management terminal in the server memory for the current operation request during the period from the completion of the preferred node selection operation to the final submission of the node combination configuration. This data structure is cleared after the administrator submits or cancels the current configuration operation. Its life cycle strictly corresponds to the interaction flow of a single node combination configuration operation and is not persisted across configuration sessions.

[0076] Steps 2-3: Perform differentiated rendering on the candidate list of collaborative nodes based on the reachability state vector.

[0077] During the data rendering phase of the collaborative node candidate list (i.e., target nodes, such as defense nodes or target nodes), the system traverses all candidate nodes in the node resource pool that have passed the three-dimensional verification in step 5 of embodiment one, and reads the security domain label identifier of each candidate node, which is recorded as the target security domain index. From the session context cache Search The element values ​​are used to process the rendering state of each candidate node according to the following rules: when When the value is UNREACHABLE, the selection control of the candidate node is set to disabled, and the cross-domain unreachable label information is written into the rendering data of the node. The node is rendered in gray in the node list, and a prompt text indicating that the source security domain and the target security domain are unreachable is displayed when the mouse hovers over it.

[0078] when When the value is RESTRICTED, the rendering flag of the candidate node is set to a warning level, and the value is read from the access control matrix table. and The recorded restriction_desc field value is used to write the constraint description text into the node's rendering data as a hover tooltip. The node is rendered in the node list in a warning style (such as an orange highlight). Administrators can still select the node but will be aware that the path has constraints.

[0079] when When the value is REACHABLE, the rendering state of the candidate node remains normal and selectable, which is consistent with the rendering logic of the node that passes the verification in step 5 of Example 1.

[0080] The above rendering logic processes are as follows: using candidate nodes... For index retrieval If the value is UNREACHABLE, a disabled state is returned along with the message "Unreachable between the source security domain and the target security domain"; if the value is RESTRICTED, the access control matrix table is queried to obtain the value of the restriction_desc field, a warning state is returned along with a description of the constraint; if the value is REACHABLE, a normal selectable state is returned. The front-end performs the corresponding rendering operation on each candidate node based on the above results.

[0081] It should be noted that the rendering objects in the above list of collaborative nodes are only those nodes that have passed the three-dimensional verification in step 5 of Example 1, namely, nodes that are online, have operating system compatibility, and have completed security domain configuration. The cross-domain reachability rendering process in this step is executed after the three-dimensional verification. The constraints of the two types of verifications are independent of each other and there is no substitution relationship between them.

[0082] Steps 2-4: Perform transit security domain queries on the restricted paths and generate multi-hop path description data.

[0083] Receive the target node selection result submitted by the administrator and read the security domain label identifier of the target node. From the session context cache Search The value of ; when the value is RESTRICTED, the following processing flow is executed: Query from the access control matrix table and The recorded value of the `transit_zone_tag_id` field is recorded as the transit security zone tag identifier. .by To filter the node resource pool, a query is performed with the following criteria: security domain label identifier equal to... If the online status is active and has passed the three-dimensional configuration integrity verification in step 5 of Example 1, the set of filtered results will be recorded as the transit candidate node set. .Will The list of recommended relay nodes is output to the configuration interface for administrators to select specific relay nodes; at the same time, a list containing source domain tags is generated. transit domain label identifier Target domain label identifier The multi-hop path description data of triples is denoted as a path description object. .

[0084] when When the value is REACHABLE, the generator is generated by Directly pointing The single-hop path description data is denoted as a path description object. This does not trigger the transit node query process.

[0085] It should be noted that the set of transit candidate nodes in the above transit security domain query... This refers to the security domain label being identified as Within the security domain, the set of nodes that satisfy online status and configuration integrity constraints. Set of relay candidate nodes. It may be empty, when When the value is empty, the system displays a prompt message on the configuration interface indicating that there are currently no available nodes in the transit security domain required for the current restricted path, guiding the administrator to confirm the node status in the transit security domain or adjust the node combination scheme, without forcibly blocking the administrator's configuration submission operation.

[0086] In this embodiment of the application, in order to support multi-segment transit path scenarios (i.e., the situation where the path from the source security domain to the target security domain needs to pass through two or more transit security domains), in addition to steps 2-4, the following step is also included: when generating the path description object, the transit security domain is used as the reference. For the new source security domain index, the inter-security domain access control policy matrix is... Obtain by performing row vector extraction operation ,in , An enumerated index identifying the target security domain label; retrieval The value is set; if the value is still RESTRICTED, the transit security domain query process is executed recursively, and the new transit domain label is appended to the path description object until the reachability status from the end domain of the path to the target domain is REACHABLE or the preset maximum number of hops is reached, generating multi-hop path description data containing an ordered sequence of all transit domain labels.

[0087] Steps 2-5: Write the path description data into the task configuration record and generate multiple ordered execution sequences.

[0088] The task execution context construction process in step 6 of Example 1 is extended as follows: When writing the task configuration record, the confirmed node combination identifier (including the preferred node identifier and the target end node identifier), the reachability status value from the source domain to the target domain, and the path description object are included. Also write the path description field (path_desc, stored in JSON format) into the task configuration record (task_config table).

[0089] During the task execution context construction phase, the `path_desc` field value of the current task is read from the task configuration record, and the node execution sequence is generated according to the following rules: when the path description object... In a single-hop structure, a two-node execution sequence is generated, where the first-choice node directly points to the target node. This execution sequence is denoted as... ,in As the preferred node identifier, Identify the target endpoint node; when the path description object In the case of a multi-hop structure, the administrator-confirmed transit node identifiers are retrieved sequentially from the transit candidate node set output in steps 2-4 according to the order of the transit domain labels, generating a multi-segment ordered execution sequence containing all transit nodes, denoted as . ,in to These are the identifiers of the transit nodes arranged in order of the path. The number of relay nodes is set, and the execution sequence is written into the task scheduling configuration so that the task scheduling engine can drive each node to execute the corresponding attack and defense test behaviors in sequence.

[0090] The JSON data structure of the path description field (path_desc) contains the following fields in the top-level object: the hop_type field takes the value single or multi, corresponding to single-hop and multi-hop path structures respectively; the path field is an ordered array containing the security domains on the path and their corresponding node identifiers. Each record in the array contains three fields: zone_tag_id (security domain tag identifier), zone_name (security domain name), and agent_id (node ​​identifier); the execution_sequence field is a list of node execution order directly read by the task scheduling engine, where the order of node identifiers strictly corresponds to the order of security domain tag identifiers in the path field; and the reachability field stores the overall reachability status value of the current path.

[0091] It should be noted that the order of the node identifiers in the above execution_sequence field strictly corresponds to the order of the security domain labels in the path description object. The task scheduling engine issues execution instructions to each node in this order, and the execution status report of the preceding node serves as the trigger condition for the subsequent node to start, thereby realizing the orderly transmission of attack and defense traffic between security domain nodes in multi-hop path scenarios.

[0092] On the other hand, this invention also proposes a cross-domain node path compliance verification system based on an inter-domain access control policy matrix, comprising: The policy matrix management module is used to build and persist the inter-domain access control policy matrix. It supports two data writing methods: automatic parsing and writing from firewall policy configuration files and manual entry by administrators. It also maintains the reachability status value, restricted path constraint description, and transit security domain label identification field for each security domain pair in the access control matrix table. The reachability vector extraction module is used to read the source security domain index of a node after the administrator has determined the preferred node. Inter-domain access control policy matrix Perform row vector extraction to obtain reachability state vectors. and will Cache to the current configuration session context; The differential rendering module is used to traverse the entire list of candidate collaborative nodes that have passed the three-dimensional verification, indexed by the target security domain of each candidate node. Search The value of restriction_desc is used to perform differentiated rendering on candidate nodes according to three states: unreachable, restricted, and reachable, respectively, as well as graying out and disabling, orange warning and normal selectability, and the value of restriction_desc field is bound to the hover tooltip of the warning node; The multi-hop path generation module is used to query the `transit_zone_tag_id` field value in the access control matrix table after the administrator selects a target node with a restricted state, and filter the set of transit candidate nodes that meet the configuration integrity constraints. It supports recursive generation of multiple transit paths and outputs a path description object containing an ordered sequence of all transit field labels. ; The execution sequence construction module is used to read the path_desc field value from the task configuration record during the task execution context construction phase, and generate the node execution sequence according to the order of the security domain labels in the path description object. The execution sequence is written into the task scheduling configuration so that the task scheduling engine can drive each node to perform attack and defense test behaviors in sequence.

[0093] By way of example, the system proposed in this invention may also include various features and combinations thereof in the method embodiments, which will not be elaborated here.

[0094] This invention extends the scope of security domain labels from single-node configuration integrity verification in Example 1 to cross-domain communication path compliance verification in node pair combination scenarios by persistently maintaining the inter-security domain access control policy matrix on the management side. During the rendering phase of the collaborative node candidate list, the system performs real-time retrieval of the cross-domain reachability status of each candidate node based on the source security domain reachability state vector of the preferred node, thus pre-positioning path compliance information to the configuration interaction layer in a differentiated rendering state manner. Unreachable combinations are blocked by disabled controls during the node selection phase, preventing administrators from submitting configurations for unreachable node combinations, fundamentally eliminating invalid configuration writes caused by cross-domain unreachability. Restricted combinations receive explicit constraint descriptions during the selection phase, allowing administrators to understand the existence of specific path constraints before confirming the selection, rather than passively receiving failure feedback during task execution.

[0095] For restricted paths, the system further extracts transit security domain information from the inter-security domain access control policy matrix and filters a set of transit candidate nodes that meet configuration integrity constraints. The restricted path is then transformed into an executable multi-hop path description object. During the task execution context construction phase, a multi-segment ordered execution sequence containing all transit nodes is generated. This allows the task scheduling engine to drive attack and defense test traffic transmission according to the node order that conforms to the security domain access control policy constraints, without needing to handle path compliance issues again during the task execution phase. This implementation moves the verification timing of cross-domain path constraints from the task execution phase to the node combination configuration confirmation phase. This allows the configuration management system to output a multi-level associated node configuration scheme that conforms to the security domain access control policy constraints during the node combination confirmation phase, thereby reducing task execution failures and ineffective consumption of test resources caused by cross-domain path configuration conflicts.

[0096] The embodiments of the present invention have been described above. However, the embodiments are not limited to the specific implementation methods described above. The specific implementation methods described above are merely illustrative and not restrictive. Those skilled in the art can make more equivalent embodiments under the guidance of the present embodiments, and all of them are within the protection scope of the present embodiments.

Claims

1. A dynamic configuration management method for verification nodes based on security domain labels and multi-level associations, characterized in that, Includes the following steps: Construct a security domain label system and persistently store the security domain label metadata in the security domain label table. The security domain label table includes fields for unique label identifier, label name, label type, and enabled status. In the verification node configuration pop-up window, render the list of security domain labels in the enabled state using single-selection constraints, receive the security domain label selection results submitted by the administrator, and update the security domain label identifier field of the verification node configuration table. The system queries the list of security assets in the same domain that are enabled, using the selected security domain label as the filtering parameter. The filtered asset list is then rendered to a multi-select control. After the administrator confirms and submits, the old association record of the verification node in the intermediate association table is deleted and new binding records are inserted in batches using a database transaction. In the node selection stage of the task creation process, online status verification, operating system compatibility verification, and security domain configuration integrity verification are performed sequentially for each candidate node. The node selection control that fails the verification is set to a disabled state and a grayed-out reason prompt text is bound to it. During the task execution context construction phase, the security domain affiliation, associated security assets, and range service status of the selected verification node are read from the persistent configuration table, injected into the task execution context, and the names of the associated security assets are automatically populated into the security device name field of the log matching configuration item.

2. The dynamic configuration management method for verification nodes based on security domain labels and multi-level associations according to claim 1, wherein, The security domain label types include system-built-in labels and administrator-defined labels. When a custom label creation request is received, the system sequentially performs checks for name non-empty, name length not exceeding a preset limit, and name duplication with existing labels. After all checks pass, the custom label is written to the security domain label table with the custom type and enabled status.

3. The dynamic configuration management method for verification nodes based on security domain labels and multi-level associations according to claim 1, wherein, When rendering the list of verification nodes, the online status field of each node is read, and the configuration control of offline nodes is set to disable the attribute; the online status is dynamically calculated by the management terminal by comparing the difference between the current time and the timestamp of the last heartbeat of the node with a preset threshold.

4. The dynamic configuration management method for verification nodes based on security domain labels and multi-level associations according to claim 1, wherein, The security domain configuration integrity verification is performed after both the online status verification and the operating system compatibility verification have passed. The three verification dimensions employ short-circuit logic; verification of subsequent dimensions is halted if any dimension fails verification.

5. The dynamic configuration management method for verification nodes based on security domain labels and multi-level associations according to claim 1, wherein, Before the task is executed, the target device type attribute of the selected attack case is automatically read, and a set matching operation is performed on the security asset device type field associated with the target verification node. If a matching asset exists, the asset is highlighted as an adapted asset. If no matching asset exists, an adaptation warning is displayed in the verification configuration area.

6. The dynamic configuration management method for verification nodes based on security domain labels and multi-level associations according to claim 1, wherein, It also includes the following steps: Construct a security domain access control policy matrix with security domain labels as row and column indexes. Matrix elements Storage source security domain To the target security domain The reachability state value, wherein the reachability state value is reachable, restricted, or unreachable; After the administrator determines the preferred node, the source security domain index of that node is read. For the matrix Perform row vector extraction to obtain reachability state vectors ,in and will Cache to the current configuration session context; Traverse the candidate list of collaborative nodes, indexed by the target security domain of each candidate node. Search When the value is unreachable, the candidate node selection control is disabled; when the value is restricted, the constraint description field of the access control matrix table is read and the node is rendered in a warning style; when the value is reachable, normal optional rendering is maintained.

7. The dynamic configuration management method for verification nodes based on security domain labels and multi-level associations according to claim 6, wherein, When the administrator selects the target node corresponding to When the value is restricted, query the transit security domain label identifier of the corresponding record in the access control matrix table. The security domain label is selected as The set of nodes that are active online and have passed the three-dimensional configuration integrity verification is used as the relay candidate node set. Generate a tag containing the source domain identifier. transit domain label identifier Target domain label identifier The path description object of the triplet .

8. The dynamic configuration management method for verification nodes based on security domain labels and multi-level associations according to claim 7, wherein, When generating a path description object, with For the new source security domain index pair matrix Perform row vector extraction to obtain retrieval The value is specified; if the value is still restricted, the transit security domain query process is executed recursively and the new transit domain label is appended to the path description object until the reachability status of the path end domain to the target domain is reachable or the preset maximum hop limit is reached.

9. The dynamic configuration management method for verification nodes based on security domain labels and multi-level associations according to claim 7, wherein, During the task execution context construction phase, the path description field in the task configuration record is read. When the path description object is a single-hop structure, an execution sequence is generated. When the path description object is a multi-hop structure, an execution sequence is generated. ,in The number of relay nodes is specified, and the execution sequence is written into the task scheduling configuration.

10. A dynamic configuration management system for verification nodes based on security domain labels and multi-level associations, characterized in that, include: The security domain label management module is used to build and persist the security domain label system, control the rendering logic of the single-selection constraint of the security domain drop-down list in the configuration pop-up window, and receive the security domain label selection results submitted by the administrator to update the verification node configuration table. The multi-level association binding module is used to perform dynamic filtering queries on security assets within the same domain using security domain labels as filtering parameters, and to manage the addition, deletion, and modification operations of many-to-many binding relationships between verification nodes and security assets in a database transaction manner. The task availability verification module is used to perform online status verification, operating system compatibility verification, and security domain configuration integrity verification on each candidate node in the node selection stage of the task creation process. The node selection control that fails the verification is set to a disabled state and a grayed-out reason prompt text is bound to it. The configuration information reuse module is used to read the security domain affiliation, associated security assets, and range service status of the selected verification node from the persistent configuration table during the task execution context construction phase, inject them into the task execution context, and perform compatibility verification between the security asset device type and the target device type of the attack case, as well as automatic filling of the security device name.

Images