A digital scheduling method for the entire process of laboratory testing tasks

Abstract

This application provides a full-chain digital scheduling method for laboratory testing tasks, including: decomposing the attack chain stages of laboratory threat assessment testing task requirements information to generate a testing task scenario feature vector table with attack chain stage labels; constructing a multi-dimensional profile of the technical capabilities of existing laboratory testing resources based on the testing task scenario feature vector table to generate a testing resource technical capability matrix with attack chain stage correlation coefficients; generating a task-resource scheduling configuration table with risk level identifiers based on the testing resource technical capability matrix; performing digital instruction hierarchical encoding on the task-resource scheduling configuration table to generate a scheduling execution and anomaly handling record table with instruction time-series trajectories; and calling a two-dimensional performance-delay model of scheduling strategies to generate strategy scheduling parameters adapted to the full-chain scheduling requirements for full-chain digital scheduling of laboratory testing tasks.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and more specifically, to a digital scheduling method for the entire chain of laboratory testing tasks. Background Technology

[0002] In the field of laboratory threat assessment, detection tasks require the coordination of multiple types of detection resources, such as vulnerability scanning, traffic simulation, and data capture, to achieve comprehensive coverage and accurate verification of attack behaviors. As the complexity of threat scenarios increases, detection tasks often exhibit multi-stage progressive characteristics, placing higher demands on the stage adaptability, end-to-end controllability, and dynamic optimization capabilities of resource scheduling. Efficient scheduling mechanisms are needed to ensure the execution efficiency and accuracy of detection tasks.

[0003] An existing laboratory testing task scheduling scheme first categorizes laboratory threat assessment testing tasks according to testing targets (such as servers and network devices); then establishes a static resource ledger based on the hardware specifications of testing resources (such as processor models and memory capacity); and finally, it distributes the tasks evenly according to the total number of tasks after categorization and the number of devices in the resource ledger to generate a basic scheduling plan.

[0004] The existing solution relies solely on matching task objectives with resource hardware specifications, failing to link the core requirements of each stage of the detection task with the specific capabilities of the resources. This can easily lead to a mismatch between resources and task stage requirements (such as using resources that are good at traffic simulation to perform vulnerability detection tasks). At the same time, it lacks a mechanism for recording the trajectory of the scheduling plan execution process and providing feedback on the results, making it impossible to optimize subsequent scheduling parameters based on the actual execution situation. This makes it difficult to meet the accuracy and continuous adaptation requirements of end-to-end scheduling in threat assessment scenarios. Summary of the Invention

[0005] To address the aforementioned technical problems, this application provides a digital scheduling method for the entire laboratory testing task chain, which can at least alleviate the aforementioned technical problems.

[0006] The technical solutions provided in this application are as follows:

[0007] A method for end-to-end digital scheduling of laboratory testing tasks includes: Step 1, decomposing the attack chain stages of laboratory threat assessment testing task requirements information to generate a testing task scenario feature vector table with attack chain stage labels; Step 2, constructing a multi-dimensional profile of the technical capabilities of existing laboratory testing resources based on the testing task scenario feature vector table to generate a testing resource technical capability matrix with attack chain stage correlation coefficients; Step 3, generating a task-resource scheduling configuration table with risk level identifiers based on the testing resource technical capability matrix; Step 4, performing digital instruction hierarchical encoding on the task-resource scheduling configuration table to generate a scheduling execution and anomaly handling record table with instruction time-series trajectories; Step 5, based on the scheduling execution and anomaly handling record table with instruction time-series trajectories, calling a two-dimensional performance-delay model of the scheduling strategy to generate strategy scheduling parameters adapted to the end-to-end scheduling requirements for end-to-end digital scheduling of laboratory testing tasks.

[0008] The end-to-end digital scheduling method for laboratory testing tasks provided in this application has the following specific technical advantages:

[0009] 1. In this application, step 1 decomposes the attack chain stage of the detection task requirement information and generates a feature vector table with attack chain stage labels. Compared with the traditional method of classifying the detection target as a whole, it can more clearly decompose the specific requirements of the detection task at each attack chain stage, providing a clear basis for the accurate matching of subsequent resources and stage requirements, and alleviating the problem of "mismatch between resources and task stage requirements" from the task requirement side.

[0010] 2. In this application, step 2 constructs a multi-dimensional profile of resource technical capabilities based on the feature vector table with stage labels and generates a matrix with attack chain stage correlation coefficients. Compared with the traditional ledger that only records hardware specifications, this matrix can intuitively reflect the degree of correlation between each detection resource and the requirements of different attack chain stages, making the matching of resource-specific capabilities with stage requirements more targeted and further reducing the situation of "using incompatible resources to perform corresponding stage tasks".

[0011] 3. In this application, step 4 generates a scheduling execution and exception handling record table with instruction time sequence trajectory by digitally encoding the task-resource scheduling configuration table. Compared with the traditional method without trajectory recording, it can completely trace the execution process of scheduling instructions and the exception handling situation, providing data support for subsequent scheduling optimization and solving the problem of "no execution process data to rely on".

[0012] 4. In this application, step 5 uses a two-dimensional performance-delay model based on a record table with time-series trajectories to generate policy scheduling parameters that adapt to the full-link requirements. Compared with the traditional scheduling method without feedback optimization, it can transform historical execution data into a basis for optimizing scheduling parameters, making subsequent scheduling more in line with the full-link requirements of laboratory threat assessment, improving the continuous adaptability of scheduling, and alleviating the problem of "difficulty in meeting the requirements of full-link scheduling accuracy and continuous adaptability". Attached Figure Description

[0013] Figure 1 This is a flowchart illustrating a full-chain digital scheduling method for laboratory testing tasks, as described in an embodiment of this application.

[0014] Figure 2 This is a schematic diagram of the structure of a full-link digital scheduling device for laboratory testing tasks according to an embodiment of this application. Detailed Implementation

[0015] Figure 1 This is a flowchart illustrating a full-chain digital scheduling method for laboratory testing tasks according to an embodiment of this application. Figure 1 As shown, a digital scheduling method for the entire chain of laboratory testing tasks includes:

[0016] Step 1: Decompose the attack chain stages of the laboratory threat assessment and detection task requirements information to generate a detection task scenario feature vector table with attack chain stage labels.

[0017] Step 2: Based on the feature vector table of the detection task scenario, construct a multi-dimensional profile of the technical capabilities of the laboratory's existing detection resources to generate a detection resource technical capability matrix with attack chain stage correlation coefficients;

[0018] Step 3: Generate a task-resource scheduling configuration table with risk level identifiers based on the detection resource technical capability matrix;

[0019] Step 4: Perform digitized instruction layered encoding on the task-resource scheduling configuration table to generate a scheduling execution and exception handling record table with instruction timing trajectories;

[0020] Step 5: Based on the scheduling execution and anomaly handling record table with instruction timing trajectory, call the two-dimensional performance-delay model of the scheduling strategy to generate strategy scheduling parameters that adapt to the full-link scheduling requirements for full-link digital scheduling of laboratory testing tasks.

[0021] Optionally, step 1 specifically involves: breaking down the laboratory threat assessment and detection task requirements information according to the attack chain stages in the threat assessment scenario to obtain the detection requirement sub-items corresponding to each stage of the attack chain, so as to generate a detection task scenario feature vector table with attack chain stage labels.

[0022] Optionally, step 1 specifically includes step 11, breaking down the laboratory threat assessment and detection task requirement information into attack chain stages under the threat assessment scenario to obtain the reconnaissance and detection stage, vulnerability exploitation stage, lateral movement stage, data theft stage, and attack withdrawal stage, and determining the detection requirement sub-items corresponding to each stage of the attack chain.

[0023] Preferably, the specific implementation process of step 11 is as follows: Taking the laboratory threat assessment and detection task requirement information (including core content such as task objectives, attack scenarios to be covered, vulnerability types to be verified, and expected detection cycle) as the processing object, firstly, based on the progressive logic of attack behavior in the laboratory threat assessment scenario (the complete attack path from initial detection to final withdrawal), the boundary standards of each stage of the attack chain are divided—where the reconnaissance and detection stage corresponds to "the attacker's behavior of obtaining basic information about the target", the vulnerability exploitation stage corresponds to "the attacker's behavior of attempting to break through by exploiting the target vulnerability", the lateral movement stage corresponds to "the attacker's behavior of expanding the control range in the target's internal network", the data theft stage corresponds to "the attacker's behavior of extracting the target's core data", and the attack withdrawal stage corresponds to "the attacker's behavior of clearing traces and escaping control", thus obtaining the attack chain stage boundary definition table;

[0024] Using the attack chain stage boundary definition table as a reference, the requirements for each stage are extracted from the laboratory threat assessment and detection task requirements information: For the reconnaissance and detection stage, key requirements such as "the target IP range to be detected, the port types to be scanned (such as common TCP ports, specific UDP ports), and the device fingerprint information to be identified" are extracted and integrated into the detection requirements sub-items for the reconnaissance and detection stage; For the vulnerability exploitation stage, key requirements such as "the vulnerability number to be verified (such as CVE-2024-XXX), the environment configuration required for vulnerability exploitation (such as operating system version, dependent component version), and the successful exploitation judgment indicators to be detected" are extracted and integrated into the detection requirements sub-items for the vulnerability exploitation stage.

[0025] Continuing with the attack chain phase boundary definition table as a reference, the requirements for the remaining phases are processed as follows: For the lateral movement phase, key requirements such as "the internal network path to be simulated (e.g., from the web server to the database server), the permission switching methods to be verified (e.g., via remote desktop, command line tools), and the lateral movement traffic characteristics to be monitored" are extracted to form the lateral movement phase detection requirements. For the data theft phase, key requirements such as "the core data types to be protected (e.g., user privacy data, business-sensitive data), the data transmission channels to be detected (e.g., HTTP, FTP, covert tunnels), and the threshold for judging data theft behavior (e.g., the upper limit of the amount of data transmitted in a single transaction)" are extracted to form the data theft phase detection requirements. For the attack withdrawal phase, key requirements such as "the trace clearing behavior to be monitored (e.g., log deletion, process cleanup), the backdoor residue detection methods to be verified, and the time characteristics of withdrawal behavior (e.g., concentrated in the early morning hours)" are extracted to form the attack withdrawal phase detection requirements.

[0026] Taking the detection requirement sub-items of each of the five attack chain stages as the processing objects, the correlation between the requirements of each stage is verified. For example, it is verified whether the "core data type" of the data theft stage matches the "target vulnerability impact range" of the vulnerability exploitation stage (to avoid the contradiction of requiring detection of data theft in the area when the vulnerability does not involve the core data storage area), and whether the "internal network path" of the lateral movement stage can connect with the "target IP segment" of the reconnaissance and detection stage. Requirement conflicts are eliminated, and missing related requirement points are supplemented (such as supplementing the related requirement that "the vulnerability exploitation stage needs to reserve an environment snapshot for the subsequent lateral movement stage"). Finally, the detection requirement sub-items corresponding to each stage of the attack chain are determined. The detection requirement sub-items corresponding to each stage of the attack chain will be directly used as the basic input for "extracting the key technical parameters in each detection requirement sub-item" in step 12, to ensure that the parameter extraction in step 12 more accurately corresponds to the requirements of each stage.

[0027] This implementation process differs from the traditional approach of simply categorizing task requirements by detection targets such as "servers and network devices." By combining the behavioral logic of each stage of the attack chain to define boundaries, refine the specific requirements of each stage, and verify their relevance, the detection requirement sub-items are made more aligned with the scenario requirements of full attack path coverage in laboratory threat assessments. This avoids the problem of ambiguous requirements caused by ignoring the characteristics of attack stages in traditional decomposition methods (such as confusing "port scanning" with "vulnerability exploitation" as the same requirement). At the same time, it provides a staged and precise basis for the parameter extraction in step 12 and the resource profile construction in step 2, ensuring that the entire link scheduling has a clear stage orientation from the requirement side.

