Distributed security resource intelligent arrangement and adaptation method

Abstract

The invention discloses a distributed security resource intelligent arrangement and adaptation method. Distributed heterogeneous security resources are efficiently and automatically arranged in combination with capability tagging abstraction, a plug-in type adaptation agent architecture and an efficiency comprehensive optimization algorithm. For distributed security resources, lightweight adaptive agents are deployed at nodes, resource functions are split into standardized capability tags and reported to a registration center, and an arrangement decision module generates an optimal security service chain based on resource capabilities, real-time operation indexes and a multi-objective optimization algorithm according to user requirements analyzed by a strategy management module. And the scheduling distribution module serializes the scheme and issues the scheme to each adaptive agent to call a manufacturer interface to execute configuration, so that efficient, automatic and safe resource arrangement is realized. According to the method, unified management and dynamic arrangement of cross-manufacturer, cross-cloud and cross-network are realized, the method has the advantages of pluggable expansion, efficient automation, real-time online self-adaption and the like, and the arrangement efficiency and protection flexibility of distributed security resources are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to a method for intelligent orchestration and adaptation of distributed security resources. Background Technology

[0002] In today's information age, more and more enterprises are deploying multiple public clouds, private clouds, and edge nodes simultaneously to meet business performance requirements and geographical compliance requirements, forming a highly distributed and heterogeneous infrastructure environment. With the widespread deployment of cloud computing and edge computing, various security protection resources are characterized by distributed, multi-vendor, and heterogeneous deployments, while business needs are dynamically changing and threat scenarios are becoming increasingly complex. However, security management under this multi-cloud, multi-domain structure faces profound challenges. Security resources running on different cloud platforms and edge environments have their own interfaces, deployment methods, and capability granularities, severely hindering unified policy orchestration and management. Furthermore, with frequent dynamic changes in business and the continuous evolution of threat models, traditional static configuration and manual operation methods cannot respond in a timely manner, leading to reduced security protection efficiency and even the risk of missed or false alarms. Against this backdrop, how to achieve efficient orchestration of security resources in cross-domain, heterogeneous environments has become a critical issue that urgently needs to be addressed.

[0003] Existing centralized or single-resource management models cannot meet the needs for unified perception, orchestration, and real-time adaptation of various security resources in a distributed environment. On the one hand, security products from different vendors differ significantly in functional interfaces and capability granularity, and the fragmentation of resources in cross-domain and cross-cloud environments poses a significant obstacle to achieving unified scheduling of security resources. On the other hand, most current systems heavily rely on static configuration or manual intervention, resulting in low orchestration efficiency and a lack of dynamic feedback mechanisms based on real-time operational status and network performance. This makes it difficult to formulate and issue new security policies in a timely manner when business traffic surges or resource anomalies occur, thus affecting the continuity and reliability of security protection. Furthermore, for large-scale, multi-tenant, and multi-regional environments, there is no universal method that can ensure security coverage while simultaneously considering performance overhead and compliance constraints.

[0004] Orchestration techniques for typical distributed resources in multi-cloud environments have long been extensively researched and applied. For example, multi-cloud orchestration techniques in research and business focus on cross-platform calls to Application Programming Interfaces (APIs) to coordinate compute, storage, and network resources, achieving high availability and cost optimization. These platforms employ declarative configuration and automated deployment mechanisms based on Kubernetes or similar systems, greatly simplifying the complexity of distributed service deployment. However, these approaches are primarily infrastructure-oriented rather than security-policy-oriented, prioritizing efficiency over security. In edge scenarios, distributed edge orchestration platforms such as ZEDEDA are used to uniformly manage the deployment, security, and visualization monitoring of edge applications. These solutions achieve cross-device deployment and operational monitoring but lack an understanding of security product capabilities and policy-based orchestration mechanisms. Additionally, there are secure access service edge architectures, designed to integrate network and security capabilities into local nodes for unified policy control and interception. However, these are service-oriented and lack modeling for heterogeneous security resource capabilities and multi-resource link orchestration mechanisms.

[0005] Another related area is security orchestration, a technology system that integrates security teams, tools, and processes to automate and optimize security operations. Currently, the primary focus is on Security Orchestration, Automation, and Response (SOAR) platforms. SOAR platforms can uniformly collect security alerts from multiple sources, invoke various security capabilities through programmable interfaces, and trigger pre-designed scripts or workflows for automated responses, thereby improving incident response efficiency and accuracy. However, current security orchestration systems typically rely on resources from a single type or vendor, lacking a unified description and scheduling capability for multi-source heterogeneous security components, and cannot flexibly scale in multi-cloud and edge deployment scenarios. Enterprises encounter a wide variety of security products with vastly different interfaces in their real-world business environments, while the off-the-shelf integration and plugin coverage provided by SOAR platforms is often very limited, lacking a unified policy and resource abstraction layer. Products from different vendors require extensive customization when integrated into the orchestration platform, increasing system integration costs and the complexity of maintenance and upgrades. Therefore, project implementation often requires investment of professional services and internal resources to plan integration solutions. In this context, SOAR’s scalability and flexibility become particularly important. A good orchestration solution needs to support “plug-and-play” toolkits and modular plugins to quickly adapt to changes in the environment.

[0006] Besides the automation difficulties caused by interface differences, current security orchestration technologies also face challenges in the flexibility and controllability of automation strategies. SOAR automation needs to strike a balance between efficiency and security. Existing methods mostly rely on manual configuration or static deployment based on preset templates, lacking dynamic awareness of runtime performance metrics and network link conditions. Orchestration decisions struggle to reflect actual resource availability in real time, easily leading to overload or policy failure. Furthermore, excessive automation can pose risks due to misjudgments or configuration errors, such as incorrectly blocking normal traffic or mistakenly deleting credentials. Therefore, script design often requires the inclusion of manual approval, conditional judgments, and rollback mechanisms to maintain the controllability of "human-machine collaboration." Simultaneously, different business environments have varying requirements for response strategies, necessitating platform support for multi-level customization: for example, different response strategies can be set based on asset value for the same threat. How to flexibly customize and adjust automation strategies is a key challenge that needs to be addressed in the advancement of SOAR.

[0007] Therefore, it is necessary to design a universal security resource orchestration method that can be used across vendors, clouds, and networks to solve the problems of integrated and intelligent optimization strategies for distributed heterogeneous security resources, and achieve high-efficiency and high-reliability security orchestration. Summary of the Invention

[0008] This invention addresses the shortcomings of existing technologies by proposing a method for intelligent orchestration and adaptation of distributed security resources. This method deploys adaptation agents on cloud platforms or edge nodes with security resources, simultaneously tagging and collecting local security resource capabilities and uploading resource performance metrics. An orchestration decision module then formulates and distributes orchestration schemes based on parsed user-defined policies, achieving efficient orchestration, dynamic provisioning, and elastic scaling of distributed heterogeneous security resources. This method abstracts security capabilities through tags and, combined with the pluggable adaptation agent's ability to shield the underlying interfaces of security resources, improves the scalability and flexibility of security resources. Furthermore, when specifying an orchestration scheme, the orchestration decision module receives real-time resource performance metrics collected from the adaptation agent by the monitoring center. During the orchestration scheme formulation, a multi-objective optimization algorithm comprehensively considers security coverage, cost, latency, and load balancing, achieving a balance between security, economy, and availability, effectively improving orchestration efficiency.

[0009] To achieve the above objectives, the present invention provides the following technical solution:

[0010] A method for intelligent orchestration and adaptation of distributed security resources includes the following steps:

[0011] Step S1, Security Resource Exploration and Capability Tagging: Deploy an adaptation agent on a cloud platform or edge node with security resources to obtain local security resource information;

[0012] Step S2, Local Information Upload: Each adapter agent reports the security resource information it collects to the resource registration and discovery module for unified management and maintenance, and regularly reports the local security resource operation indicators, security event logs and network link indicators to the monitoring module;

[0013] Step S3, Policy Entry and Parsing: The policy management module receives and parses the new security policy entered by the user;

[0014] Step S4, Orchestration Scheme Generation: The orchestration decision module receives security requirements from the policy management module, and outputs a security orchestration scheme, namely the security service chain topology and corresponding resource instances and configurations, based on the available resource list obtained from the resource registration and discovery module and the real-time resource status and link performance data obtained from the monitoring module.

[0015] Step S5, Orchestration Scheme Serialization: The scheduling and distribution module serializes the security orchestration scheme from the orchestration decision module into a standardized "execution task list" and pushes the configuration information to each adaptor agent;

[0016] Step S6, Task Execution and Feedback: After receiving the task, the adapter calls the corresponding vendor's command-line interface (CLI) or API to execute the task based on the local resource type, verifies the effectiveness of the policy locally, and feeds back the status to the scheduling and distribution module.

[0017] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0018] 1. Achieve unified management and flexible scheduling of heterogeneous security resources. This invention decomposes the functions of multi-vendor and multi-type security resources into standardized capability tags, enabling unified description and dynamic perception of heterogeneous resources. Simultaneously, the method provided by this invention designs a centralized security resource management system, adapting to agents that automatically collect resource information and report it to the resource registration and discovery module, globally maintaining resource status, performance indicators, and geographical distribution in real time, completely resolving scheduling obstacles caused by resource dispersion and interface differences in multi-cloud / edge environments.

[0019] 2. Implement an intelligent dynamic orchestration decision-making mechanism. This invention constructs a scoring function based on multiple dimensions such as security coverage, end-to-end latency, resource cost, and load balancing. It dynamically generates the optimal service chain topology by combining real-time monitoring data, while taking into account security, real-time performance, and availability, achieving intelligent adaptation to the needs and characteristics of different tenants. The method also realizes adaptive adjustment of policies. When resources are abnormal or business needs change suddenly, policy degradation or path switching is automatically triggered through online re-orchestration closed loop to ensure the continuity of security protection.

[0020] 3. Achieve fully automated closed-loop execution. The method provided by this invention achieves end-to-end automation from policy to execution. The entire process, including policy entry, conflict verification, intelligent orchestration, scheme serialization, distributed deployment, local execution verification, and status feedback, requires no manual intervention. The policy activation speed is significantly improved. With a pluggable adaptation layer architecture, new vendor resources can be dynamically accessed through plugins using lightweight adaptation proxies. Only the corresponding CLI / API interface adapter needs to be implemented, without modifying the core engine, significantly reducing system expansion costs.

[0021] 4. Optimize security orchestration performance and cost. The method provided by this invention prioritizes low-load, geographically proximate resource nodes in orchestration decisions, reducing cross-domain traffic overhead and ensuring maximum resource utilization. Furthermore, by replacing manual inspections with automated policy conflict checks, version management, and audit logs, it effectively reduces manual workload and significantly lowers operational costs.