[0028] Optionally, step 1 specifically includes step 12: extracting the key technical parameters in each detection requirement sub-item, and using vector mapping to transform the key technical parameters corresponding to each stage into multi-dimensional vectors to generate a detection task scenario feature vector table with attack chain stage labels.

[0029] Preferably, the specific implementation process of step 12 is as follows: Taking the detection requirement sub-items corresponding to each stage of the attack chain determined in step 11 (including the detection requirement sub-items of the reconnaissance and detection stage, vulnerability exploitation stage, lateral movement stage, data theft stage, and attack withdrawal stage) as the processing objects, firstly, in combination with the technical characteristics of the detection tasks of each stage in the laboratory threat assessment scenario, define the key technical parameter extraction dimensions of each stage detection requirement sub-item to form a "stage-parameter dimension comparison table"—wherein the parameter dimensions of the reconnaissance and detection stage include "target IP segment coverage, number of port types to be scanned, and device fingerprint recognition type", the parameter dimensions of the vulnerability exploitation stage include "vulnerability number, compatible operating system version, and successful exploitation judgment indicators", the parameter dimensions of the lateral movement stage include "number of internal network path nodes, type of permission switching method, and traffic feature monitoring items", the parameter dimensions of the data theft stage include "number of core data types, type of transmission channel, and threshold for single transmission volume", and the parameter dimensions of the attack withdrawal stage include "type of trace clearing behavior, backdoor detection method, and withdrawal time range";

[0030] Based on the "Stage-Parameter Dimension Comparison Table," key technical parameters are extracted for the detection requirements of each attack chain stage: For the detection requirements of the reconnaissance and detection stage, the "target IP segment coverage (e.g., 192.168.0.0 / 24), number of port types to be scanned (e.g., TCP 80 / 443 / 3389, a total of 3 types), and device fingerprint recognition type (e.g., operating system fingerprint, application fingerprint, a total of 2 types)" are extracted from the requirement description and integrated to form the "Reconnaissance and Detection Stage Technical Parameter Set"; For the detection requirements of the vulnerability exploitation stage, the "vulnerability number (e.g., CVE-2024-21413), compatible operating system version (e.g., Windows 10 21H2, Linux CentOS 8), and successful exploitation criteria (e.g., whether command-line privileges on the target device were obtained)" are extracted and integrated to form the "Vulnerability Exploitation Stage Technical Parameter Set";

[0031] Continue extracting key technical parameters for the remaining stages according to the "Stage-Parameter Dimension Comparison Table": For the detection requirements of the lateral movement stage, extract "number of intranet path nodes (e.g., 3 nodes in total: Web server → middleware server → database server), type of permission switching method (e.g., 2 types: remote desktop login, SUID privilege escalation), and traffic feature monitoring items (e.g., 3 items: abnormal RDP connection, high-frequency SMB request)" to form the "Technical Parameter Set for the Lateral Movement Stage"; For the detection requirements of the data theft stage, extract "number of core data types (e.g., 2 types: user account data, business order data), type of transmission channel (e.g., 2 types: HTTP POST, FTP), and single transmission volume threshold (e.g., 100MB)" to form the "Technical Parameter Set for the Data Theft Stage"; For the detection requirements of the attack withdrawal stage, extract "type of trace clearing behavior (e.g., 2 types: log deletion, process termination), backdoor detection method (e.g., 2 types: registry check, port listening), and withdrawal time range (e.g., 2:00-4:00 AM)" to form the "Technical Parameter Set for the Attack Withdrawal Stage".

[0032] Using the technical parameter sets of each stage as the processing object, parameter standardization is performed—non-numerical parameters are converted into quantifiable encoded values ​​(e.g., in the "successful utilization judgment index", "obtain command line permission" is encoded as 1 and "obtain file read permission only" is encoded as 0.6), and numerical parameters are converted into relative weight values ​​(e.g., in the "number of port types to be scanned", 3 types of ports are encoded as 0.8 and 2 types are encoded as 0.6, and normalization is performed with 5 types of ports as the full value of 1.0), forming a "standardized stage technical parameter set" to avoid subsequent vector mapping deviations due to differences in parameter format;

[0033] Based on the "standardized stage technical parameter set", the number of dimensions of the multi-dimensional vector is configured for each attack chain stage (the number of dimensions is consistent with the number of parameter dimensions for that stage), and the meaning of the parameters corresponding to each dimension is defined: for example, the reconnaissance and detection stage is a 3-dimensional vector, the first dimension corresponds to the "target IP segment coverage weight value", the second dimension corresponds to the "number of port types to be scanned weight value", and the third dimension corresponds to the "device fingerprint recognition type weight value"; the vulnerability exploitation stage is a 3-dimensional vector, the first dimension corresponds to the "vulnerability number matching degree (such as the degree of matching with the resource support vulnerability library, a perfect match is 1.0)", the second dimension corresponds to the "number of adapted operating system versions weight value", and the third dimension corresponds to the "exploitation success judgment indicator code value"; after completing the vector dimension definition for all stages according to this rule, the standardized parameter values ​​of each stage are sequentially filled into the corresponding vector dimensions to generate the "stage multi-dimensional vector";

[0034] Add corresponding attack chain stage labels to each "stage multi-dimensional vector" (e.g., label the reconnaissance and detection stage vector as "reconnaissance and detection-STG01" and the exploitation stage vector as "exploitation-STG02") to form a "multi-dimensional vector set with stage labels". Sort the "multi-dimensional vector set with stage labels" according to the attack chain stage sequence (reconnaissance and detection → exploitation → lateral movement → data theft → attack withdrawal) and supplement the detection requirement sub-item number corresponding to each vector (consistent with the requirement sub-item number determined in step 11). Finally, generate a "detection task scenario feature vector table with attack chain stage labels". This feature vector table will serve as the core input for "constructing a multi-dimensional profile of resource and technical capabilities based on the detection task scenario feature vector table" in step 2, ensuring that step 2 can accurately associate the requirements and resource capabilities of each stage and avoid resource matching deviations caused by traditional unvectorized requirement descriptions.

[0035] This implementation process differs from the traditional approach of simply extracting parameters without defining or standardizing dimensions. Through a progressive logic of "parameter dimension classification - standardization processing - vector dimension binding," it enables multi-dimensional vectors to accurately map the technical characteristics of detection requirements at each stage. This solves the problems of chaotic parameter extraction (such as mixing parameters from different stages) and vectors lacking clear meaning, leading to low targeting in subsequent resource matching. At the same time, by associating stage labels with requirement sub-item numbers, it ensures that the feature vector table can be completely traced back to the initial requirement, providing a clear data link for the requirement-resource correspondence in the entire chain scheduling.

[0036] Optionally, step 2 specifically involves: constructing a matrix of existing laboratory testing resources based on the feature vector table of detection task scenarios with attack chain stage labels, in order to generate a detection resource technical capability matrix with attack chain stage correlation coefficients.

[0037] Optionally, step 2 specifically includes step 21: using the detection task scenario feature vector table with attack chain stage labels as a reference, classifying and sorting the existing detection resources in the laboratory, determining the physical attributes and functional boundaries of each detection resource, so as to obtain a detection resource classification list, and matrixing the existing detection resources in the laboratory.

[0038] Preferably, the specific implementation process of step 21 is as follows: Taking the detection task scenario feature vector table with attack chain stage labels as the core reference, first extract the vector dimension meaning of each attack chain stage (reconnaissance and detection stage, vulnerability exploitation stage, lateral movement stage, data theft stage, attack withdrawal stage) from the feature vector table (e.g., the reconnaissance and detection stage vector includes dimensions such as "target IP segment coverage, port type to be scanned"). Based on these dimension meanings, sort out the core capability requirements of each stage for detection resources (e.g., the reconnaissance and detection stage requires "IP scanning capability, port identification capability", and the vulnerability exploitation stage requires "vulnerability database matching capability, environment simulation capability"), and form an "attack chain stage - resource capability requirement comparison table" to provide a scenario-based reference standard for resource classification;

[0039] Based on the "Attack Chain Stage - Resource Capability Requirements Comparison Table", basic information on the laboratory's existing testing resources (including equipment names, procurement records, technical manuals, historical usage logs, etc.) is collected. Basic descriptive data for each resource is extracted from this data (e.g., "Vulnerability Scanning Device A: Supports CVE vulnerability database query and can scan TCP / UDP ports" and "Traffic Capture Device B: Can record internal network HTTP / FTP traffic and has a storage capacity of 500GB"). This information is then integrated to form a "Resource Original Information Set" to ensure coverage of all testing resources to be classified.

[0040] For each detection resource in the "Resource Original Information Set", its physical attributes are analyzed: the constituent dimensions of physical attributes are clarified (including hardware specifications, deployment method, interface type, and operating environment requirements). Hardware specifications include processor model, memory capacity, storage media type and capacity; deployment method distinguishes between physical machine, virtual machine, and containerized deployment; interface type includes network interface (such as Gigabit Ethernet port) and data interaction interface (such as REST API); and operating environment requirements include operating system version and dependent component version. By verifying the resource technical manual against the actual configuration, the above attribute data is filled into the "Resource Physical Attribute Table" to obtain the "Physical Attribute Details" of each resource, thereby determining the physical boundaries of each resource (e.g., "Vulnerability scanning device A deployed on a virtual machine needs to run on CentOS 7 system and depends on Python 3.8 environment").

[0041] Based on the "Attack Chain Stage - Resource Capability Requirements Comparison Table," a functional boundary analysis is performed on each detection resource in the "Resource Original Information Set." For each resource, it is determined which attack chain stages' capability requirements it can meet (e.g., "Traffic capture device B can meet the 'traffic feature monitoring' requirement in the lateral movement stage and the 'transmission channel detection' requirement in the data theft stage"). At the same time, capability requirements that it cannot cover are marked (e.g., "Traffic capture device B does not support the 'vulnerability database matching' requirement in the vulnerability exploitation stage"). Combining the resource's historical usage logs, its functional limitations are supplemented (e.g., "The maximum number of concurrent monitoring sessions for a single device B is 100"), forming a "Resource Functional Boundary Description Table" to clarify the functional coverage of each resource in the laboratory threat assessment scenario.

[0042] The "Resource Physical Attribute Table" and the "Resource Functional Boundary Description Table" are used as joint processing objects for resource classification and sorting. The classification rules are based primarily on the "match between function and attack chain stage requirements," with physical attributes as a secondary basis. Resources that mainly meet the requirements of the reconnaissance and detection stage are classified as "reconnaissance resources" (such as port scanning devices and device fingerprinting devices); those that mainly meet the requirements of the vulnerability exploitation stage are classified as "vulnerability resources" (such as vulnerability verification platforms and POC testing tools); those that mainly meet the requirements of the lateral movement stage are classified as "internal network resources" (such as internal network traffic analysis devices and permission tracking tools); those that mainly meet the requirements of the data theft stage are classified as "data resources" (such as data leakage detection devices and transmission encryption analysis tools); and those that mainly meet the requirements of the attack withdrawal stage are classified as "source tracing resources" (such as log auditing devices and backdoor detection tools). For resources that support multiple stages (such as devices that simultaneously support traffic capture and log auditing), they are classified according to their primary adapted stage, and the secondary supported stage is marked in the classification results.

[0043] Perform consistency verification on the preliminary classification results: check whether there are significant conflicts in the physical attributes of resources in the same category (e.g., whether "reconnaissance resources" include devices that require both Windows and Linux environments; if so, supplement the environment compatibility description), and whether the functional boundaries are highly related to the requirements of the corresponding attack chain stage (e.g., whether "vulnerability resources" all include vulnerability database-related capabilities); adjust the classification based on the verification results (e.g., change devices that only support a few vulnerability types from "vulnerability resources" to "auxiliary resources" and label them), and finally form a "detection resource classification list"; this detection resource classification list will serve as the basic input for step 22 "evaluating the technical capability parameters of each detection resource", ensuring that the parameter evaluation in step 22 can be carried out on the common and individual characteristics of similar resources, and improve the targeting of subsequent matrix construction.