[0022] In summary, the distributed security resource intelligent orchestration and adaptation method proposed in this invention can effectively adapt to cross-domain and cross-vendor security resources, improve their flexibility and scalability, and at the same time take into account security, availability and economy in the orchestration process, realize a closed loop in the whole process, effectively reduce manual intervention and improve orchestration efficiency. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0024] Figure 1 This is a schematic diagram of the module structure of a distributed security resource intelligent orchestration and adaptation method provided in an embodiment of the present invention.

[0025] Figure 2 A flowchart of a distributed security resource intelligent orchestration and adaptation method provided in an embodiment of the present invention. Detailed Implementation

[0026] To better understand this technical solution, the method of the present invention will be described in detail below with reference to the accompanying drawings.

[0027] This invention proposes a distributed security resource intelligent orchestration and adaptation method, involving 6 modules, the structure of which is as follows: Figure 1 As shown. This method consists of 6 main steps, and the overall process is as follows. Figure 2 As shown:

[0028] 1) Security resource exploration and capability tagging: Deploy adaptable agents on cloud platforms or edge nodes with security resources to obtain local security resource information;

[0029] 2) Local information upload: Each adapter agent uploads the security resource information it collects to the resource registration and discovery module for unified management and maintenance, and regularly reports the local security resource operation indicators, security event logs and network link indicators to the monitoring module;

[0030] 3) Policy Entry and Parsing: The policy management module receives and parses new security policies entered by users;

[0031] 4) Orchestration scheme generation: The orchestration decision module receives security requirements from the policy management module, and outputs a security orchestration scheme, namely the security service chain topology and corresponding resource instances and configurations, based on the available resource list obtained from the resource registration and discovery module and the real-time resource status and link performance data obtained from the monitoring module.

[0032] 5) Orchestration scheme serialization: The scheduling and distribution module serializes the security orchestration scheme from the orchestration decision module into a standardized "execution task list" and pushes the configuration information to each adapting agent;

[0033] 6) Task execution and feedback: After receiving the task, the adapter calls the corresponding vendor's command-line interface (CLI) or API to execute the task according to the local resource type, verifies whether the policy is effective locally, and feeds back the status to the scheduling and distribution module.

[0034] The steps are explained in detail below:

[0035] 1. Security resource exploration and capability labeling

[0036] First, to enable unified management and scheduling of local security resources across various cloud platforms or edge nodes, an adapter agent needs to be deployed on each node. This adapter agent runs as a containerized microservice or system daemon, and its main functions include resource discovery, capability abstraction, metadata management, and heartbeat reporting. Its purpose is to build a unified foundation for collecting distributed security resources in multi-cloud and cross-domain environments, providing complete, real-time, and reliable input data for subsequent orchestration and scheduling. The specific steps are as follows:

[0037] 1) Run the adaptation agent on the node

[0038] The target node used to deploy the adapter should already have a basic operating environment, such as Docker or a lightweight virtual environment that supports container operation, or a Python / Go runtime environment.

[0039] The adapter proxy is a service program used to discover local security resources, distribute specific configurations to security resources, and collect relevant operational metrics. It includes the following functions:

[0040] • Agent Core: The core service process used to coordinate various functional modules;

[0041] ●Resource Scanner: Local security resource scanning engine;

[0042] • Client-side resource registrar: The client that communicates with the resource registration module;

[0043] • Configure templates and scripts (Dockerfile, systemd unit, Kubernetes DaemonSet manifest, etc.).

[0044] According to the predefined deployment script, the adapter agent will be started as a container or daemon process and load the local configuration file, which defines parameters such as the registration module address, monitoring module address, node identifier, and log level.

[0045] 2) Local security resource scanning and identification

[0046] Dynamic Scanning: Upon startup, the resource scanner module automatically detects locally manageable security resource instances, including but not limited to firewalls, intrusion detection / prevention systems, web application firewalls, security gateways, log auditing components, and traffic mirroring devices. Scanning methods include: reading the list of installed software in the node's operating system (e.g., via package manager or system service list); querying security component information mounted in the local deployment directory or container orchestration platform (Kubernetes CRD, Docker Label); and calling the management interfaces (REST API, gRPC, CLI) of local security resources to obtain a list of basic capabilities.

[0047] Capability Abstraction: When the adapter performs resource scanning and capability identification locally, it breaks down resource functions into a set of predefined capability tags. For example, a Web Application Firewall (WAF) instance might be labeled PacketFiltering, SignatureDetection, or WebAttackProtection; an Intrusion Detection System (IDS) instance might be labeled ProtocolAnomalyDetection or BehavioralAnalysis. Each tag represents a category of security functions that can be invoked independently. The specific implementation process includes:

[0048] ① Function identification: Probe the protection functions supported by the resource (such as whether it supports web attack protection or behavioral analysis) through REST API, CLI command or software development kit (SDK) call;

[0049] ② Tag Mapping: Internal maintenance requirements - tag mapping table, which maps vendor functions to standard capability tags. For example, "OWASP ModSecurity rule set" is mapped to WebAttackProtection;

[0050] ③ Tag storage: Tag information and resource metadata are stored in the local cache and reported to the resource registration and discovery module for global query.

[0051] This capability labeling approach treats products from different vendors as "functionally equivalent" within this methodology, eliminating the need for deep adaptation of each API feature. Existing security orchestration systems often employ product-level integration, such as directly calling a vendor's WAF or IDS. However, due to the lack of a unified functional abstraction layer, it is impossible to replace "Web attack protection" with capabilities from different vendors, nor can it combine capabilities from multiple vendors to form a security chain. Therefore, compared to the traditional approach of "integrating vendors one by one," this method has high versatility.