[0044] This implementation process differs from the traditional approach of classifying resources solely by "hardware type (such as servers and switches)" or "manufacturer model." By defining classification criteria in conjunction with the capability requirements of each stage of the attack chain, it directly links resource classification results with the staged requirements of the detection task. This solves the problem of "classification mismatch" caused by traditional classifications being detached from scenario requirements (such as classifying vulnerability scanning devices and traffic capture devices into the same category). At the same time, by clearly defining physical attributes and functional boundaries, it provides a clear resource characteristic benchmark for the accurate evaluation of subsequent resource technical capability parameters.

[0045] Optionally, step 2 specifically includes step 22: based on the list of testing resources, evaluate the technical capability parameters of each testing resource to obtain the technical parameters of the testing resources, so as to matrix the existing testing resources of the laboratory.

[0046] Preferably, the specific implementation process of step 22 is as follows: Taking the detection resource classification list (including reconnaissance resources, vulnerability resources, intranet resources, data resources, source tracing resources, and specific resource entries under each category) as the processing object, firstly, combine the vector dimensions of each stage in the detection task scenario feature vector table with attack chain stage labels generated in step 12 (such as the "target IP segment coverage range, port type to be scanned" dimension in the reconnaissance and detection stage), and formulate corresponding technical capability evaluation dimensions for each type of resource to form a "resource category-capability evaluation dimension comparison table"—wherein the evaluation dimensions of reconnaissance resources include "IP scanning range coverage rate" The evaluation dimensions for vulnerability resources include "the number of port identification types and the accuracy of device fingerprint matching". The evaluation dimensions for vulnerability resources include "the coverage of CVE numbers in the vulnerability database, the number of compatible operating system versions, and the update frequency of POC (Proof of Confirmation)". The evaluation dimensions for intranet resources include "the number of intranet path nodes identified, the types of permission switching methods supported, and the accuracy of traffic feature extraction". The evaluation dimensions for data resources include "the types of core data types identified, the number of transmission channel protocols supported, and the maximum amount of data captured in a single instance". The evaluation dimensions for source tracing resources include "the types of trace clearing behavior identified, the number of backdoor detection tools integrated, and the length of log audit coverage period".

[0047] Based on the "Resource Category - Capability Assessment Dimension Comparison Table", parameter data is collected for each specific resource in the resource classification list: For static technical parameters (parameters that do not change with the running status), they are extracted from the resource technical manual and configuration files, such as the "CVE number coverage in the vulnerability database" (over 10,000 from the manual) and "number of compatible operating system versions" for the vulnerability-type resource "Vulnerability Scanning Device X" (supporting 4 versions including Windows 7 / 10 / 11 and Linux Ubuntu 20.04 from the configuration file); For dynamic technical parameters (parameters that change with the running status), they are extracted from the resource's historical operation logs and monitoring system, such as the "number of port identification types" (recorded scanning of 4 types including TCP 80 / 443 / 3389 and UDP 53 in the past 30 days' logs) and "device fingerprint matching accuracy" for the reconnaissance-type resource "Port Scanning Device Y" (85 out of 100 historical identifications matched the actual device, calculated as 85%); The collected static and dynamic parameters are recorded separately to form the "raw dataset of resource parameters".

[0048] Perform parameter validity verification on the "Original Resource Parameter Dataset": Verify whether static parameters are consistent with the actual resource configuration (e.g., if the manual indicates "supports 5 operating systems" but only 3 are actually configured, then the actual configuration shall prevail); verify whether dynamic parameters are within the valid statistical period (e.g., only log data from the last 90 days are used, and outdated data exceeding the period is removed); for missing parameters (e.g., if a resource has no POC update frequency record), supplement them with the average parameter value of similar resources (e.g., if the average update frequency of similar vulnerability resources is once a week, then use this as the supplementary value), and indicate the source of the supplement; after verification, the "Resource Parameter Verification Dataset" is obtained, ensuring the authenticity and completeness of the parameters;