[0052] For each type of discovered security resource, the agent breaks down its functionality into a set of standardized capability tags, such as packet filtering, signature detection, protocol anomaly detection, web attack protection, malware sandbox, log collection, audit analysis, etc., and populates the local metadata structure with the capability set and operational metrics (maximum throughput, minimum latency, supported protocol versions, etc.) corresponding to each instance.

[0053] 3) Local caching of resource metadata

[0054] The proxy maintains a lightweight resource description library locally. The description fields of the objects include resource ID, type, capability tag, performance parameters (maximum throughput, latency, etc.), interface endpoint, location, and status. An example of its data structure is as follows:

[0055]

[0056] When security resources on a node change (such as being added, uninstalled, or upgraded), the resource scanner will rescan every preset period (e.g., 60 seconds) after the initial scan and compare it with the local cache to update the records of newly added or offline resources.

[0057] 4) Heartbeat and metadata reporting

[0058] The adapter proxy, through the client resource registry module, batch reports the latest local resource description list to the central resource registration and discovery module via a secure encrypted channel (such as two-way TLS) for unified global management. Upload interface example:

[0059]

[0060] At the same time, the agent starts a heartbeat thread to report the node's liveness status to the registration module at a preset period (e.g., every 10 seconds), and provides feedback on operating indicators such as local CPU / memory load, network bandwidth usage, and online status of resource instances.

[0061] 5) Safety and reliability assurance

[0062] All communication with the registration and monitoring modules uses TLS two-way authentication to protect the confidentiality and integrity of reported data during transmission. The adapter has a disconnection reconnection and local caching mechanism: when communication with the registration or monitoring modules is not possible, the reported data is temporarily persisted to the local log and automatically resent after the network is restored, ensuring that the system's awareness of resource status is not lost. The adapter supports hot updates and canary upgrades, which facilitates online maintenance and rapid iteration.

[0063] 2. Upload local information

[0064] In this step, each adapter agent reports the security resource information it collects to the resource registration and discovery module for unified management and maintenance, and periodically reports local security resource operation metrics, security event logs, and network link metrics to the monitoring module. Through the collaboration of the adapter agents, registration module, and monitoring module, this step achieves unified management and real-time monitoring of distributed security resources, providing an accurate and reliable data foundation for subsequent intelligent orchestration and dynamic adjustment.

[0065] Detailed explanation is as follows:

[0066] 1) Resource information is reported to the registration module.

[0067] ① Reporting timing: After the initial deployment and completion of local resource scanning, the adaptation agent should immediately report all resource entries in the local "resource description library" once; when local resources are added, uninstalled, or undergo major configuration changes (such as upgrading rule sets or adjusting performance parameters), incremental reporting is triggered; to ensure consistency across the entire network, a full re-report is performed every preset period (e.g., 5 minutes) to correct any missing statuses.

[0068] ② Reporting interface and data format: Use RESTful API interface:

[0069]

[0070] Request body example:

[0071]

[0072]

[0073] ③ Report reliability assurance:

[0074] ●Idempotent design is enabled for reporting requests: Each record in the resource list is identified by a unique resource_id, and the registration module automatically deduplicates and updates the records based on this ID;

[0075] ● The proxy maintains a "reporting queue" locally, and sends an acknowledgment receipt (HTTP 200+ack) for each reporting result. If no acknowledgment is received, it retryes (exponential backoff) and records it in the local log.

[0076] ● For agent nodes that fail to report successfully for an extended period (>30 minutes), the registration module identifies them through heartbeat monitoring and issues an alarm, indicating that a network disconnection or agent failure may have occurred.

[0077] 2) Operational indicators and safety incidents are reported to the monitoring module.

[0078] ①Indicator categories and collection frequency

[0079] ● Operational metrics: These include CPU utilization, memory utilization, current throughput, number of active connections, queue length, etc., for local security resources. It is recommended to collect data every 10 seconds.

[0080] ● Security event logs: including interception events (such as firewall blocked entries), alarm events (IDS / IPS alarms), policy execution failure records, etc., are written to the local buffer in real time and summarized by minute;

[0081] ● Network link metrics: including outbound link latency, packet loss rate, bandwidth utilization, jitter, etc.

[0082] By combining active detection with passive statistics, a sampling frequency of 30 seconds per sampling is recommended.

[0083] ② Reporting channels and formats

[0084] A dedicated monitoring channel (such as one based on gRPC or message queues like Kafka / RabbitMQ) is used, separate from the registration module, to prevent monitoring data from interfering with the registration process; each type of data is reported in the following format:

[0085] Example of operating metrics:

[0086]

[0087] Example of a security event log (aggregated by batch):

[0088]

[0089]

[0090] Example of network link metrics:

[0091]

[0092] ③ Monitoring module processing and storage

[0093] After receiving the data, the monitoring module writes it to a time-series database (such as Prometheus / InfluxDB) and a log store (such as Elasticsearch), and then archives and indexes it.

[0094] To support real-time alarms and visualization, the monitoring module should be configured with alarm rules: such as triggering a threshold alarm and notifying the orchestration module when the CPU utilization of a certain resource exceeds 80%, the security event alarm rate suddenly increases, or the link packet loss rate exceeds 5%.

[0095] Data retention policy: High-frequency operation metrics are retained for 7 days, while security event logs and link metrics can be retained for a long time (30 days or longer) according to compliance requirements.