[0049] Based on the "Resource Parameter Verification Dataset," parameter standardization is performed: For numerical parameters (such as vulnerability database coverage and the number of port identification types), interval normalization is used to convert them into relative values ​​between 0 and 1 (e.g., if the "vulnerability database coverage" is based on the maximum coverage of mainstream industry resources as 1.0, and a certain resource's coverage is 80% of that, then it is standardized to 0.8); For enumeration parameters (such as supported operating system versions), they are converted into relative values ​​according to the proportion of the number of supported versions to the average number of supported versions of that type of resource (e.g., if a vulnerability resource supports 4 versions, and the average of the same type supports 5 versions, then it is standardized to 0.8); For percentage parameters (such as device fingerprint matching accuracy), the original percentage is directly retained and converted into a decimal between 0 and 1 (e.g., 85% is converted to 0.85); After standardization, a "Resource Standardized Parameter Set" is formed, eliminating the dimensional differences between different types of parameters.

[0050] The "Resource Standardization Parameter Set" is associated with the corresponding resource category labels and unique identifiers (such as equipment numbers), and organized according to the hierarchical structure of "Resource Category - Specific Resource - Evaluation Dimension - Standardized Parameter Value" to generate the "Testing Resource Technical Parameter Table". The "Testing Resource Technical Parameter Tables" of all resources are summarized to obtain the "Testing Resource Technical Parameter Set". This testing resource technical parameter set will be directly used as the input data for step 23 "Calculating the Demand Matching Degree through Scenario-based Parameter Comparison Method", ensuring that step 23 can accurately compare the standardized resource capability parameters with the testing task demand parameters, thereby improving the reliability of the matching degree calculation.

[0051] This implementation process differs from the traditional approach of only evaluating resource hardware specifications (such as processors and memory). By combining the demand vector dimension of the attack chain stages to define the technical capability evaluation dimension, the parameter evaluation is directly linked to the scenario requirements of the detection task. At the same time, by adopting a combination of static and dynamic parameters and standardized processing, it solves the problem of inaccurate resource capability characterization caused by the chaotic description of traditional parameters (such as different units for different resource parameters and only recording static attributes), and provides a quantitative and comparable technical basis for matching resources with task stages in the future.

[0052] Optionally, step 2 specifically includes step 23: based on the set of technical parameters of the detection resources, calculate the matching degree between each detection resource and the needs of each stage of the attack chain through the scenario-based parameter comparison method, so as to matrix the existing detection resources of the laboratory.

[0053] Preferably, the specific implementation process of step 23 is as follows: Using the set of technical parameters for detection resources (containing standardized technical parameters for each resource, such as "IP scan range coverage" for reconnaissance resources and "CVE number coverage" for vulnerability database resources) and the feature vector table of detection task scenarios with attack chain stage labels (containing multi-dimensional requirement vectors for each stage, such as "target IP segment coverage" and "port type to be scanned" vectors for the reconnaissance and detection stage) as the joint processing objects, first establish a correspondence table of "attack chain stage - requirement dimension - resource parameter dimension"—where the "target IP segment coverage" requirement dimension of the reconnaissance and detection stage corresponds to the "IP scan range coverage" parameter dimension of the reconnaissance resources, and the "port type to be scanned" requirement dimension corresponds to the "number of port identification types" parameter dimension; the "vulnerability number matching degree" requirement dimension of the vulnerability exploitation stage corresponds to the "CVE number coverage" parameter dimension of the vulnerability database resources, and the "adaptation to operating system version" requirement dimension corresponds to the "number of adapted operating system versions" parameter dimension; complete the dimensional correspondence between all stages and resource categories according to this rule, ensuring that the comparison dimensions of requirements and resource parameters match one-to-one, avoiding deviations caused by cross-dimensional comparisons;

[0054] Based on the correspondence table of "Attack Chain Stage - Requirement Dimension - Resource Parameter Dimension", scenario-based weights are configured for each requirement dimension of each attack chain stage. The weight value is determined according to the degree of influence of the dimension on the stage detection effect in the laboratory threat assessment scenario. For example, in the reconnaissance and detection stage, the "target IP segment coverage" dimension directly affects the completeness of the subsequent attack path, with a weight of 0.6; the "number of port identification types" dimension affects the breadth of vulnerability discovery, with a weight of 0.4; in the vulnerability exploitation stage, the "CVE number coverage in the vulnerability database" dimension determines the coverage of vulnerability verification, with a weight of 0.5; and the "number of compatible operating system versions" dimension affects environmental compatibility, with a weight of 0.5. The dimension weights of each stage are determined by expert review combined with historical detection effect data (such as the frequency of detection failure due to insufficient parameters in a certain dimension), forming a "stage-dimensional weight table" that reflects the priority of scenario-based requirements.

[0055] For each individual detection resource, the matching degree is calculated sequentially according to the attack chain stages: For the reconnaissance and detection stage, the standardized parameter values ​​of the resource (e.g., the reconnaissance resource "port scanning device Y") in the corresponding parameter dimensions are extracted ("IP scanning range coverage" is 0.8, "number of port identification types" is 0.7), and the standardized values ​​of the corresponding dimensions in the reconnaissance and detection stage demand vector are also extracted ("target IP segment coverage" is 0.9, "port type to be scanned" is 0.8); the single matching degree of each dimension is calculated—using the absolute difference inverse mapping method, that is, the single dimension matching degree = 1 - |resource parameter value - demand parameter value| (e.g., "IP scanning range coverage" dimension: 1 - |0.8 - 0.9| = 0.9; "number of port identification types" dimension: 1 - |0.7 - 0.8| = 0.9), resulting in the "stage-dimension single matching degree table";

[0056] The "Phase-Dimension Single Matching Degree Table" is associated with the "Phase-Dimension Weight Table" to calculate the overall requirement matching degree of the resource in the reconnaissance and detection phase: Overall matching degree = Σ(Single dimension matching degree × corresponding dimension weight) (e.g., reconnaissance and detection phase: 0.9 × 0.6 + 0.9 × 0.4 = 0.9); The matching degree calculation of this resource with other attack chain phases (vulnerability exploitation phase, lateral movement phase, etc.) is processed in the same way. If the resource category and phase do not directly correspond (e.g., data resources and vulnerability exploitation phase), the calculation is based on the indirect association dimension between the resource and the phase in the "Phase-Requirement Dimension-Resource Parameter Dimension" correspondence table (e.g., the "number of transmission channel protocols supported" of data resources may be indirectly related to the "vulnerability exploitation data transmission requirement" of the vulnerability exploitation phase) to ensure that all resources have matching degree results with all phases.

[0057] The calculated overall requirement matching degree is validated for reasonableness: Check for abnormal jumps in the matching degree of the same resource in adjacent attack chain stages (e.g., a resource with a matching degree of 0.8 in the reconnaissance and detection stage suddenly drops to 0.2 in the vulnerability exploitation stage; verify the correctness of the dimension correspondence and parameter values). Also check whether the matching degree distribution of different resources in the same stage conforms to the differences in resource capabilities (e.g., the matching degree of high-end vulnerability scanning equipment should be higher than that of basic equipment). Based on the validation results, correct any erroneous dimension correspondences or parameter values ​​to obtain a "Resource-Stage Requirement Matching Degree Table," where each record contains a unique resource identifier, an attack chain stage label, and an overall requirement matching degree value (range 0-1, with higher values ​​indicating stronger matching).

[0058] The "Resource-Stage Requirement Matching Table" is organized according to the order of the resource classification list and the attack chain stage sequence (reconnaissance and detection → vulnerability exploitation → lateral movement → data theft → attack withdrawal) to form a "Prototype of Resource-Stage Requirement Matching Matrix". This provides direct input for step 24, "determine the correlation coefficient through stage correlation quantification rules", ensuring that step 24 can generate more accurate correlation coefficients based on quantified matching data, and improve the scenario adaptability of the detection resource technology capability matrix.

[0059] This implementation process differs from the traditional matching method that relies solely on a single parameter (such as hardware performance). Through a progressive logic of "precise dimensional correspondence - scenario-based weight allocation - multi-dimensional comprehensive calculation," the matching results reflect the scenario-based adaptability of resource capabilities to the needs of attack chain stages. Furthermore, by calculating the matching degree for indirect associations between cross-category resources and stages, it addresses the incomplete matching problem caused by traditional matching methods that are limited to directly associating resources and stages. This provides a quantitative basis for the accurate matching of resources and multi-stage requirements in laboratory threat assessment scenarios.

[0060] Optionally, step 2 specifically includes step 24: based on the matching degree of the needs of each detection resource and each stage of the attack chain, determine the correlation coefficient between the detection resource and the attack chain stage through the stage correlation quantification rule, so as to construct a detection resource technical capability matrix. In this matrix, the rows correspond to each detection resource in the detection resource classification list, the columns correspond to each stage of the attack chain, and the intersection of the rows and columns is filled with the correlation coefficient between the detection resource and the attack chain stage.

[0061] Preferably, the specific implementation process of step 24 is as follows: Taking the "Resource-Stage Demand Matching Degree Table" (which contains the comprehensive demand matching degree of each detection resource and each stage of the attack chain, with a value range of 0-1) generated in step 23 as the core processing object, firstly, in combination with the actual constraints of resource scheduling in the laboratory threat assessment scenario, formulate the "Stage Correlation Measurement Rule" - this rule includes three levels: basic coefficient mapping, historical performance correction, and stage dependency correction, which are used to transform the demand matching degree into a correlation coefficient that is more in line with the actual scheduling scenario;

[0062] Based on the first level of the "stage-related metric rules", a basic correlation coefficient mapping is performed: the comprehensive demand matching degree is mapped to the basic correlation coefficient according to a preset interval. The interval division is determined based on the correlation between the matching degree and the actual task completion effect in the laboratory's historical scheduling - for example, a matching degree of 0.8-1.0 is mapped to a basic coefficient of 0.9-1.0 (high correlation), 0.5-0.8 is mapped to 0.6-0.9 (medium correlation), 0.3-0.5 is mapped to 0.3-0.6 (low correlation), and 0-0.3 is mapped to 0-0.3 (weak correlation). The relative differences in matching degree are preserved during the mapping (e.g., a matching degree of 0.9 corresponds to a basic coefficient of 0.95, and 0.8 corresponds to 0.9, maintaining a linear relationship), forming a "resource-stage basic correlation coefficient table" to ensure the consistency of the trend between the basic coefficient and the demand matching degree.

[0063] Entering the second level of the "Stage-Based Correlation Measurement Rules," a historical performance correction factor is introduced: historical performance data of each detection resource at the corresponding attack chain stage is extracted from the laboratory resource scheduling historical database, including task completion success rate (historical successful execution count / total execution count) and result stability (deviation rate of three consecutive execution results); the historical performance correction factor is calculated as (success rate × 0.6 + (1 - deviation rate) × 0.4), where the success rate has a higher weight than stability, because laboratory threat assessment focuses more on whether the task can be completed; the basic coefficient in the "Resource-Stage Basic Correlation Coefficient Table" is multiplied by the corresponding historical performance correction factor to obtain the "Resource-Stage Corrected Correlation Coefficient (Historical Layer)." For example, if the basic coefficient of a resource in the reconnaissance and detection stage is 0.9 and the historical performance correction factor is 0.95, then the corrected coefficient is 0.855, thus reflecting the impact of the actual performance of the resource on the correlation.

[0064] Based on the third level of the "stage correlation metric rule," stage dependency correction is performed: Each stage of the attack chain has a progressive dependency relationship (e.g., the exploit stage depends on the information output of the reconnaissance and detection stage). Therefore, the correlation coefficient needs to be adjusted according to the dependency strength between the preceding stage and the current stage. A stage dependency weight table is defined, where the dependency weight of the current stage on directly related preceding stages (e.g., the lateral movement stage on the exploit stage) is 0.2, the dependency weight on indirectly related preceding stages (e.g., the lateral movement stage on the reconnaissance and detection stage) is 0.1, and the weight of unrelated stages is 0. The stage dependency correction value of a resource in the current stage is calculated as follows: The "Revised Relevance Coefficient (Historical Layer)" of the sequential correlation stage is multiplied by the sum of the corresponding dependency weights. The "Resource-Stage Revised Relevance Coefficient (Historical Layer)" is added to the stage dependency correction value (the sum does not exceed 1.0) to obtain the "Resource-Stage Final Relevance Coefficient". For example, if the historical layer correction coefficient of a resource in the vulnerability exploitation stage is 0.8, its coefficient in the preceding reconnaissance and detection stage is 0.85, and its dependency weight is 0.2, then the stage dependency correction value is 0.17, and the final coefficient is 0.8 + 0.17 = 0.97 (if it does not exceed 1.0, the actual value is taken). This reflects the impact of the attack chain stage progression relationship on the resource correlation.

[0065] Using the order of resources in the resource classification list as row indexes and the attack chain stages (reconnaissance and detection stage, vulnerability exploitation stage, lateral movement stage, data theft stage, and attack withdrawal stage) as column indexes, an initial matrix framework is constructed. The "resource-stage final correlation coefficient" is filled into the intersection of the matrix framework according to the correspondence between resources and stages, forming a "prototype of detection resource technical capability matrix". In this matrix, the rows represent specific detection resources (such as "reconnaissance-port scanning device Y" and "vulnerability-vulnerability scanning device X"), the columns represent each stage of the attack chain, and the value at the intersection of rows and columns is the detection resource-attack chain stage correlation coefficient (range 0-1, the higher the value, the stronger the adaptability of the resource to the technical capability of the corresponding stage).

[0066] The "prototype of detection resource technical capability matrix" is validated for rationality: the distribution of correlation coefficients of the same resource in each stage is checked to see if it conforms to its functional positioning (e.g., the coefficient of source tracing resources should be significantly higher in the attack withdrawal stage than in other stages), and whether there is a reasonable gradient in the coefficients of different resources in the same stage (e.g., the coefficient of high-end equipment should be higher than that of basic equipment). If there are anomalies (e.g., the coefficient of a vulnerability resource in the vulnerability exploitation stage is lower than that in the data theft stage), the historical performance data and stage dependency weights are checked back to see if they are configured reasonably. After correction, the final "detection resource technical capability matrix" is formed. This matrix will serve as the core input for step 3, "generating a task-resource scheduling configuration table with risk level identifiers", to ensure that step 3 can perform accurate task-resource adaptation based on the quantitative correlation between resources and stages.

[0067] This implementation process differs from the traditional approach of directly using demand matching as the correlation coefficient. Through a three-layer quantification rule of "basic mapping - historical correction - stage dependency correction", the correlation coefficient not only reflects demand matching, but also integrates the actual performance of resources with the progressive relationship of attack chain stages. This solves the scheduling deviation problem caused by traditional coefficients that only statically reflect parameter matching and ignore dynamic execution effects and stage correlation. At the same time, it clarifies the meaning of matrix rows and columns and the physical meaning of coefficients, providing a structured and interpretable quantitative basis for resource capabilities for subsequent scheduling scheme generation.

[0068] Optionally, step 3 specifically involves: based on the detection resource technology capability matrix with attack chain stage correlation coefficient, dynamically adapting detection tasks and resources through the attack chain stage risk dual-factor evaluation model, generating a correlation mapping table between risk level and resource adaptation stability label, so as to generate a task-resource scheduling configuration table with risk level identifier.

[0069] Optionally, step 3 specifically includes step 31: Based on the detection resource technology capability matrix with attack chain stage correlation coefficient, construct a two-factor risk assessment model for attack chain stages, where the first factor is the attack impact diffusion factor and the second factor is the vulnerability exploitation success rate factor. Calculate the comprehensive risk assessment value for each attack chain stage based on the two-factor risk assessment model to generate a correlation mapping table between risk level and resource adaptation stability label.

[0070] Preferably, the specific implementation process of step 31 is as follows: Based on the detection resource technical capability matrix with attack chain stage correlation coefficients (the matrix rows correspond to detection resources, the columns correspond to attack chain stages such as reconnaissance and detection, vulnerability exploitation, etc., and the intersection is the correlation coefficient between resources and stages, ranging from 0 to 1), the core components of the attack chain stage risk dual-factor assessment model are first clarified: the first factor is the attack impact diffusion factor (F1), which reflects the scope and degree of impact that an attack may have if successfully implemented at this stage; the second factor is the vulnerability exploitation success rate factor (F2), which reflects the possibility that the vulnerabilities involved in this stage will be actually exploited; the two factors work together to characterize the stage risk, avoiding the one-sidedness of single-factor assessment;

[0071] The calculation dimensions for the Attack Impact Diffusion Factor (F1) are constructed as follows: Starting from the asset attributes of the laboratory threat assessment scenario, F1 is defined to include three sub-dimensions: "Percentage of Affected Assets," "Core Asset Influence," and "Cross-Stage Impact Weight." "Percentage of Affected Assets" is the ratio of the number of assets potentially affected by the attack at this stage to the total number of assets in the laboratory; "Core Asset Influence" is the percentage of core assets (such as database servers and business terminals) among the affected assets, with core assets pre-labeled according to the importance of the business they support (e.g., labeled "Core," "Important," "General"); "Cross-Stage Impact Weight" is determined based on the progressive relationship of the attack chain stages (e.g., an attack at the vulnerability exploitation stage may directly trigger the risk of the lateral movement stage, and its weight is higher than that at the reconnaissance and detection stage); through expert review combined with historical attack case data, weights are assigned to the three sub-dimensions (e.g., 0.4, 0.4, and 0.2 respectively), forming the "F1 Sub-Dimension Weight Table."

[0072] Calculate the attack impact diffusion factor (F1) for each stage of the attack chain: For the vulnerability exploitation stage, the number of assets that may be affected by the attack at this stage is 20, and the total number of assets in the laboratory is 50, so the "percentage of affected assets" is 0.4; among them, there are 8 core assets, so the "core asset entanglement" is 0.4; its "cross-stage impact weight" is configured to 0.3; then F1 = (0.4 × 0.4) + (0.4 × 0.4) + (0.3 × 0.2) = 0.16 + 0.16 + 0.06 = 0.38; calculate the F1 value for other stages according to the same logic to form an "Attack Chain Stage - F1 Value Comparison Table";

[0073] The calculation dimensions for the vulnerability exploitation success rate factor (F2) are constructed as follows: Combining the correlation coefficients in the detection resource technical capability matrix, F2 is defined to include three sub-dimensions: "vulnerability exploitability," "environment adaptability," and "resource coverage gap." "Vulnerability exploitability" is based on the exploitation difficulty rating of the vulnerability in publicly available vulnerability databases (such as CVEs) (easy = 0.8, medium = 0.5, difficult = 0.2); "environment adaptability" is the degree of matching between the vulnerability involved in this stage and the target environment (operating system, application software version) (complete match = 1.0, partial match = 0.6, no match = 0); "resource coverage gap" is 1 minus the maximum value of all resource correlation coefficients in the detection resource technical capability matrix for this stage (reflecting the resource's coverage capability for the vulnerability; the higher the coefficient, the smaller the gap); weights are assigned to the three sub-dimensions (e.g., 0.3, 0.3, 0.4 respectively), forming the "F2 Sub-dimension Weight Table," where "resource coverage gap" has a higher weight because the effectiveness of resource coverage in laboratory scenarios directly affects the actual success rate of vulnerability exploitation.

[0074] Calculate the vulnerability exploitation success rate factor (F2) for each stage of the attack chain: For the vulnerability exploitation stage, the exploitation difficulty is "easy", "vulnerability exploitability" = 0.8; "partially matches" the target environment, "environment adaptability" = 0.6; the maximum resource correlation coefficient for this stage is 0.7, "resource coverage gap" = 1 - 0.7 = 0.3; then F2 = (0.8 × 0.3) + (0.6 × 0.3) + (0.3 × 0.4) = 0.24 + 0.18 + 0.12 = 0.54; calculate the F2 value for other stages using the same logic (e.g., in the reconnaissance and detection stage where there is no direct vulnerability exploitation, the F2 value is adjusted to 0.3 based on the information gathering difficulty), forming an "Attack Chain Stage - F2 Value Comparison Table";

[0075] The comprehensive risk assessment value calculation rule is constructed based on F1 and F2: Comprehensive risk assessment value = (F1×α) + (F2×β), where α and β are factor weights, configured according to the focus of the laboratory threat assessment (e.g., if more attention is paid to the scope of attack impact, then α=0.6, β=0.4; if more attention is paid to the possibility of vulnerability exploitation, then α=0.4, β=0.6). For the vulnerability exploitation stage, if α=0.5, β=0.5, then the comprehensive risk assessment value = 0.38×0.5 + 0.54×0.5 = 0.19 + 0.27 = 0.46. The comprehensive risk assessment values ​​for all stages are calculated to form an "Attack Chain Stage - Comprehensive Risk Assessment Value Table" (value range 0-1, the higher the value, the higher the risk).

[0076] The comprehensive risk assessment value is mapped to a risk level: risk levels are divided according to preset ranges (e.g., 0.7-1.0 is "high risk", 0.4-0.7 is "medium risk", and 0-0.4 is "low risk"). A comprehensive value of 0.46 in the vulnerability exploitation stage corresponds to "medium risk". At the same time, based on the standard deviation of the resource correlation coefficient in the detection resource technical capability matrix for this stage (reflecting the consistency of resource adaptation), a resource adaptation stability label is generated (standard deviation ≤0.1 is "stable", 0.1-0.3 is "average", and ≥0.3 is "fluctuating"). For example, if the standard deviation of the resource correlation coefficient in the vulnerability exploitation stage is 0.2, the label is "average".

[0077] By associating risk levels with resource adaptation stability tags one by one, a "risk level-stability tag association mapping table" (such as combinations like "medium risk-general" and "high risk-volatile") is formed. This mapping table will serve as the basis for step 33, "calculating risk-capability adaptation", ensuring that the adaptation logic between risk levels and resource stability is traceable and improving the risk targeting of the task-resource scheduling configuration table.

[0078] This implementation process differs from traditional risk assessment methods that rely solely on a single dimension, such as the vulnerability itself or the impact of an attack. It integrates the attack impact and vulnerability exploitation characteristics through a two-factor design and incorporates the correlation coefficient of the detection resource technical capability matrix into the "resource coverage gap" sub-dimension of F2. This directly links risk assessment with the actual resource adaptability, solving the problem of "disconnect between risk assessment and scheduling" caused by traditional risk assessment neglecting resource support capabilities. At the same time, the sub-dimension weight configuration reflects scenario-based needs, making the comprehensive risk assessment value more closely match the actual scheduling needs of laboratory threat assessment.

[0079] Optionally, step 3 specifically includes step 32: based on the comprehensive risk assessment value of the attack chain stage, the detection task and the backup resource are dynamically adapted to the risk level by using the historical adaptation stability data of the detection task in the same attack chain stage, so as to calculate the risk-capability adaptation degree, and generate an association mapping table between the risk level and the resource adaptation stability label according to the risk-capability adaptation degree.

[0080] Preferably, the specific implementation process of step 32 is as follows: Taking the "Attack Chain Stage - Comprehensive Risk Assessment Value Table" (containing the comprehensive risk assessment value and corresponding risk level of each stage, such as the vulnerability exploitation stage being "medium risk") generated in step 31 and the "Historical Adaptation Stability Data of the Same Attack Chain Stage" (recording the historical adaptation performance of each resource within the same stage, including task completion rate, execution result deviation rate, and anomaly recovery time) in the laboratory testing task historical database as the joint processing objects, the historical adaptation stability data is first extracted in a structured manner to clarify the data dimensions - "Task Completion Rate" is the proportion of the number of times the resource successfully executes the task of this stage to the total number of executions, "Execution Result Deviation Rate" is the average parameter difference between the actual detection result and the expected result, and "Anomaly Recovery Time" is the average time for the resource to recover to normal operation after an anomaly occurs; these data are summarized according to the attack chain stage and resource classification to form the "Stage - Resource Historical Stability Data Table" to ensure that the data is directly related to the risk assessment scenario of the current stage;

[0081] The data in the "Phase-Resource Historical Stability Data Table" is standardized as follows: "Task Completion Rate" is retained as the original ratio between 0 and 1 (e.g., 0.9 represents 90%); "Execution Result Deviation Rate" is converted into a positive indicator by "1 - Deviation Rate" (the smaller the deviation, the higher the value, e.g., a deviation rate of 0.1 is converted into 0.9); "Abnormal Recovery Time" is converted into a relative value between 0 and 1 by "1 - (Time / Maximum Allowable Time for this Phase)" (the shorter the time, the higher the value, e.g., if the maximum allowed time is 10 minutes and the actual time is 3 minutes, it is converted into 0.7); after standardization, the "Phase-Resource Standardized Stability Data Table" is obtained, eliminating the difference in dimensions between different indicators and facilitating subsequent comprehensive calculations;

[0082] Based on the "Attack Chain Stage - Comprehensive Risk Assessment Value Table", corresponding resource capability requirement thresholds are configured for each risk level: high-risk levels require resources with a high task completion rate (threshold ≥ 0.9), a low execution deviation rate (standardized value ≥ 0.85), and a short anomaly recovery time (standardized value ≥ 0.8); the corresponding thresholds for medium-risk levels are ≥ 0.8, ≥ 0.75, and ≥ 0.7, respectively; and the corresponding thresholds for low-risk levels are ≥ 0.7, ≥ 0.65, and ≥ 0.6, respectively. This forms the "Risk Level - Resource Capability Threshold Table", which clarifies the minimum requirements for resource stability for different risk levels.

[0083] From the detection resource technical capability matrix, backup resources for each stage of the attack chain are selected: For the vulnerability exploitation stage (medium risk), resources with a correlation coefficient ≥ 0.6 (basic capability threshold) are selected as backup resource sets (such as vulnerability scanning device X and vulnerability verification platform Z); for each resource in the backup resource set, the corresponding standardized stability data in the "Stage-Resource Standardized Stability Data Table" is extracted (such as the task completion rate of device X 0.85, the standardized value of execution result deviation rate 0.8, and the standardized value of anomaly recovery time 0.75).

[0084] Calculate the risk-capability fit between backup resources and the current risk level: The fit calculation uses a weighted summation method, with weights configured according to the level of attention paid to stability indicators based on the risk level—for high-risk levels, the weights for "task completion rate" are 0.4, "execution result deviation rate" is 0.3, and "anomaly recovery time" is 0.3; for medium-risk levels, the weights are 0.35, 0.3, and 0.35 respectively; for low-risk levels, the weights are 0.3, 0.35, and 0.35 respectively. For example, for device X in the vulnerability exploitation phase (medium risk), the risk-capability fit = 0.85 × 0.35 + 0.8 × 0.3 + 0.75 × 0.35 = 0.2975 + 0.24 + 0.2625 = 0.8; calculate the fit of all backup resources using the same logic to form a "Phase-Backup Resource-Fitness Table";

[0085] Based on the risk-capability fit, resource fit stability labels are assigned to backup resources: fit ≥ 0.85 is labeled "high stability", 0.7-0.85 is labeled "medium stability", and 0.6-0.7 is labeled "low stability"; for example, equipment X has a fit of 0.8 and is labeled "medium stability"; the risk level is associated with the stability label of the corresponding backup resource to form a "risk level-stability label association mapping table" (e.g., "medium risk-medium stability" corresponds to equipment X, and "medium risk-high stability" corresponds to platform Z with a fit of 0.86);

[0086] Verify the association mapping table: check whether the distribution of stability labels under the same risk level is consistent with the actual capabilities of the resources (e.g., the historical performance of resources with high stability labels should be significantly better than that of resources with low stability labels), and whether there is a reasonable distinction between the label thresholds of different risk levels (e.g., the fit of the "low stability" label for high risk level should be higher than that for "low stability" for medium risk level); adjust the weights or thresholds according to the verification results to ensure that the mapping table can accurately reflect the fit relationship between risk and resource stability; this association mapping table will serve as the input for step 32 (assigning cross-stage association weights) to provide a risk and stability association benchmark for multi-stage resource adaptation and integration.

[0087] This implementation process differs from the traditional static adaptation method that only considers the current capabilities of resources. By introducing historical adaptation stability data from the same attack chain stage, resource adaptation not only considers the current capabilities but also integrates historical execution performance, solving the problem of "capabilities meeting the standards but actual execution being unstable" caused by the traditional adaptation ignoring historical differences in resource stability. At the same time, stability indicator weights are dynamically configured for different risk levels, improving the risk targeting and reliability of task-resource adaptation.

[0088] Optionally, step 3 specifically includes step 33: assigning cross-stage association weights to each risk level-stability label combination in the association mapping table between risk level and resource adaptation stability label, and performing multi-stage adaptation fusion calculation processing on the initial resource adaptation data of each attack chain stage based on the cross-stage association weights to generate a task-resource scheduling configuration table with risk level identifiers.

[0089] Preferably, the specific implementation process of step 33 is as follows: Taking the "Association Mapping Table of Risk Level and Resource Adaptation Stability Label" (containing the combination of "Risk Level-Stability Label" and the corresponding backup resources, such as the vulnerability scanning device X corresponding to "Medium Risk-Medium Stability") generated in step 32 and the "Initial Resource Adaptation Data" of each attack chain stage (containing the main resources, backup resources and their risk-capability adaptability of each stage) as the processing objects, first analyze the progressive dependency relationship of each stage of the attack chain (reconnaissance and detection → vulnerability exploitation → lateral movement → data theft → attack withdrawal), and clarify the influence intensity between stages - the direct preceding stage (such as the direct preceding stage of the vulnerability exploitation stage is the reconnaissance and detection stage) has the strongest influence on the current stage, the indirect preceding stage (such as the indirect preceding stage of the lateral movement stage is the reconnaissance and detection stage) has the second strongest influence, and the subsequent stages have no influence on the current stage;

[0090] Based on the strength of stage dependency, each "risk level - stability label" combination in the "Association Mapping Table of Risk Level and Resource Adaptation Stability Labels" is assigned a cross-stage association weight: the combination weight of the direct preceding stage and the current stage is configured as 0.3 (e.g., the weight of "reconnaissance and detection stage - high risk - high stability" to "vulnerability exploitation stage - medium risk - medium stability"), the combination weight of the indirect preceding stage and the current stage is configured as 0.1 (e.g., the weight of "reconnaissance and detection stage - high risk - high stability" to "lateral movement stage - low risk - low stability"), and the weight of non-associated stage combinations is 0; the weights of different "risk level - stability label" combinations within the same stage are adjusted according to their support capabilities for subsequent stages (e.g., the weight of the "high stability" label combination is higher than that of "low stability"), forming a "cross-stage association weight table" to reflect the impact of the continuity of the attack chain stages in the scenario on resource adaptation.

[0091] Extract the initial resource adaptation data for each stage of the attack chain and organize it according to the structure of "stage-primary resource-backup resource-adaptability-risk level-stability label" to form a "stage initial adaptation data table"; for example, the initial data for the vulnerability exploitation stage is: primary resource device X (adaptability 0.8, medium risk, medium stability), backup resource platform Z (adaptability 0.86, medium risk, high stability).

[0092] Based on the "Cross-Phase Association Weight Table", multi-stage adaptation and fusion calculations are performed on the "Phase Initial Adaptation Data Table". Taking the lateral movement phase as an example, its direct predecessor is the vulnerability exploitation phase, and its indirect predecessor is the reconnaissance and detection phase. The fusion adaptation degree of the main resource in the lateral movement phase = its own initial adaptation degree + (adaptation degree of the main resource in the vulnerability exploitation phase × cross-stage weight of the combination of the two) + (adaptation degree of the main resource in the reconnaissance and detection phase × cross-stage weight of the combination of the two). Assuming that the initial adaptation degree of the main resource in the lateral movement phase is 0.75, the adaptation degree of the main resource in the vulnerability exploitation phase is 0.8 and the combined weight is 0.3, and the adaptation degree of the main resource in the reconnaissance and detection phase is 0.9 and the combined weight is 0.1, then the fusion adaptation degree = 0.75 + (0.8 × 0.3) + (0.9 × 0.1) = 0.75 + 0.24 + 0.09 = 1.08 (take 1.0 when it exceeds 1.0). The fusion adaptation degree of the main resources and backup resources in all phases is calculated according to this logic to form the "Phase-Resource Fusion Adaptation Degree Table".

[0093] Resources are prioritized based on their integration compatibility at each stage: within the same stage, the resource with the highest integration compatibility is the first choice, and the second highest is the backup resource; if the integration compatibility is the same, resources with higher stability labels are preferred (e.g., "high stability" is better than "medium stability"); for example, in the vulnerability exploitation stage, the integration compatibility of platform Z is calculated to be 0.92, which is higher than that of device X (0.88), so platform Z is adjusted to be the first choice resource, and device X is the backup resource, forming a "stage-resource priority table";

[0094] The "Phase-Resource Priority Table" is associated with the risk level identifiers of each phase, organized according to the attack chain phase sequence, and the preferred resources, backup resources, resource activation order, and risk level indications for each phase are clearly defined (e.g., "Vulnerability Exploitation Phase - Medium Risk: Preferred Platform Z, Backup Device X"). At the same time, cross-phase resource collaboration requirements are marked (e.g., "The scanning results of device Y in the reconnaissance and detection phase need to be synchronized to platform Z in the vulnerability exploitation phase"), forming a "Draft of Task-Resource Scheduling Configuration Table with Risk Level Identifiers".

[0095] The initial draft of the scheduling plan is tested for feasibility: it is checked whether there are compatibility issues with cross-stage resources (such as whether the data format of device Y is supported by platform Z), whether the resource load exceeds the laboratory's simultaneous operation limit (such as whether more than 3 high-load devices are scheduled at the same time), and whether the matching of risk level and resource stability meets the requirements of the "Risk Level-Resource Capacity Threshold Table". Based on the test results, the resource priority is adjusted or the resource coordination rules are supplemented, and finally the "Task-Resource Scheduling Configuration Table with Risk Level Identifier" is generated, which provides a clear resource scheduling basis for the digital instruction coding in step 4.

[0096] This implementation process differs from the traditional approach of independently adapting resources at each stage. By introducing cross-stage correlation weights, the progressive relationship of the attack chain is quantified into an influencing factor for resource adaptation. This enables resource scheduling to not only meet the needs of a single stage but also adapt to the collaborative requirements of the entire chain, solving the problem of "isolated resource adaptation at each stage and poor overall collaboration" in traditional scheduling. At the same time, by combining the calculation of risk level and stability label, the scheduling scheme is ensured to have high execution stability while controlling risks.

[0097] Optionally, step 4 specifically involves: based on the task-resource scheduling configuration table with risk level identifiers, performing digitized instruction layer-by-layer encoding according to the attack chain stage timing and resource type differences, synchronously tracking the execution process of each layer of encoding and recording anomaly handling information, so as to generate a scheduling execution and anomaly handling record table with instruction timing trajectory.

[0098] Optionally, step 4 specifically includes step 41: determining the attack chain stage layer based on the task-resource scheduling configuration table with risk level identifiers; performing digital instruction layering encoding on the attack chain stage layer according to the differences in attack chain stage timing and resource type to obtain an instruction layering dimension table, so as to synchronously track the execution process of the instruction layering dimension table and record anomaly handling information.

[0099] Preferably, the specific implementation process of step 41 is as follows: Taking the task-resource scheduling configuration table with risk level identifier (which includes the preferred resources, backup resources, risk level and cross-stage collaboration requirements for each attack chain stage, such as "Vulnerability Exploitation Stage - Medium Risk: Preferred platform Z, which needs to receive scanning data from device Y in the reconnaissance and detection stage") as the core input, the scheduling scheme is first layered according to the attack chain stage sequence (reconnaissance and detection → vulnerability exploitation → lateral movement → data theft → attack withdrawal) to determine the "attack chain stage layer" - each stage is an independent level, and the level identifier includes the stage name and risk level (such as "reconnaissance and detection stage - low risk" and "vulnerability exploitation stage - medium risk"), forming an "attack chain stage layer list" to clarify the top-level structure of the instruction code;

[0100] Based on the "Attack Chain Stage Layer List," each stage layer is further subdivided according to resource type differences: resource types include reconnaissance (such as port scanning devices and traffic analysis tools), vulnerability (such as vulnerability scanning devices and verification platforms), and tracing (such as lateral movement trajectory recording tools and data flow monitoring devices), etc., with each type serving as a "resource type sub-layer" under the stage layer; for example, the vulnerability exploitation stage layer is divided into "vulnerability scanning device sub-layer" and "vulnerability verification platform sub-layer." The sub-layer identifier includes the resource type and the corresponding preferred / alternate attributes (such as "vulnerability verification platform - preferred"), forming a "stage-resource type hierarchical table," enabling instruction encoding to distinguish the operational requirements of different types of resources;

[0101] For each resource type sub-layer in the "Phase-Resource Type Hierarchy Table", the "Operation Instruction Sub-layer" is further divided according to the differences in operation type: operation types include startup type (such as device power-on, parameter loading), execution type (such as vulnerability scanning, data collection), collaboration type (such as data synchronization, result upload), and termination type (such as task pause, device shutdown); each operation type corresponds to a set of specific instructions. For example, the execution type operations of "Vulnerability Verification Platform - Preferred" include "Load CVE-2023-XXX vulnerability database" and "Set verification timeout threshold", forming the "Resource Type-Operation Instruction Hierarchy Table" and clarifying the specific operations that need to be encoded in each sub-layer;

[0102] A hierarchical coding rule for digital instructions is established: a four-segment coding structure of "stage code - resource type code - operation type code - instruction sequence number" is adopted. The stage code is represented by uppercase letters according to the time sequence (e.g., A for reconnaissance and detection stage, B for vulnerability exploitation stage); the resource type code is represented by two digits (01 for reconnaissance class, 02 for vulnerability class); the operation type code is represented by lowercase letters (s for startup class, e for execution class); the instruction sequence number is represented by two digits (the order of instructions under the same operation type); at the same time, a risk level identifier is attached to the end of the code (H for high risk, M for medium risk, L for low risk), such as the vulnerability exploitation stage (B) vulnerability verification platform (02) execution class (e) first instruction (01) with medium risk (M), the code is "B-02-e-01-M"; this rule ensures that the code can reflect the hierarchical relationship and associate the risk level, forming a "digital instruction hierarchical coding rule table";

[0103] Based on the "Digital Instruction Hierarchical Encoding Rule Table", all operation instructions in the "Resource Type-Operation Instruction Hierarchical Table" are encoded: for example, the "Load Target IP Segment" instruction of the port scanning device (01) in the reconnaissance and detection phase (A) is encoded as "A-01-s-01-L" (assuming low risk); the encoding is associated with the description information of the corresponding instruction (such as "Load Target IP Segment: 192.168.1.0 / 24") to form an "Instruction Hierarchical Dimension Table", which contains fields such as hierarchical path (phase layer → resource type sub-layer → operation instruction sub-layer), instruction encoding, instruction description, associated resources, and risk level identifier;

[0104] An instruction execution tracking mechanism is constructed based on an "instruction hierarchical dimension table": a unique execution status identifier (not executed, executing, completed, abnormal) is configured for each instruction code; the operation logs of each resource are collected in real time through the laboratory resource management system; the operation events in the logs are matched with the instruction codes (e.g., the "vulnerability database loading completed" log of platform Z matches the code "B-02-e-01-M"), and the execution status of the instructions is updated synchronously; when an abnormal event is detected (e.g., "loading timeout" or "data format error"), the abnormality type, occurrence time and associated code are marked in the tracking record to form an "instruction execution tracking table";

[0105] Link the "Instruction Hierarchical Dimension Table" with the "Instruction Execution Tracking Table" and supplement the record fields of exception handling information (such as backup instructions triggered by exceptions and records of manual intervention) to form an "Instruction Hierarchical Dimension Table with Tracking Status". This provides basic data containing execution status for step 42 "Configure Hierarchical Instruction Element Set", ensuring that subsequent tracking and exception handling can be accurately linked to instructions at specific levels.

[0106] This implementation process differs from traditional flat instruction coding methods. Through a multi-level structure of "stage-resource type-operation type" and risk level embedding, the coding can reflect the temporal logic of the attack chain and distinguish the differences between resources and operations. This solves the problems of "difficult instruction location and inefficient cross-stage collaborative tracking" caused by the ambiguity of the hierarchy in traditional coding. At the same time, integrating risk levels into the coding allows execution tracking to prioritize high-risk instructions, improving the targeting and efficiency of instruction execution monitoring in laboratory threat assessment scenarios.

[0107] Optionally, step 4 specifically includes step 42: configuring a hierarchical instruction element set for the instruction hierarchical dimension table, which includes instruction triggering conditions, operation parameters, and expected execution duration; and, based on the hierarchical instruction element set, synchronously tracking the execution process of the instruction hierarchical dimension table to obtain a scheduling execution table of instruction timing trajectory and recording the exception handling information therein.

[0108] Preferably, the specific implementation process of step 42 is as follows: Based on the "instruction hierarchical dimension table" generated in step 41 (which includes fields such as hierarchical path, instruction code, instruction description, associated resources, and risk level identifier, such as the code "B-02-e-01-M" corresponding to the vulnerability library loading instruction of the preferred verification platform in the vulnerability exploitation stage), first configure a "hierarchical instruction element set" for each instruction in the table. This element set includes three core elements: instruction triggering conditions, operation parameters, and expected execution time. The element configuration needs to be combined with the correlation and risk level requirements of resource operations in the laboratory threat assessment scenario.

[0109] Configuring command trigger conditions: Based on the progressive relationship of the attack chain stages and the dependency logic between commands, trigger conditions are divided into three categories: pre-command dependency type, event-driven type, and timed trigger type. Pre-command dependency type conditions are applicable to commands with a clear sequential relationship across stages or within the same stage (e.g., the "vulnerability verification" command in the vulnerability exploitation stage requires the successful execution of the "target port scan completed" command in the reconnaissance and detection stage as a trigger condition), and are associated through command encoding (e.g., the trigger condition of "B-02-e-01-M" is associated with the "completed" status of "A-01-e-03-L"). Event-driven type conditions are applicable to commands that need to respond to specific detection results (e.g., the trigger condition for the "lateral movement trajectory recording" command is "an abnormal login event detected"), and are associated with the event type identifier of the laboratory security event monitoring system. Timed trigger type conditions are applicable to periodic operations (e.g., the "data theft stage log backup" command is triggered once per hour), and specific time intervals or moments are configured; the trigger conditions are bound to the command encoding to form a "command-trigger condition mapping table."

[0110] Configure operation parameters: For each command corresponding to a resource type, extract the key technical parameters of that resource in the detection task (such as the vulnerability verification platform's "vulnerability database version", "number of verification threads", and "timeout threshold", and the port scanning device's "target IP segment", "scanning port range", and "scanning rate"). The determination of parameter values ​​should refer to the correlation coefficient (the higher the coefficient, the wider the configurable range of the parameter) and risk level in the detection resource technical capability matrix (high-risk command parameters need to be more stringent, such as the verification timeout threshold shortener). For example, the operation parameters for "B-02-e-01-M" (medium risk) are configured as "vulnerability database version: CVE-2023-Q3, number of threads: 4, timeout threshold: 30 seconds", forming the "command-operation parameter configuration table".

[0111] Configure expected execution time: Based on the average execution time of the same instruction in the laboratory's historical scheduling data, and combined with the risk level and operation parameters of the current instruction, adjust the expected execution time of high-risk instructions by 10%-20% compared to the historical average (to reserve an emergency buffer), and extend the expected execution time of low-risk instructions by 10% (to reduce resource pressure). For operation parameters involving large traffic or complex calculations (such as full port scanning), extend the expected execution time appropriately; for example, for a vulnerability database loading instruction with a historical average of 2 minutes, the expected execution time under medium risk is configured to be 2 minutes and 10 seconds (considering the time consumed by the increase in the number of threads); associate the expected execution time with the instruction code to form an "Instruction-Expected Execution Time Table";

[0112] Integrate the “Instruction-Trigger Condition Mapping Table,” “Instruction-Operation Parameter Configuration Table,” and “Instruction-Expected Duration Table,” and associate them with the “Instruction Hierarchical Dimension Table” according to the instruction code to generate a “Complete Table of Hierarchical Instruction Element Set.” Each record in the table includes the instruction code, hierarchical path, trigger condition, operation parameter, expected execution duration, associated resources, and risk level.

[0113] A synchronous tracking mechanism is constructed based on the "complete table of hierarchical instruction element set": Operation logs of each resource are collected in real time through the laboratory resource monitoring interface. Information such as instruction execution start time, current operation parameters, and execution duration in the logs are analyzed and compared with corresponding fields in the element set—checking whether triggering conditions are met (e.g., whether preceding instructions have been completed), whether operation parameters are consistent with the configuration (e.g., whether the number of threads is 4), and whether the execution duration is within the expected range (e.g., whether it exceeds the 30-second timeout threshold). The comparison results are recorded by timestamp to form a "scheduling and execution table of instruction timing trajectory," which includes instruction code, execution status (not triggered, triggering, executing, completed), actual start / end time, actual operation parameters, and real-time consumption.

[0114] During the tracking process, record anomaly handling information: When an anomaly is detected (such as starting a command when the trigger condition is not met, actual parameters deviating from the configuration by more than 10%, or execution time exceeding the expected 150%), automatically identify the anomaly type (trigger anomaly, parameter anomaly, timeout anomaly, etc.); call preset handling rules according to the anomaly type and risk level (such as automatically triggering the same command of the backup resource when there is a timeout anomaly and it is high risk; pushing parameter correction suggestions to the operator when there is a parameter anomaly); record the anomaly occurrence time, anomaly type, handling measures, and post-handling status (such as "B-02-e-01-M" triggering a timeout anomaly at 35 seconds, starting the "B-02-e-01-M" command of the backup platform Z, which is completed after 1 minute), and form an "Anomaly Handling Record Table";

[0115] The "Scheduling Execution Table with Instruction Timing Trajectory" and the "Exception Handling Record Table" are associated by instruction code and timestamp, and exception fields (such as whether an exception occurred and the result of exception handling) are added to generate the "Scheduling Execution and Exception Handling Record Table with Instruction Timing Trajectory". This table fully reflects the entire process data of each instruction from triggering to completion (or exception handling), and provides a quantitative basis for the execution process for step 5 to call the two-dimensional performance-delay model of scheduling strategy.

[0116] This implementation process differs from the traditional static configuration of command elements. By associating triggering conditions with attack chain stages, binding operational parameters with resource capabilities and risk levels, and dynamically adjusting expected durations, the element set is made more aligned with the dynamic execution scenario of laboratory threat assessment. This solves the problems of "chaotic command triggering and poor parameter adaptability" caused by neglecting correlation in traditional configuration. At the same time, anomaly handling is linked with real-time comparison of the element set to ensure that anomaly responses can be accurately located to specific parameters or triggering logic, improving the stability of scheduling execution and the efficiency of anomaly handling.

[0117] Optionally, step 5 specifically includes:

[0118] Step 51: Based on the scheduling execution and exception handling record table with instruction timing trajectory, call the two-dimensional performance-latency model of the scheduling strategy to calculate the resource performance decay data and instruction response latency data of each attack chain stage;

[0119] Step 52: Based on the resource performance degradation data and instruction response latency data of each attack chain stage, determine the stage adaptation compensation coefficient through two-dimensional cross-calibration calculation to generate policy scheduling parameters.

[0120] Preferably, the specific implementation process of step 51 is as follows: Taking the scheduling execution and exception handling record table with instruction timing trajectory (containing the code, trigger time, actual execution time, operation parameter deviation, exception type and handling result of each instruction, such as the instruction "B-02-e-01-M" is triggered at 10:05, actually executed for 45 seconds, parameter deviation 5%, no exception) as the core input, the scheduling strategy dual-dimensional performance-delay model (this model includes a performance dimension calculation module and a response delay dimension calculation module, which are dual-dimensional collaboratively related to the resource execution characteristics of the attack chain stage) is called to first extract staged data from the record table;

[0121] The instruction data in the record table is grouped according to the attack chain stage (reconnaissance and detection, vulnerability exploitation, etc.). Information such as the associated resource ID, actual execution result (e.g., vulnerability verification success rate, scan coverage), expected execution result (based on the hierarchical instruction element set in step 42), number of anomaly handling, and total execution time of all instructions in each stage is extracted to form an "Attack Chain Stage - Resource Execution Data Table". For example, the associated resource of the vulnerability exploitation stage is platform Z, which contains the execution data of 3 instructions. Among them, 2 completed the expected result, and 1 resulted in a 10% decrease in result coverage due to parameter deviation, forming the basic data set of this stage.

[0122] Calculate resource performance degradation data for each stage of the attack chain: Resource performance degradation data reflects the difference between the actual and initial capabilities of resources during stage execution, including three sub-items: degradation rate, degradation trigger point, and anomaly correlation. The degradation rate is calculated as: (1 - average actual execution result / average expected execution result) × 100%. The average actual execution result is the average of the result parameters of all instructions in that stage (such as the average success rate of vulnerability verification). The average expected execution result is determined based on the correlation coefficient between the resource and the stage in the detection resource technical capability matrix (coefficient 0.8 corresponds to an expected success rate of 80%). For example, the average actual success rate of platform Z in the vulnerability exploitation stage is 72%, and the expected success rate is 80%, so the degradation rate = (1 - 72% / 80%) × 100% = 10%.

[0123] The decay trigger point is determined by the instruction timing trajectory: with the timestamp as the horizontal axis, the deviation between the actual execution result and the expected value of each instruction is recorded. The instruction execution time point when the deviation first exceeds 10% is the decay trigger point (e.g., the second instruction in the vulnerability exploitation phase has a deviation of 12% when it is executed at 10:15, so the trigger point is 10:15); the anomaly correlation is the proportion of the performance decrease caused by anomaly handling in this phase to the total decay rate (e.g., if the total decay rate is 10%, and 3% is caused by anomaly handling, the correlation is 30%); the three sub-items are integrated to form the "Attack Chain Phase - Resource Performance Decay Data Table";

[0124] Calculate instruction response latency data for each stage of the attack chain: Instruction response latency data reflects the delay characteristics from the fulfillment of the trigger condition to the actual start of execution of an instruction, including three sub-items: average latency, latency volatility, and risk-related latency. The average latency is the average of (actual start time - trigger condition fulfillment time) of all instructions in this stage. The trigger condition fulfillment time is taken from the completion time of the preceding instruction or the occurrence time of the event in the record table (e.g., the trigger condition of "B-02-e-01-M" is fulfilled at 10:05:00, and the actual start time is 10:05:03, with a latency of 3 seconds).

[0125] The time-lag volatility is the ratio of the standard deviation to the average time-lag of the time-lag data in this stage (reflecting the stability of the time-lag; the higher the ratio, the worse the stability). For example, in the vulnerability exploitation stage, the time lags of the three instructions are 3 seconds, 5 seconds, and 4 seconds, with an average of 4 seconds, a standard deviation of ≈0.816, and a volatility of ≈20.4%. The risk-related time lag is the difference between the average time lag of high-risk instructions and the overall average time lag of this stage (e.g., the average time lag of high-risk instructions in this stage is 5 seconds, while the overall average is 4 seconds, with a difference of 1 second). Integrating these three sub-items forms the "Attack Chain Stage - Instruction Response Time Lag Data Table".

[0126] Perform intra-stage correlation verification on the "Resource Performance Decay Data Table" and the "Command Response Lag Data Table": check whether the decay trigger point coincides with the high-latency command (e.g., the command latency corresponding to the decay trigger point 10:15 is 5 seconds, which is higher than the average latency), and whether the abnormal correlation degree is positively correlated with the high-risk correlation latency (e.g., the abnormal correlation degree of 30% corresponds to the risk correlation latency of 1 second), to ensure that the two-dimensional data reflects the inherent correlation of resource execution; correct outliers based on the verification results (e.g., remove extreme latency data caused by sudden network interruption), and finally generate the "Summary Table of Resource Performance Decay Data and Command Response Lag Data for Each Attack Chain Stage", providing quantitative input for the two-dimensional cross-calibration in step 52.

[0127] This implementation process differs from traditional single-dimensional performance or time-delay assessment methods. By constructing a two-dimensional model, it correlates resource performance degradation with command response time delay. In particular, it introduces the staged characteristics of the degradation trigger point and risk-related time delay, enabling the data to not only reflect the differences in results but also locate the time nodes of performance decline and the correlation between time delay and risk. This solves the problem of "insufficient targeting of scheduling optimization" caused by traditional assessments neglecting process correlation. At the same time, by combining the progressive nature of attack chain stages in laboratory threat assessment scenarios, it ensures that data calculation matches the stage characteristics (such as focusing more on the impact of time delay on the attack window in the vulnerability exploitation stage), improving the accuracy of data support for scheduling strategy optimization.

[0128] Preferably, the specific implementation process of step 52 is as follows: Taking the "Summary Table of Resource Performance Attenuation Data and Command Response Lag Data for Each Attack Chain Stage" generated in step 51 (which includes sub-items such as attenuation rate, attenuation trigger point, abnormal correlation, average lag, lag fluctuation rate, and risk-related lag for each stage, such as attenuation rate of 10% and average lag of 4 seconds in the vulnerability exploitation stage) as the processing object, a dual-dimensional cross-calibration calculation mechanism is initiated. This mechanism quantifies the comprehensive impact of the performance dimension and response lag dimension on stage adaptation through the synergistic correlation between the two, so as to determine the stage adaptation compensation coefficient.

[0129] The resource efficiency degradation data and command response time delay data are standardized: the degradation rate (0-100%) is converted into an efficiency degradation index between 0 and 1 (e.g., a 10% degradation rate corresponds to 0.1); the average time delay is converted into a time delay index between 0 and 1 (based on the expected maximum allowable time delay of this stage, e.g., if the expected maximum time delay is 10 seconds, the actual average time delay of 4 seconds corresponds to 0.4); the anomaly correlation degree and risk correlation time delay are standardized according to the same logic to form a "stage-dual-dimensional standardized data table", eliminating the difference in the dimensions of different indicators and ensuring the operability of cross-calibration;

[0130] Based on the risk level configuration of the attack chain stages, a two-dimensional weight is configured: high-risk stages (such as the vulnerability exploitation stage) require higher command response speed, with a time delay dimension weight of 0.6 and a performance degradation dimension weight of 0.4; medium-risk stages (such as the lateral movement stage) have a balanced weight of 0.5 for both; low-risk stages (such as the attack withdrawal stage) focus more on performance stability, with a performance degradation dimension weight of 0.6 and a time delay dimension weight of 0.4; forming a "risk level-two-dimensional weight table" to ensure that calibration calculations align with the core needs of different stages;

[0131] Calculate the two-dimensional comprehensive deviation value: For each stage, multiply the standardized performance decay index by the corresponding weight to obtain the performance dimension deviation score; multiply the standardized time delay index by the corresponding weight to obtain the time delay dimension deviation score; the sum of the two is the two-dimensional comprehensive deviation value for that stage (range 0-1, the higher the value, the greater the adaptation deviation); for example, in the vulnerability exploitation stage (high risk), the performance decay index is 0.1×0.4=0.04, the time delay index is 0.4×0.6=0.24, and the comprehensive deviation value is 0.28;

[0132] The overall deviation value is corrected through cross-calibration: the correlation between performance degradation and response latency is analyzed. If the degradation trigger point of a certain stage coincides with the high latency instruction time (e.g., degradation is triggered at 10:15, corresponding to an instruction latency of 5 seconds, which is higher than the average latency), it indicates that the two have a mutually reinforcing effect. A correlation correction of 10%-20% is added to the overall deviation value (e.g., due to the correlation effect in the vulnerability exploitation stage, the corrected overall deviation value = 0.28 × 1.15 = 0.322); if the two have no obvious correlation (e.g., degradation is caused by resource aging and is unrelated to instruction latency), no correction is made; a "Stage-Calibration Post-Overall Deviation Value Table" is generated.

[0133] The stage adaptation compensation coefficient is determined based on the overall deviation value after calibration. The compensation coefficient is divided into an effectiveness compensation sub-coefficient and a time delay compensation sub-coefficient, the sum of which is 1, and it is consistent with the weighting of the two dimensions (e.g., the time delay compensation sub-coefficient accounts for 0.6 in the high-risk stage). The effectiveness compensation sub-coefficient = overall deviation value after calibration × effectiveness dimension weight × compensation benchmark coefficient (the benchmark coefficient is 1.2 to ensure the compensation covers the deviation); the time delay compensation sub-coefficient = overall deviation value after calibration × time delay dimension weight × compensation benchmark coefficient; for example, the effectiveness compensation sub-coefficient for the vulnerability exploitation stage = 0.322 × 0.4 × 1.2 ≈ 0.154, the time delay compensation sub-coefficient = 0.322 × 0.6 × 1.2 ≈ 0.232, and the stage adaptation compensation coefficient = 0.154 + 0.232 ≈ 0.386 (coefficient range 0-1, the higher the value, the greater the compensation required).

[0134] Perform cross-stage compensation coordination verification: Due to the progressive nature of the attack chain stages (e.g., compensation in the reconnaissance and detection stage affects the exploitation stage), it is necessary to check the correlation between compensation coefficients of adjacent stages—when the compensation coefficient of the preceding stage is higher than 0.5, the compensation coefficient of the subsequent stage needs to be increased by 5%-10% in coordination compensation (e.g., if the compensation coefficient of the reconnaissance and detection stage is 0.6, after coordination compensation in the exploitation stage it becomes 0.386×1.08≈0.417), to ensure the continuity of compensation throughout the entire chain; form a "stage-final adaptation compensation coefficient table";

[0135] The final adaptation compensation coefficients are transformed into strategy scheduling parameters: the efficiency compensation sub-coefficient corresponds to resource adjustment parameters (e.g., increasing the proportion of reserve resources, coefficient 0.154 corresponds to an increase of 15.4% in reserve resources); the time delay compensation sub-coefficient corresponds to instruction optimization parameters (e.g., shortening the instruction trigger interval, coefficient 0.232 corresponds to a 23.2% reduction in the trigger interval); combined with the stage risk level and resource technical capability matrix, the specific implementation values ​​of the parameters are clarified (e.g., increasing reserve resources by 15% and shortening the trigger interval by 20% during the vulnerability exploitation stage), generating a "strategy scheduling parameter table adapted to the full-link scheduling requirements". This parameter table is directly used for the full-link digital scheduling optimization of laboratory testing tasks, achieving a dynamic balance between resource efficiency and response speed.

[0136] This implementation process differs from traditional single-dimensional compensation methods. By using dual-dimensional cross-calibration, the correlation between performance degradation and instruction latency is quantified into a correction amount. This allows the compensation coefficient to not only reflect the deviation of a single indicator but also the mutual influence between the two, solving the "one-sided" problem caused by neglecting dimensional coordination in traditional compensation. At the same time, by combining the risk level and progressive relationship of the attack chain stages to configure weights and collaborative compensation amounts, the parameters are ensured to adapt to the dynamic needs of the entire chain, improving the overall stability and efficiency of laboratory threat assessment task scheduling.

[0137] Figure 2 This is a schematic diagram of a digital scheduling device for the entire laboratory testing task chain, as described in an embodiment of this application. Figure 2 As shown, it includes: a decomposition unit: used to decompose the attack chain stages of the laboratory threat assessment and testing task requirements information to generate a detection task scenario feature vector table with attack chain stage labels; a profiling unit: used to construct a multi-dimensional profile of the technical capabilities of the laboratory's existing testing resources based on the detection task scenario feature vector table to generate a detection resource technical capability matrix with attack chain stage correlation coefficients; a scheduling unit: used to generate a task-resource scheduling configuration table with risk level identifiers based on the detection resource technical capability matrix; an encoding unit: used to perform hierarchical encoding of digital instructions on the task-resource scheduling configuration table to generate a scheduling execution and anomaly handling record table with instruction time sequence trajectories; and a parameter unit: used to call the scheduling strategy dual-dimensional performance-delay model to generate strategy scheduling parameters adapted to the full-link scheduling requirements based on the scheduling execution and anomaly handling record table with instruction time sequence trajectories for full-link digital scheduling of laboratory testing tasks.

[0138] The above Figure 2 The specific implementation of each unit in the embodiment can be found in the above. Figure 1 The details of that record will not be repeated here.

[0139] The relative descriptions such as “higher,” “lower,” “more targeted,” and “more relevant” mentioned in this application should be understood objectively in conjunction with the technical background and current level of technology in laboratory threat assessment, and are not intended to describe an ideal state in which the technical effect reaches an absolute. For those skilled in the art, the core function of such statements is to objectively reflect the relative improvement in technical effect achieved by this application through specific technical designs such as "attack chain stage decomposition to generate a labeled feature vector table", "multi-dimensional profiling of detection resources to construct a technical capability matrix with correlation coefficients", "digital instruction hierarchical encoding to generate an execution and anomaly handling record table with time-series trajectory", and "two-dimensional efficiency of scheduling strategy - time delay model to generate strategy scheduling parameters adapted to the whole link"—that is, compared with the prior art, the solution of this application presents better performance in terms of the clarity of detection task stage requirements, the rationality of resource and stage requirements matching, the traceability of scheduling execution process, and the continuous optimization of scheduling parameters throughout the whole link, rather than an absolute promise of technical effect. This approach to description meets the requirements of rigor in technical solution description, enabling those skilled in the art to clearly identify the differences in technical effects between this application and existing technologies, and to accurately grasp the improvement value of the solution in the refined scheduling of the entire detection task chain in laboratory threat assessment scenarios.

Claims

1. A digital scheduling method for the entire process of laboratory testing tasks, characterized in that, include: Step 1: Decompose the attack chain stages of the laboratory threat assessment and detection task requirements information to generate a detection task scenario feature vector table with attack chain stage labels. Step 2: Based on the feature vector table of the detection task scenario, construct a multi-dimensional profile of the technical capabilities of the laboratory's existing detection resources to generate a detection resource technical capability matrix with attack chain stage correlation coefficients; Step 3: Generate a task-resource scheduling configuration table with risk level identifiers based on the detection resource technical capability matrix; Step 4: Perform digitized instruction layered encoding on the task-resource scheduling configuration table to generate a scheduling execution and exception handling record table with instruction timing trajectories; Step 5: Based on the scheduling execution and anomaly handling record table with instruction timing trajectory, call the two-dimensional performance-delay model of the scheduling strategy to generate strategy scheduling parameters that adapt to the full-link scheduling requirements for full-link digital scheduling of laboratory testing tasks. Step 1 specifically includes: Step 11: Decompose the laboratory threat assessment and detection task requirements information according to the attack chain stages under the threat assessment scenario to obtain the reconnaissance and detection stage, vulnerability exploitation stage, lateral movement stage, data theft stage, and attack withdrawal stage, and determine the detection requirement sub-items corresponding to each stage of the attack chain. Step 12: Extract the key technical parameters from each detection requirement sub-item, and use vector mapping to transform the key technical parameters corresponding to each stage into multi-dimensional vectors to generate a detection task scenario feature vector table with attack chain stage labels.

2. The end-to-end digital scheduling method for laboratory testing tasks according to claim 1, characterized in that, Step 2 specifically involves: constructing a matrix of existing laboratory testing resources based on the feature vector table of detection task scenarios with attack chain stage labels, in order to generate a detection resource technical capability matrix with attack chain stage correlation coefficients.

3. The end-to-end digital scheduling method for laboratory testing tasks according to claim 2, characterized in that, Step 2 specifically includes: Step 21: Using the feature vector table of detection task scenarios with attack chain stage labels as a reference, classify and sort out the existing detection resources in the laboratory, determine the physical attributes and functional boundaries of each detection resource, so as to obtain a list of detection resource classifications and matrix the existing detection resources in the laboratory. Step 22: Based on the classification list of testing resources, evaluate the technical capability parameters of each testing resource to obtain the technical parameters of the testing resources, so as to matrix the existing testing resources in the laboratory; Step 23: Based on the set of technical parameters of the detection resources, calculate the matching degree between each detection resource and the needs of each stage of the attack chain through the scenario-based parameter comparison method, so as to matrix the existing detection resources of the laboratory.

4. The end-to-end digital scheduling method for laboratory testing tasks according to claim 3, characterized in that, Step 2 specifically includes step 24: Based on the matching degree of each detection resource with the needs of each stage of the attack chain, determine the correlation coefficient between detection resources and attack chain stages through stage correlation quantification rules, so as to construct a detection resource technical capability matrix. In this matrix, the rows correspond to each detection resource in the detection resource classification list, the columns correspond to each stage of the attack chain, and the intersection of the rows and columns is filled with the correlation coefficient between detection resources and attack chain stages.

5. The end-to-end digital scheduling method for laboratory testing tasks according to claim 4, characterized in that, Step 3 specifically involves: based on the detection resource technology capability matrix with attack chain stage correlation coefficients, dynamically adapting detection tasks and resources through the attack chain stage risk dual-factor evaluation model, generating a correlation mapping table between risk level and resource adaptation stability label, and generating a task-resource scheduling configuration table with risk level identifiers.

6. The end-to-end digital scheduling method for laboratory testing tasks according to claim 5, characterized in that, Step 3 specifically includes: Step 31: Based on the detection resource technology capability matrix with attack chain stage correlation coefficient, construct a two-factor risk assessment model for attack chain stage, where the first factor is the attack impact diffusion factor and the second factor is the vulnerability exploitation success rate factor. Calculate the comprehensive risk assessment value of the attack chain stage based on the two-factor risk assessment model to generate a correlation mapping table between risk level and resource adaptation stability label. Step 32: Based on the comprehensive risk assessment value of the attack chain stage, the detection task and the backup resource are dynamically adapted to the risk level by using the historical adaptation stability data of the detection task in the same attack chain stage, so as to calculate the risk-capability adaptation degree, and generate an association mapping table between risk level and resource adaptation stability label according to the risk-capability adaptation degree. Step 33: Assign cross-stage association weights to each risk level-stability label combination in the association mapping table between risk level and resource adaptation stability label. Based on the cross-stage association weights, perform multi-stage adaptation fusion calculation processing on the initial resource adaptation data of each attack chain stage to generate a task-resource scheduling configuration table with risk level identifiers.

7. The end-to-end digital scheduling method for laboratory testing tasks according to claim 6, characterized in that, Step 4 specifically involves: based on the task-resource scheduling configuration table with risk level identifiers, performing digitized instruction layer-by-layer encoding according to the attack chain stage timing and resource type differences, synchronously tracking the execution process of each layer of encoding and recording anomaly handling information, in order to generate a scheduling execution and anomaly handling record table with instruction timing trajectory.

8. The end-to-end digital scheduling method for laboratory testing tasks according to claim 7, characterized in that, Step 4 specifically includes: Step 41: Determine the attack chain stage layer based on the task-resource scheduling configuration table with risk level identifier; digitize the attack chain stage layer with instruction layering encoding according to the attack chain stage sequence and resource type differences to obtain the instruction layering dimension table, so as to synchronously track the execution process of the instruction layering dimension table and record the abnormal handling information. Step 42: Configure a hierarchical instruction element set for the instruction hierarchical dimension table, including instruction triggering conditions, operation parameters, and expected execution duration; based on the hierarchical instruction element set, synchronously track the execution process of the instruction hierarchical dimension table to obtain the instruction timing trajectory scheduling execution table and record the exception handling information therein.

Images