[0096] 3) Unified management and maintenance

[0097] Data model update of the registration module: The registration module synchronizes the received resource metadata and running status to the global resource table, and updates the online status, capability list and performance indicators of the resources; for offline (not reported if the heartbeat threshold is exceeded) or abnormal (indicator alarm) resources, the registration module marks them as "OFFLINE" or "FAULTY" in their status field for the orchestration decision module to filter.

[0098] Version management and auditing: All reported resource descriptions and metrics data are recorded with version numbers and timestamps, supporting backtracking and auditing; the registration and monitoring modules can query historical status changes based on node ID or resource ID, generate reports, and perform statistical analysis on agent performance.

[0099] 3. Strategy Input and Analysis

[0100] In this step, the policy management module receives the new security policy entered by the user, performs standardized parsing and high-reliability management on it, and provides clear and controllable policy input for subsequent orchestration decisions.

[0101] Detailed explanation is as follows:

[0102] 1) Strategy entry and verification triggering

[0103] When a user submits a new security policy in the operations and maintenance console or API interface, the policy management module first receives a request containing the complete policy content. The request can be submitted in two ways: graphical user interface (GUI) input, where operations and maintenance personnel fill out a policy form, including fields such as business link, policy type, and priority; or RESTful API call, where a third-party system or automated script POSTs the policy in JSON format to the / api / v1 / policy / create interface.

[0104] Upon receiving the request, the module immediately generates a strategy draft, creates a unique identifier draft_id for subsequent parsing and verification, and records the entry timestamp.

[0105] 2) Strategy format and syntax validation

[0106] The draft is validated using a predefined strategy description language, formatted as JSON Schema or YAML, with key fields including:

[0107]

[0108] The module uses a JSON Schema validation engine to verify each field of user-entered content, including: data type, required fields, value range, time format validation (ISO 8601), and the legality of business link nodes (unregistered business identifiers are not allowed). When validation fails, the module returns a detailed error list, prompting the user to make corrections.

[0109] 3) Strategy conflict and dependency check

[0110] After successful verification, the module compares the draft with the existing policy set to detect the following conflicts or dependencies:

[0111] ●Duplicate policies: Do policies with the same business links, the same security requirements, and the same effective time already exist?

[0112] • Priority conflict: If the new strategy has a higher priority than the existing strategy, it is necessary to confirm whether to cover or run in parallel;

[0113] ●Resource constraint conflict: Does the performance constraint specified in the policy exceed the maximum capacity that the system can provide (by calling the resource registration module to query the global maximum throughput and minimum latency);

[0114] For conflicting items, the module provides two modes: automatic mediation and manual intervention. Automatic mediation automatically adjusts the status of existing policies based on the "first-come, first-served" or "high-priority coverage" rules (such as marking old policies as "to be taken offline"). Manual intervention pushes the conflict details to the operation and maintenance platform as a to-do item, and the administrator decides how to handle it.

[0115] 4) Strategy Analysis and Functional Requirements Decomposition

[0116] Based on the policy description, the module breaks down high-level requirements into corresponding functional components. For example, "network attack defense" is broken down into "network application firewall" or "IDS with web protection capabilities," "malware sandbox" is broken down into "sandbox service," and "audit analysis" is broken down into "log collection + analysis," etc. Its parsing process includes:

[0117] ● Demand Mapping: Calls the built-in "Demand Mapping Table" to map strategy types to a set of capability tags;

[0118] ●Priority sorting: Sort each requirement item by weight according to the priority specified by the user or the default rules of the module, so as to guide the resource scheduling order of the orchestration engine;

[0119] ● Grouping and Scenario Labeling: Group strategy items by function and label them with "Business Scenario" (e.g., ...).

[0120] (Web application link, database access protection) to facilitate subsequent statistics and archiving.

[0121] 5) Metadata generation and version management

[0122] After parsing, a standardized strategy object is generated:

[0123]

[0124]

[0125] Persist policy objects to the policy version repository, recording version, status (Draft, Pending, Active, Deprecated) and modification history; support policy rollback and audit traceability.

[0126] 6) Preparation for Strategy Issuance

[0127] For policies that are parsed correctly and have a PENDING status, the module triggers a dispatch schedule: pushes the policy metadata to the input queue of the orchestration decision module; at the same time, updates the policy status to SCHEDULED and sets the start time effective_time. When the time is reached, the status is automatically updated to ACTIVE and officially included in orchestration execution.

[0128] 7) Security and Audit Assurance

[0129] The policy management module records audit logs for all input, modification, and parsing operations, including the operator, time, operation content, and status before and after the operation. The audit logs are stored in encrypted form and can be exported as reports or linked to the SIEM system for security monitoring according to compliance requirements. The module provides access control for the user interface, allowing only accounts with the corresponding roles (such as security administrators and compliance auditors) to create, modify, or delete policies.

[0130] 4. Arrangement scheme generation

[0131] In this step, the orchestration decision module receives security requirements from the policy management module. Based on the available resource list obtained from the resource registration and discovery module and the real-time resource status and link performance data obtained from the monitoring module, it outputs a security orchestration scheme, namely the security service chain topology and corresponding resource instances and configurations. This step realizes intelligent security orchestration decision-making based on policy requirements and real-time resource status, ensuring intelligent adaptation to the needs and characteristics of different tenants, and providing accurate and verifiable scheme input for subsequent scheduling, distribution, and execution.

[0132] Detailed explanation is as follows:

[0133] 1) Input reception and preprocessing

[0134] Policy retrieval: The orchestration decision module periodically or event-drivenly retrieves policy objects with an ACTIVE status and whose effective time has expired from the policy management module's message queue (such as KafkaTopic policy-ready). For each policy, the module generates an internal orchestration task, which includes the policy ID, version, parsed requirement list, and performance / region constraints.

[0135] Orchestration task initialization: Assign a unique task_id to each orchestration task, record the creation time, and persist it to the local orchestration task table; sort the policy requirements according to priority and group them by function (e.g., "Web protection", "sandbox detection", "audit analysis") to generate a requirement sequence.

[0136] 2) Available resource list search

[0137] ① Call the registration module interface

[0138] The orchestration module calls the resource registration and discovery module via a REST API:

[0139]

[0140] For each item in the demand sequence (such as WebAttackProtection, MalwareSandboxing, AuditAnalysis), initiate a query and summarize the returned list of resource candidates.

[0141] ② Candidate set construction

[0142] For each requirement tag, filter out resource instances that meet performance constraints (such as max_latency_ms, min_throughput_mbps) and use them as input for subsequent algorithms to construct a multi-dimensional attribute vector:

[0143]

[0144] 3) Real-time performance and status acquisition

[0145] The orchestration module pulls the latest operational metrics and link performance data from the monitoring module:

[0146]

[0147] The monitoring module returns real-time metric values ​​and link statistics for each resource.

[0148] Status verification and filtering: Perform threshold verification on the returned data, remove instances with CPU utilization exceeding the threshold (e.g., 80%), link packet loss rate exceeding the threshold (e.g., 5%), or latency exceeding the policy limit, mark the remaining resources as "available candidates", and update their real-time load, available bandwidth, and other attributes.

[0149] 4) Execution of orchestration decision algorithm

[0150] Based on the demand sequence and the corresponding candidate sets, multiple service chain combinations are generated (number of combinations = π candidate set size). Each combination represents a complete security service chain. Then, a comprehensive score is calculated for each combination, and the best combination is selected to achieve multi-objective optimization of security, cost, latency, and load availability. An example of a service chain combination is shown below:

[0151] Table 1 Examples of Service Chain Composition

[0152] Combination ID Web protection Sandbox audit Total delay Total throughput Total Cost Index C1 waf-001 sbx-101 AUD-501 8ms 5.5Gbps 2.2 C2 waf-002 sbx-102 aud-502 9ms 5Gbps 2.4 C3 waf-003 sbx-103 AUD-501 9.5ms 5Gbps 2.2

[0153] First, assess the security coverage of each resource instance in the candidate service chain combination:

[0154]

[0155] in:

[0156] i is the resource number;

[0157] RQ i The weight of the requirement is used to measure the importance of the relevant security requirement, and is specified by the priority value of the relevant requirement in the policy;

[0158] m iTo what extent resources meet the corresponding needs, 0 ≤ m i ≤1, its value is given by the label matching rules;

[0159] RD i The function weight for resource redundancy is used to measure the importance of security functions beyond the security requirements covered by the policy. It is assigned to each resource instance by the operations and maintenance personnel and the default value is 0.

[0160] w is a weight parameter used to adjust the degree of influence of redundant functions on the overall security coverage score of candidate service chain combination, 0≤w<1;

[0161] n is the number of resource instances in the candidate service chain combination.

[0162] Then, calculate the load balancing degree B of each resource in each service chain:

[0163]

[0164] in:

[0165] i is the resource number;

[0166] CL i EL represents the current utilization rate of resources. i For the expected resource utilization rate based on demand, 0 ≤ (CL) i +EL i )≤1;

[0167] n is the number of resource instances in the candidate service chain combination.

[0168] Finally, a multi-objective scoring model is constructed, and a comprehensive safety benefit scoring function is defined:

[0169]

[0170] in:

[0171] i is the resource number;

[0172] L is the sum of the expected end-to-end latency of each resource's link, which is measured by the adapter agent;

[0173] C represents the sum of the cost indices of the selected resources. The cost index of each resource is assessed and given by the operations and maintenance personnel. Factors considered typically include licensing or usage fees, network transmission costs, or compliance hardening costs.

[0174] w1…w4 are weights that can be pre-configured by the operation and maintenance strategy or dynamically adjusted by the online learning component;

[0175] a and b are adjustment parameters, where a>0 and 0.5≤b<1;

[0176] n is the number of resource instances in the candidate service chain combination.

[0177] 5) Arrangement scheme generation and verification

[0178] Select the best solution from the optimization results and generate a security service chain topology graph data structure:

[0179]

[0180] Local simulation and feasibility verification: The generated link is subjected to latency simulation and throughput testing in a sandbox environment or lightweight simulation model to ensure that performance constraints are met; if the simulation fails, an automatic alternative solution is triggered to downgrade or re-search until the verification is passed.

[0181] 6) Solution Output and Persistence

[0182] The final orchestration scheme is serialized into an "execution task list" and pushed to the scheduling task queue of the scheduling and distribution module:

[0183]

[0184] 5. Serialization of the orchestration scheme

[0185] In this step, the scheduling and distribution module serializes the security orchestration scheme from the orchestration decision module into a standardized "execution task list" and pushes the configuration information to each adapter agent. Through the entire process of "task splitting → standardized serialization → concurrent push → confirmation and retry → progress monitoring and status summary", the reliable, efficient and secure delivery of the security orchestration scheme to each distributed adapter agent is realized, laying a solid foundation for subsequent execution and verification.

[0186] Detailed explanation is as follows:

[0187] 1) Orchestration scheme reception and task breakdown

[0188] The scheduling and distribution module receives the scheme object output by the orchestration decision module from a message queue (such as Kafka Topic plans-ready) or a REST interface. This object includes the task_id, chain_topology, and configuration templates for each node. Based on the resource_id and corresponding capability of each step in the chain topology, the entire security service chain is divided into several subtasks. Each subtask corresponds to a single configuration for a specific adapter proxy.

[0189]

[0190]

[0191] Assign a unique subtask_id to each sub-scheduled task and record the expected execution order (if there are dependencies, set a dependency chain) and persist it to the local "scheduled task table".

[0192] 2) Standardization and serialization of the execution task list

[0193] Define a unified task message format, including fields:

[0194]

[0195] After sorting all scheduled subtasks according to their dependency topology and priority, package them into a list of execution tasks:

[0196]

[0197]

[0198] The task list is digitally signed, along with the algorithm version and scheduling module instance ID, to ensure that downstream execution is trustworthy and traceable.

[0199] 3) Concurrent push and channel management

[0200] For each subtask, the target adaptation proxy address is determined based on its node_id (which can be queried from the resource registration and discovery module), supporting three delivery channels: HTTP / HTTPS, gRPC, and message queue. Then, requests are delivered concurrently in batches to each node, merging all subtasks on the same node into a single batch request to reduce handshake attempts. Parallel execution across different nodes improves scheduling efficiency. An example of a delivery request is shown below:

[0201]

[0202]

[0203] 4) Confirmation and Retry Mechanism

[0204] Upon receiving the data, the adapter should immediately return an ACK, including the subtask_id and status:RECEIVED. The scheduling module will update the "Scheduling Task Table" with this result. If no ACK is received or a status:ERROR is returned, the scheduling module will retry according to the exponential backoff strategy. The number of retries and the interval are configurable (e.g., up to 3 times, with intervals of 5s, 10s, and 20s). For subtasks that fail for an extended period (>3 times), the scheduling module will immediately alert the operations and maintenance personnel, mark the subtask as FAILED in the scheduling table, record the reason for the error, and then decide whether to automatically degrade the subtask or trigger re-orchestration based on the strategy.

[0205] 5) Execution progress monitoring and status summary

[0206] The scheduling module periodically (e.g., every 2 seconds) polls each adaptor for execution progress.

[0207]

[0208] The adapter returns the execution status:

[0209]

[0210] 6. Task Execution and Feedback

[0211] In this step, after receiving the subtask, the adapting agent calls the corresponding vendor's CLI or API to execute it based on the local resource type. It then verifies the policy's effectiveness locally and reports the status back to the scheduling and distribution module. This step, through the entire process of "task parsing → environment preparation → API call → local verification → result feedback → fault retry," enables the adapting agent to accurately execute and provide real-time feedback on various security resources, ensuring that security policies are reliably and controllably effective in a distributed environment.

[0212] Detailed explanation is as follows:

[0213] 1) Task Reception and Parsing

[0214] The adapter listens to the local execution entry point (HTTP / gRPC or message queue), receives executeSubtasks requests from the scheduling and distribution module, performs digital signature verification and authorization verification on the request body to ensure the source is trustworthy, then parses the subtasks list in JSON, and constructs a dependency execution graph according to the dependencies field to prepare for subsequent serial / parallel execution.

[0215] 2) Local execution environment preparation

[0216] Based on the resource_id, the local resource descriptor is located to obtain the corresponding execution metadata such as type, api_endpoint, cli_path, and auth_credentials. The corresponding execution adapter module is then dynamically loaded for each resource type, such as:

[0217]

[0218] It also supports flexible access to new vendor resources through a plug-in architecture.

[0219] 3) Call the vendor's CLI or API to perform configuration.

[0220] ① For REST / gRPC interface resources: Construct standardized API requests (GET / POST / PUT), populate policy parameters, and use batch or phased submission methods to reduce the number of interface calls. Taking Web Application Firewall policy distribution as an example:

[0221]

[0222] ② For CLI / Shell script resources: Execute the script via SSH or local command line and capture standard output / errors. Take firewall rule distribution as an example:

[0223]

[0224] ③ For SDK / library call resources: The interface is called directly within the proxy process via the language SDK. Taking the Python-based IDSSDK as an example:

[0225]

[0226] 4) Verification of local policy effectiveness

[0227] ●Status query: After execution, call the resource query interface to confirm whether the policy has been loaded and compare the version number or policy ID;

[0228] ●Functional testing: Perform single-step functional testing on the resource, such as initiating test traffic or triggering predefined test cases, to verify the interception / alarm behavior;

[0229] ●Performance baseline comparison: Collect local short-term latency and throughput indicators and compare them with the baseline values ​​before distribution to ensure that resources are healthy and there is no abnormal jitter.

[0230] Example of a verification script:

[0231]

[0232] 5) Summary and feedback of execution results

[0233] Based on the verification results, an execution report is generated for each subtask:

[0234]

[0235] Reports are pushed to the scheduling module via a dedicated feedback channel (HTTP Callback or message queue):

[0236]

[0237] If a status: FAILED is displayed, along with the error code and log file index, it will facilitate diagnosis by the scheduling module or maintenance personnel.

[0238] 6) Retry and Fault Handling

[0239] For subtasks that fail to call the vendor's interface or fail verification, the agent automatically retryes locally according to the configured policy (default 3 times, with a backoff policy). If the retry still fails, the agent marks the subtask as ERROR and triggers a local alarm (such as writing to the local log or reporting the abnormal event through the monitoring module).

[0240] Supports local degradation: If critical policies cannot be deployed, business continuity can be ensured by using a predefined degradation scheme (e.g., only enabling alarm mode and not blocking).

Claims

1. A method for intelligent orchestration and adaptation of distributed security resources, characterized in that, Includes the following modules and steps: Step S1: Security resource exploration and capability labeling; Deploy an adaptation agent on a cloud platform or edge node with secure resources to obtain local security resource information and cache it. Report heartbeat information and resource list metadata to the resource registration and discovery module and ensure the confidentiality and integrity of the information. Step S2: Upload local information; The adapter reports the security resource information it collects to the resource registration and discovery module for unified management and maintenance, and regularly reports the local security resource operation indicators, security event logs and network link indicators to the monitoring module. Step S3: Strategy Input and Analysis; The policy management module receives new security policies entered by users and performs verification, standardizing the policy parsing, conflict checking, and high-reliability management. Step S4: Generate orchestration scheme; The orchestration decision module receives security requirements from the policy management module. Based on the list of available resources obtained from the resource registration and discovery module and the real-time resource status and link performance data obtained from the monitoring module, it outputs a security orchestration scheme, namely the security service chain topology and corresponding resource instances and configurations. Step S5: Serialize the orchestration scheme; The scheduling and distribution module serializes the security orchestration scheme from the orchestration decision module into a standardized "execution task list" and pushes the configuration information to each adapting agent; Step S6: Task execution and feedback; After receiving the task, the adapter calls the corresponding vendor's command-line interface or application programming interface to execute the task based on the local resource type, verifies the effectiveness of the policy locally, and feeds back the status to the scheduling and distribution module.

2. The method for intelligent orchestration and adaptation of distributed security resources according to claim 1, characterized in that, The specific implementation process of step S1 is as follows: Step S1.1: Run the adaptation agent on the node; Step S1.2: Scanning and identifying local security resources; Step S1.3: Local caching of resource metadata; Step S1.4: Heartbeat and metadata reporting; Step S1.5: Safety and Reliability Assurance.

3. The method for intelligent orchestration and adaptation of distributed security resources according to claim 2, characterized in that, Step S1 decomposes the functions of heterogeneous security resources from multiple vendors and of multiple types into standardized capability tags, thereby achieving a unified description and dynamic perception of heterogeneous security resources without the need for deep adaptation of the interface characteristics of each resource, thus improving the flexibility and scalability of security resources.

4. The method for intelligent orchestration and adaptation of distributed security resources according to claim 1, characterized in that, The specific implementation process of step S2 is as follows: Step S2.1: Report the resource information to the registration module; Step S2.2: Report operational metrics and security events to the monitoring module; Step S2.3: Unified management and maintenance of resource information.

5. The method for intelligent orchestration and adaptation of distributed security resources according to claim 1, characterized in that, The specific implementation process of step S3 is as follows: Step S3.1: Strategy entry and verification triggering; Step S3.2: Strategy format and syntax verification; Step S3.3: Strategy conflict and dependency check; Step S3.4: Strategy Analysis and Functional Requirements Decomposition; Step S3.5: Metadata generation and version management; Step S3.6: Preparation for strategy distribution; Step S3.7: Security and Audit Assurance.

6. The method for intelligent orchestration and adaptation of distributed security resources according to claim 1, characterized in that, The specific implementation process of step S4 is as follows: Step S4.1: Input reception and preprocessing; Step S4.2: Query the list of available resources; Step S4.3: Real-time performance and status acquisition; Step S4.4: Organize the execution of the decision-making algorithm; Step S4.5: Orchestration scheme generation and verification; Step S4.6: Solution output and persistence.

7. The method for intelligent orchestration and adaptation of distributed security resources according to claim 6, characterized in that, Step S4 generates multiple service chain combinations based on the demand sequence and the candidate set corresponding to each demand, calculates the security coverage, total latency, total cost index and resource load balancing of each combination, and then calculates a comprehensive score and selects the best one to achieve multi-objective optimization of security, cost, latency and load availability.

8. The method for intelligent orchestration and adaptation of distributed security resources according to claim 1, characterized in that, The specific implementation process of step S5 is as follows: Step S5.1: Orchestration scheme reception and task splitting; Step S5.2: Perform task list standardization and serialization; Step S5.3: Concurrent Push and Channel Management; Step S5.4: Issue confirmation and retry mechanism; Step S5.5: Execution progress monitoring and status summary.

9. The method for intelligent orchestration and adaptation of distributed security resources according to claim 1, characterized in that, The specific implementation process of step S6 is as follows: Step S6.1: Task reception and parsing; Step S6.2: Prepare the local execution environment; Step S6.3: Call the vendor interface to perform configuration; Step S6.4: Verify the effectiveness of local policies; Step S6.5: Summarize and provide feedback on execution results; Step S6.6: Retry and troubleshooting.

10. The method for intelligent orchestration and adaptation of distributed security resources according to claim 1, characterized in that, Through steps S3, S4, S5, and S6, end-to-end automation from policy to execution is achieved. Starting from the user entering a new policy, the entire process, including policy conflict verification, intelligent orchestration, scheme serialization, distributed distribution, local execution verification, and status feedback, requires no manual intervention. This greatly reduces the time required for policies to take effect and effectively improves the overall efficiency of security resource orchestration.

Images