LLM-based firewall policy automatic generation method

Abstract

The invention relates to the technical field of network security and artificial intelligence, in particular to an LLM-based firewall policy automatic generation method. The method comprises the following steps: firstly, preprocessing acquired multi-source data related to a firewall policy, constructing a vector database, and finely adjusting an LLM (Logistics Language Model) generation model; secondly, verifying a firewall intention of an input natural language, and converting the firewall intention into a structured and executable subtask sequence; then converting the subtask sequence into a firewall equipment API calling code, standardizing and preliminarily verifying; performing simulation execution in a digital twin environment, and pre-verifying a firewall code; and finally deploying to firewall equipment in a production network. Through a multi-stage processing flow, an end-to-end automation scheme from a strategy intention of a natural language to an executable API calling code is realized, and meanwhile, through pre-verification of a firewall strategy code of digital twinning, the accuracy and the safety of a guarantee strategy are ensured, the firewall strategy generation efficiency is improved, the labor cost is reduced, and configuration errors are reduced.

Description

Technical Field

[0001] This invention relates to the fields of network security and artificial intelligence technology, and more specifically, to an automatic generation method for firewall policies based on LLM. Background Technology

[0002] In modern digital infrastructure, firewalls, as core network security devices, are a critical line of defense against unauthorized access and malicious network traffic. Firewall policies (rule sets that define what traffic is allowed or denied through the firewall) are the cornerstone of maintaining an organization's network security posture. However, with the increasing complexity, distribution, and dynamism of network environments, and the continuous evolution of network threats, traditional firewall policy management methods and existing related technologies face many key challenges: (a) Deficiencies of manual management of traditional firewall policies Traditional firewall policy generation relies on security experts manually interpreting business needs and security compliance requirements, and then writing rules based on command-line interface (CLI) or graphical interface (GUI), which has significant shortcomings: 1. High reliance on human intervention and prone to errors: Firewall policies need to cover multiple parameters such as source / destination IP, port, protocol, and action (allow / deny). Manual configuration is prone to errors such as missing parameters or incorrect formatting, which can lead to policy failure or even introduce new security vulnerabilities. According to industry statistics, approximately 40% of network security incidents are directly related to firewall policy configuration errors. Differences in human interpretation of policy intent and mistakes in complex syntax can trigger serious security vulnerabilities or critical business interruptions.

[0003] 2. Low response efficiency and inability to cope with dynamic threats: When faced with real-time threats such as DDoS attacks and malicious IP intrusions, the traditional manual configuration process takes several hours to several days to complete the firewall policy update, which cannot meet the threat response requirements at the minute level, resulting in the network being exposed to risks for a long time.

[0004] 3. Significant semantic gap: Business personnel describe firewall protection needs in natural language (e.g., "Block IP 192.168.1.0 / 24 from accessing internal database port 3306 through the firewall"), and security experts need to manually convert them into rules that the firewall can recognize. This process relies on professional knowledge and is prone to misinterpretation, leading to policies that do not match the intent.

[0005] 4. Difficulty in policy verification: Directly deploying new firewall policies to the production environment may cause service interruptions due to rule conflicts (such as contradictions between "allow" and "deny"); traditional sandbox environments cannot simulate the complex topology and traffic characteristics of production networks, thus limiting the effectiveness of firewall policy verification.

[0006] (ii) Limitations of existing firewall policy automation technologies 1. Shortcomings of first-generation automation tools: Firewall policy solutions based on scripts or configuration management platforms can only automate the execution of "how to do it". Human experts are still required to define each specific operation. They cannot understand abstract natural language intent and have failed to solve the core translation problem from "what to do" to "how to do it".

[0007] 2. Limitations of AI applications in the firewall field: Existing AI / ML technologies mostly focus on firewall-related threat detection (such as intrusion detection and malicious traffic identification based on firewall logs), which are analytical applications that only handle events that have occurred or are occurring. They cannot proactively generate and configure firewall policies to prevent future threats. In the field of firewall policy generation, there is no effective mechanism to transform abstract goals into specific configurations.

[0008] In summary, there is an urgent need for an end-to-end solution that can automatically translate natural language-described policy intentions into API call code that firewalls can execute, filling the gap in existing technology. Summary of the Invention

[0009] This invention addresses the shortcomings of existing firewall policy generation technologies, which rely on manual operation, are slow to respond, prone to errors, and difficult to verify. It proposes an automatic firewall policy generation method based on LLM. Through a multi-stage processing flow, it achieves an end-to-end automated solution from natural language policy intent to executable API call code. At the same time, it ensures the accuracy and security of policies through digital twin firewall policy code pre-verification, thereby improving the efficiency of firewall policy generation, reducing labor costs, and reducing configuration errors.

[0010] The specific implementation details of this invention are as follows: An automatic firewall policy generation method based on LLM includes the following steps: Step S1: Preprocess the acquired multi-source firewall policy-related special data and build a vector database; Step S2: Fine-tune the LLM generation model according to the set fine-tuning target and the set training parameters; Step S3: Based on the obtained abstract firewall protection requirements and the set error checking mechanism, verify the firewall intent of the input natural language; Step S4: Invoke prompt word engineering techniques to transform firewall intents into a structured, executable sequence of subtasks; Step S5: Convert the subtask sequence into firewall device API call code, standardize the firewall device API call code according to the LLM generation model, and perform preliminary verification; Step S6: Simulate the execution of the firewall device API call code in a digital twin environment to pre-verify the firewall code; Step S7: Deploy the pre-verified firewall code to firewall devices in the production network.

[0011] To better realize the present invention, step S1 further includes the following steps: Step S11: Collect multi-source data related to firewall policies; the multi-source firewall policy related data includes firewall threat intelligence, API documentation of mainstream firewall devices, firewall security research documents, historical firewall policy data, natural language intent, firewall vulnerability and attack response data, firewall security protection data, and firewall configuration data; Step S12: Preprocess the collected multi-source data related to firewall policies, and call the text segmentation tool to segment the text data into semantically coherent text blocks that meet the input constraints of the embedding model; Step S13: Call the pre-trained sentence conversion model to convert text blocks into high-dimensional numerical embedding vectors and build a vector database.

[0012] To better realize the present invention, step S2 further includes the following steps: Step S21: Use an open-source LLM model that supports long context windows as the base model; Step S22: Construct training samples based on the acquired natural language intent and contextual information; Step S23: Set the training parameters based on the constructed training samples; Step S24: Fine-tune the LLM model based on the training parameters.

[0013] To better realize the present invention, step S3 further includes the following steps: Step S31: Construct the firewall policy intent input interface based on the Chatbot class interaction interface; Step S32: Verify the natural language firewall intent obtained from the firewall policy intent input interface; the verification includes format error verification and logical rationality verification.

[0014] To better realize the present invention, step S4 further includes the following steps: Step S41: Construct a prompt word template to guide the fine-tuned LLM model to complete the firewall task decomposition according to the set logic; Step S42: Construct a firewall policy classification system based on the firewall protection scenario; Step S43: Based on the prompt word template and the constructed firewall policy classification system, decompose the natural language intent into a sequence of sub-tasks; Step S44: Verify the subtask sequence according to the set constraints.

[0015] To better realize the present invention, step S5 further includes the following steps: Step S51: Vectorize the verified subtask sequence, generate subtask vectors, and retrieve the Top-K records with the highest semantic similarity to the subtask vectors from the vector database; Step S52: Obtain a context learning example consistent with the current firewall subtask type, and concatenate it with system instructions, retrieved context information, and firewall subtask description to obtain the enhanced prompt words; Step S53: Input the enhanced prompt words into the LLM generation model to obtain the firewall API call code that meets the requirements; Step S54: Convert the generated firewall API call code into JSON format and perform preliminary verification.

[0016] To better realize the present invention, step S6 further includes the following steps: Step S61: Construct a digital twin model of the firewall; Step S62: Simulate the execution of the preliminarily verified firewall API call code in the digital twin environment, and perform conflict detection based on the firewall policy generated by the code; Step S63: Verify whether the policy corresponding to the firewall policy code is consistent with the intent and has no side effects through traffic simulation and compliance checks; Step S64: If the verification passes, mark the firewall API call code as "deployable" and proceed to step S7; if the verification fails, report the reason for the failure to the LLM generation model, and the model will combine the failure information to correct the firewall API call parameters or code logic, and re-execute steps S5-S6 until the verification passes; if the verification still fails after multiple corrections, trigger the manual review process.

[0017] To better implement the present invention, step S61 further includes the following steps: Step S611: Construct a firewall network topology model based on the target firewall device's hardware parameters, software version, and existing policy configuration; Step S612: Construct a firewall network environment, simulate the network topology related to the firewall in the production network, and generate virtual traffic consistent with the real environment; Step S613: Synchronize existing policy configurations, traffic logs, device status data, and vulnerability protection configurations from the physical firewall device via a timed interface, and update the firewall digital twin model.

[0018] To better realize the present invention, step S7 further includes the following steps: Step S71: Based on the verified firewall API call code, construct the firewall API execution environment; Step S72: Execute the API call code in sequence according to the firewall subtask dependencies.

[0019] To better implement the present invention, step S7 further includes: Step S73: During execution, monitor the status, execution time, return results, and device status of firewall API calls in real time through the log library; Step S74: If all firewall API calls are executed successfully, generate a firewall policy deployment report, notify the user via email, SOC platform or API interface, and provide a way to query firewall policies. Step S75: After execution, check whether the policy has been successfully deployed by calling the query API of the firewall device, and compare whether the actual deployed parameters are consistent with the original intent. If they are inconsistent, trigger the secondary correction process. Step S76: During the monitoring period after the transaction is committed, the key indicators of the affected network segment are continuously tracked through the monitoring script. If the indicator deviates from the preset baseline, it is determined to be a configuration anomaly, and the rollback mechanism is automatically triggered. The rollback mechanism includes calling the firewall recovery configuration API to restore the firewall device to the backup configuration before deployment; recording the rollback log and analyzing the cause of the anomaly. The anomaly information is fed back to the LLM, and after the model is corrected, steps S5-S7 are re-executed; after the rollback is completed, the user is notified and an anomaly analysis report and correction suggestions are provided.

[0020] The present invention has the following beneficial effects: (1) This invention realizes end-to-end automation from firewall policy intent described in natural language to API call code execution, without the need for manual writing of policy rules and API code, reducing the firewall policy generation and deployment time from the traditional hours to days to minutes, improving efficiency by ≥90%; it supports multi-turn dialogue and batch firewall intent processing, further reducing operation and maintenance costs.

[0021] (2) This invention is a professional fine-tuning of LLM in the field of firewalls. Combined with the extended firewall-specific training dataset, it improves the accuracy of policy intent understanding and firewall API generation. The accuracy of intent understanding in the test set is ≥90% and the accuracy of API generation is ≥85%. Error checking in the firewall intent input stage avoids policy deviation caused by incorrect input information from the source. The invention calls RAG technology (in combination with firewall-specific knowledge base) to ensure that API calls match the firewall device interface and avoids the generation of "illusion" error parameters. Based on digital twin firewall policy code pre-verification, it detects policy conflicts, validity and performance issues, reduces the firewall configuration error rate in the production environment by ≥80%, and avoids business interruption and security vulnerabilities.

[0022] (3) This invention directly transforms the abstract natural language firewall policy generation intent into machine-executable API call code through a collaborative process of natural language understanding, firewall task decomposition guided by prompt word engineering, and RAG and context learning to enhance translation. No manual intervention is required in the translation process, eliminating the misunderstanding of "business requirements → firewall policy → machine configuration" and ensuring a high degree of consistency between firewall policy and intent. Attached Figure Description

[0023] Figure 1 The flowchart of the LLM-based automatic firewall policy generation method provided by the present invention is shown in the figure. Detailed Implementation

[0024] To more clearly illustrate the technical solutions of the embodiments of the present invention, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments, and therefore should not be regarded as a limitation on the scope of protection. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0025] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "set up," "connected," and "linked" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0026] The full English translations of the technical terms and abbreviations used in this embodiment are as follows: LLM, Large Language Model; API, Application Programming Interface; RAG, Retrieval-Augmented Generation; CVE, Common Vulnerabilities and Exposures; CNNVD, China National Vulnerability Database of Information Security. Example 1:

[0027] This embodiment proposes an automatic firewall policy generation method based on LLM, which specifically includes the following steps: Step S1: Preprocess the acquired multi-source firewall policy-related special data and build a vector database; Step S1 specifically includes the following steps: Step S11: Collect multi-source data related to firewall policies; the multi-source firewall policy related data includes firewall threat intelligence, API documentation of mainstream firewall devices, firewall security research documents, historical firewall policy data, natural language intent, firewall vulnerability and attack response data, firewall security protection data, and firewall configuration data; Step S12: Preprocess the collected multi-source data related to firewall policies, and call the text segmentation tool to segment the text data into semantically coherent text blocks that meet the input constraints of the embedding model; Step S13: Call the pre-trained sentence conversion model to convert text blocks into high-dimensional numerical embedding vectors and build a vector database.

[0028] Step S2: Fine-tune the LLM generation model according to the set fine-tuning target and the set training parameters; Step S2 specifically includes the following steps: Step S21: Use an open-source LLM model that supports long context windows as the base model; Step S22: Construct training samples based on the acquired natural language intent and contextual information; Step S23: Set the training parameters based on the constructed training samples; Step S24: Fine-tune the LLM model based on the training parameters.

[0029] Step S3: Based on the obtained abstract firewall protection requirements and the set error checking mechanism, verify the firewall intent of the input natural language; Step S3 specifically includes the following steps: Step S31: Construct the firewall policy intent input interface based on the Chatbot class interaction interface; Step S32: Verify the natural language firewall intent obtained from the firewall policy intent input interface; the verification includes format error verification and logical rationality verification.

[0030] Step S4: Invoke prompt word engineering techniques to transform firewall intents into a structured, executable sequence of subtasks; Step S4 specifically includes the following steps: Step S41: Construct a prompt word template to guide the fine-tuned LLM model to complete the firewall task decomposition according to the set logic; Step S42: Construct a firewall policy classification system based on the firewall protection scenario; Step S43: Based on the prompt word template and the constructed firewall policy classification system, decompose the natural language intent into a sequence of sub-tasks; Step S44: Verify the subtask sequence according to the set constraints.

[0031] Step S5: Convert the subtask sequence into firewall device API call code, standardize the firewall device API call code according to the LLM generation model, and perform preliminary verification; Step S5 specifically includes the following steps: Step S51: Vectorize the verified subtask sequence, generate subtask vectors, and retrieve the Top-K records with the highest semantic similarity to the subtask vectors from the vector database; Step S52: Obtain a context learning example consistent with the current firewall subtask type, and concatenate it with system instructions, retrieved context information, and firewall subtask description to obtain the enhanced prompt words; Step S53: Input the enhanced prompt words into the LLM generation model to obtain the firewall API call code that meets the requirements; Step S54: Convert the generated firewall API call code into JSON format and perform preliminary verification.

[0032] Step S6: Simulate the execution of the firewall device API call code in a digital twin environment to pre-verify the firewall code; Step S6 specifically includes the following steps: Step S61: Construct a digital twin model of the firewall; Step S61 specifically includes the following steps: Step S611: Construct a firewall network topology model based on the target firewall device's hardware parameters, software version, and existing policy configuration; Step S612: Construct a firewall network environment, simulate the network topology related to the firewall in the production network, and generate virtual traffic consistent with the real environment; Step S613: Synchronize existing policy configurations, traffic logs, device status data, and vulnerability protection configurations from the physical firewall device via a timed interface, and update the firewall digital twin model.

[0033] Step S62: Simulate the execution of the preliminarily verified firewall API call code in the digital twin environment, and perform conflict detection based on the firewall policy generated by the code; Step S63: Verify whether the policy corresponding to the firewall policy code is consistent with the intent and has no side effects through traffic simulation and compliance checks; Step S64: If the verification passes, mark the firewall API call code as "deployable" and proceed to step S7; if the verification fails, report the reason for the failure to the LLM generation model, and the model will combine the failure information to correct the firewall API call parameters or code logic, and re-execute steps S5-S6 until the verification passes; if the verification still fails after multiple corrections, trigger the manual review process.

[0034] Step S7: Deploy the pre-verified firewall code to firewall devices in the production network.

[0035] Step S7 specifically includes the following steps: Step S71: Based on the verified firewall API call code, construct the firewall API execution environment; Step S72: Execute the API call code in sequence according to the firewall subtask dependencies.

[0036] To better implement the present invention, step S7 further includes: Step S73: During execution, monitor the status, execution time, return results, and device status of firewall API calls in real time through the log library; Step S74: If all firewall API calls are executed successfully, generate a firewall policy deployment report, notify the user via email, SOC platform or API interface, and provide a way to query firewall policies. Step S75: After execution, check whether the policy has been successfully deployed by calling the query API of the firewall device, and compare whether the actual deployed parameters are consistent with the original intent. If they are inconsistent, trigger the secondary correction process. Step S76: During the monitoring period after the transaction is committed, the key indicators of the affected network segment are continuously tracked through the monitoring script. If the indicator deviates from the preset baseline, it is determined to be a configuration anomaly, and the rollback mechanism is automatically triggered. The rollback mechanism includes calling the firewall recovery configuration API to restore the firewall device to the backup configuration before deployment; recording the rollback log and analyzing the cause of the anomaly. The anomaly information is fed back to the LLM, and after the model is corrected, steps S5-S7 are re-executed; after the rollback is completed, the user is notified and an anomaly analysis report and correction suggestions are provided.

[0037] Working principle: This embodiment achieves an end-to-end automated solution from natural language policy intent to executable API call code through a multi-stage processing flow. At the same time, it ensures the accuracy and security of the policy through digital twin firewall policy code pre-verification, thereby improving the efficiency of firewall policy generation, reducing labor costs, and reducing configuration errors. Example 2:

[0038] This embodiment is based on the above embodiment 1, such as... Figure 1 As shown, it includes seven core steps, which work together to form a complete closed loop for the automatic generation and deployment of firewall policies.

[0039] Step S1: Collection and preprocessing of firewall-specific training data; This step builds a comprehensive and firewall-specific knowledge base, supplementing it with data on firewall vulnerabilities and attack responses, firewall security protection, and configurations of different firewall brands. This provides foundational data support for subsequent LLM fine-tuning, specifically including: Step S11: Multi-source data acquisition; We aggregate dedicated data related to firewall policies through authoritative channels, covering firewall threat intelligence, firewall device API documentation, historical firewall policies, labeled samples, newly added firewall vulnerabilities and attack responses, firewall security protection, and configuration data for firewalls of different brands. Firewall Threat Intelligence: Obtain firewall-related threat intelligence from public repositories, including real-world attack patterns against firewalls, attackers' exploitation of firewall vulnerabilities, and mitigation measures (such as the "block DDoS attack IP ranges through firewalls" strategy), providing the model with the ability to understand firewall policies related to threats.

[0040] API documentation for mainstream firewall devices: Through automated web scraping or direct file download, we collect official API documentation from mainstream firewall vendors such as Palo Alto, Fortinet, Cisco, Huawei, and Anheng. This includes function signatures, parameter descriptions, return values, constraints, and usage examples, ensuring that LLM generates correctly syntactically correct firewall API calls.

[0041] Firewall Security Research and Best Practices: This section collects arXiv academic papers, industry security conference papers, firewall security research papers published by standards organizations, best practice guidelines, and technical tutorials to enrich the model's understanding of advanced firewall security concepts, emerging threats, and defense strategies.

[0042] Historical firewall policy data: Collect enterprise historical firewall policy configuration logs (de-sensitized, sensitive IPs / ports replaced with placeholders such as [INTERNAL_IP], [DB_PORT], etc.), including policy creation / update time, rule content, and associated security event types, to provide the model with a reference for real firewall scenarios.

[0043] Natural Language Intent - Firewall Policy Mapping Samples: 100+ manually annotated pairs of "Natural Language Intent - Firewall Policy Rules" (e.g., the rule corresponding to the intent "deny external IP from accessing the internal web port through the firewall" is src_ip=0.0.0.0 / 0, dst_ip=10.0.0.5 / 32, port=80, protocol=TCP, action=deny), used for LLM fine-tuning.

[0044] Firewall vulnerability and attack response data: Firewall vulnerability information (such as vulnerability number, scope of impact, and exploitation method) is collected from channels such as the National Information Security Vulnerability Database (CNNVD), Common Vulnerability Disclosure (CVE), and Common Vulnerability Scoring System (CVSS). For firewall attack cases (such as attack path, tools used, and consequences) and corresponding firewall defense strategies, the model's ability to generate strategies for firewall vulnerability protection and attack response scenarios is enhanced.

[0045] Firewall security protection data: Collect configuration specifications, best practice cases, and corresponding firewall policy templates for security protection technologies such as firewall-based identity authentication integration, data encryption transmission adaptation, access control refinement, and endpoint protection linkage, to ensure that the policies generated by the model cover multi-dimensional firewall security protection needs.

[0046] Firewall configuration data from different brands: Collect configuration manuals, policy management processes, and policy examples for common scenarios (such as perimeter protection and internal network segmentation) of mainstream firewall devices such as Palo Alto, Fortinet, Cisco, Huawei, and Anheng, so that the model can become familiar with the characteristics and policy configuration requirements of firewall devices from different brands.

[0047] Step S12: Data preprocessing; Text cleaning: Remove redundant content from documents, standardize encoding formats, correct spelling errors, and ensure text quality.

[0048] Structured processing: Convert unstructured documents into structured data in JSON format, with fields including data_type (such as "Firewall API Documentation", "Firewall Vulnerability Data", "Palo Alto Firewall Configuration Case"), content (text content), and metadata (source, publication time, associated firewall model) to facilitate subsequent processing.

[0049] Data anonymization: Sensitive information (real internal network IP, business ports, user information, and core firewall systems affected by vulnerabilities) in firewall historical policy data and firewall vulnerability data is replaced or masked to prevent data leakage and comply with privacy protection requirements.

[0050] Text chunking: Using a text segmentation tool, all text data is divided into semantically coherent text chunks that conform to the input constraints of the embedding model, ensuring that each chunk contains complete context.

[0051] Data partitioning: The preprocessed data is divided into training set, validation set and test set in a 7:2:1 ratio, which are used for LLM fine-tuning, performance evaluation and result verification, respectively.

[0052] Step S13: Data vectorization and vector database construction; Embedding generation: Using a pre-trained sentence converter model, each text block is converted into a high-dimensional numerical embedding vector, capturing the semantic meaning of the text in the vector space, making semantically similar texts closer together.

[0053] Vector storage: The embedded vectors and their corresponding original text blocks, especially information related to firewall API calls, are stored in a dedicated vector database and indexed to support efficient large-scale similarity searches, providing core data support for the RAG mechanism in the subsequent LLM fine-tuning and firewall intent translation stages.

[0054] Step S2: Fine-tuning the large language model; Through fine-tuning, the LLM is adapted to the needs of the firewall domain, enabling it to understand firewall intent, decompose tasks, and generate firewall API call code. The specific implementation process is as follows: Step S21: Basic model selection; We selected an open-source LLM that supports long context windows (≥4096 tokens) to balance model performance and computational cost.

[0055] Step S22: Fine-tune the target; The model has three core capabilities: (1) understanding the firewall policy generation intent described in natural language; (2) breaking down the intent into sub-tasks that conform to the firewall policy classification criteria; and (3) generating call code that matches the API of the target firewall device.

[0056] Step S23: Construction of training samples; Extract "input-output" paired samples from the training set. The input is "natural language intent + contextual information" (e.g., "based on a certain firewall, intent: prohibit external IPs from accessing the internal network database port 3306 through this firewall"), and the output is "task breakdown result + firewall API call code".

[0057] Step S24: Training parameter settings; The LoRA (Low-Rank Adaptation) technique is adopted to avoid the high computational cost of full fine-tuning; the batch size is 16, and the rounds are 5; the cross-entropy loss function is used to measure the difference between the prediction and the "standard answer", and the model weights are optimized through backpropagation; the accuracy of firewall policy generation on the validation set (≥85%) is used as the early stopping metric to avoid overfitting.

[0058] Step S25: Model evaluation; The performance of the fine-tuned model was evaluated using a test set. Key metrics included firewall intent understanding accuracy (≥90%), task decomposition accuracy (≥85%), and firewall API call generation accuracy (≥85%). If the metrics were not met, low-accuracy scenario samples were added for further fine-tuning.

[0059] Step S3: Input firewall policy intent based on natural language; This step receives the user's abstract firewall protection requirements, performs error checking, completes the input and preliminary analysis of the intent, and provides a foundation for subsequent intent decomposition: Step S31: Intent input interface; Provides a Chatbot-like interaction interface, allowing users to easily submit firewall policy intents described in natural language. Conversational interaction: A chatbot-like interface supporting multi-turn dialogues; the system maintains a dialogue history and combines new input to generate context-complete firewall policy requirements, avoiding ambiguity of intent. It supports formatted prompts (e.g., "Please enter the firewall protection action, access subject, and access target; example: Deny external IP range 203.0.113.0 / 24 from accessing port 8080 of internal web server 10.0.1.100 through the firewall"). Step S32: Intent error check; The error checking module performs multi-dimensional validation of the user's natural language firewall intent input to ensure the accuracy and completeness of the input information. Format error check: Checks the correctness of the IP address (e.g., whether it conforms to IPv4 / IPv6 format, whether the CIDR mask is valid), port number (e.g., whether it is within the range of 0-65535, whether it conflicts with commonly used service ports), and protocol type (e.g., whether it is a valid protocol such as TCP / UDP / ICMP). If errors are found, the user is prompted to correct them.

[0060] Information integrity check: Determine whether the firewall intent includes core elements such as protection actions (allow / deny / rate limiting, etc.), access subject (source IP / user group, etc.), and access object (destination IP / port / service). If missing, ask the user to supplement through the interactive interface.

[0061] Logical rationality check: Analyze the logical relationships in the firewall intent, such as logic that poses a security risk, like "allowing external IPs to access sensitive internal databases through the firewall without restricting ports", and prompt the user to confirm or adjust the intent.

[0062] Step S4: Firewall intent disassembly; This step, based on prompt word engineering technology, transforms the abstract firewall policy intent into a structured, executable sequence of subtasks, clarifying the execution logic and dependencies. The specific process is as follows: Step S41: Prompt word engineering; Design professional prompt templates to guide the LLM to complete firewall task breakdown according to fixed logic. The prompt content includes: Task Objective Description: Clearly define the intent and core requirements of the natural language firewall policy generation that needs to be broken down, such as "Based on the intent 'To counter DDoS attacks, deny 203.0.113.0 / 24 access to 10.0.1.100:8080 (TCP)', break it down into ordered sub-tasks to ensure coverage of the entire intent process requirements"; Firewall policy classification system guidelines: Embed a predefined firewall policy classification system (such as: access control, traffic management, log auditing, compliance adaptation), requiring LLM to first classify the intent, and then break down the sub-tasks according to the category; Subtask structure specification: Specifies the fields that a subtask must include (task_id: unique identifier, task_type: corresponding category, pre_task_id: preceding task, task_desc: task description), and provides an example of the correct format; Constraints: Subtasks must be clearly defined, with no circular dependencies, no missing critical steps, and clear, unambiguous descriptions.

[0063] Step S42: Constructing a firewall policy classification system; Based on firewall protection scenarios and firewall device functions, a pre-classification system is defined to provide clear direction for task decomposition. The core categories include: Access control: Controlling IP / port access permissions through the firewall, such as "firewall IP blacklist / whitelist configuration", "firewall port allow / block", and "firewall-based access restrictions for specific user groups". Traffic management: Limiting traffic bandwidth or rate through firewalls, such as "firewall DDoS traffic throttling", "controlling video traffic bandwidth through firewalls", and "firewall peak traffic scheduling". Log auditing: Configure log collection rules related to firewall policies, such as "Record firewall access denial logs", "Audit firewall database port access logs", and "Firewall abnormal traffic alarm logs". Compliance-adaptive policies: Firewall policies that meet specific compliance standards, such as "Level 3 Firewall Port Protection of Information Security Protection 2.0", "Firewall-based Data Outbound IP Restriction", and "Firewall Payment Port Protection".

[0064] Step S43: Intent classification and task breakdown; The intent parsing results and the designed prompts are input into the LLM. The model first classifies the policy-generated intents into the above classification system, and then, based on the "step-by-step thinking" logic guided by the prompts, it decomposes the high-level intents into discrete, unambiguous, and ordered sub-task sequences.

[0065] Step S44: Task breakdown and verification; LLM performs self-verification of the disassembly results based on the constraints in the prompts, checking the following: Does the subtask fully cover the firewall policy generation intent requirements, with no key steps omitted? Are the dependencies between subtasks reasonable, and are there no circular dependencies? Does the subtask type match the firewall policy classification system? Are the subtask descriptions clear and unambiguous?

[0066] If the verification fails, the model will automatically correct itself based on the prompt words and output a correction log to ensure that the decomposition results are usable.

[0067] Step S5: Firewall intent translation; This step transforms the decomposed firewall subtasks into specific, executable firewall device API call code. It employs techniques such as LLM generative modeling, RAG, and context learning to ensure the accuracy and effectiveness of the firewall API calls. The specific process is as follows: Step S51: RAG-enhanced contextual retrieval; For each firewall subtask, perform semantic similarity retrieval to obtain description information of relevant API calls: Subtask vectorization: Input the firewall subtask description into the embedding model used in step 1.3 to generate subtask vectors.

[0068] Similarity search: Retrieve the top-K records (K=5) with the highest semantic similarity to the subtask vector in the vector database. The search results include relevant firewall API documentation snippets, call examples, best practices for firewall policy configuration, etc.

[0069] Search result filtering: Remove search records that are irrelevant to or duplicated in the firewall subtask, and ensure the relevance of contextual information.

[0070] Step S52: Context learning example selection and prompt word construction; Example selection: Select 2 to 3 examples from the “Natural Language Intent - Firewall Policy Mapping Samples” in step 1.1 that are consistent with the current firewall subtask type. The examples must include the correspondence between “subtask description - firewall API call code” to help the model understand the task format and output requirements.

[0071] Prompt construction: System commands, context examples, retrieved context information, and firewall subtask descriptions are concatenated in the order of "system command → context example → retrieved context → subtask description" to form information-rich prompts. The length is controlled within the LLM context window limit to ensure the model can process them completely. The system commands explicitly specify the output format requirements (such as firewall API function names, parameter lists, and error handling logic) and security constraints (such as avoiding generating overly lenient firewall policy rules).

[0072] Step S53: Firewall API call code generation; Input the enhanced prompts into the LLM generator to produce a model. The model outputs firewall API call code that meets the requirements, which are: Syntactic correctness: The function name, parameter list, and parameter format conform to the API specifications of the target firewall device; Error handling: Includes logic for handling firewall API call failures, addressing scenarios such as network timeouts and parameter errors; Readability: Includes necessary code comments explaining firewall API functions and the meaning of key parameters; Scenario adaptability: Combining the needs of scenarios such as firewall vulnerability protection and specific brand firewall configuration, ensure that API calls can meet the firewall policy requirements of specific scenarios.

[0073] Step S54: Standardization and verification of firewall API call code; Standardized format: The generated firewall API call code is converted into JSON format, with fields including task_id (associated subtask ID), api_device (firewall device type), api_name (firewall API function name), api_params (parameter key-value pairs), api_code (complete code), and error_handler (error handling description), to facilitate subsequent verification and execution.

[0074] Preliminary code verification: Check the syntax correctness, parameter completeness, parameter format validity, and scenario adaptability of the firewall API call code (e.g., whether the firewall vulnerability protection scenario includes parameter configurations corresponding to the vulnerability's impact scope). If the verification fails, feedback is sent to regenerate the LLM model.

[0075] Step S6: Firewall code pre-verification; This step involves performing risk-free verification of the generated firewall API call code before deployment. By simulating the firewall's operation in a production network using a digital twin environment, conflict detection, effectiveness, and potential side effects verification are performed on the firewall policy code. This is a core step in ensuring firewall security. Step S61: Constructing a digital twin model of the firewall; Build a high-fidelity virtual environment for firewalls in production networks, ensuring that the simulation results are consistent with the real firewall environment, with a focus on supporting the simulation execution and verification of firewall policy generation code: Firewall physical device modeling: Based on the hardware parameters, software version, and existing policy configuration of the target firewall device, a firewall network topology model is constructed. The firewall operating environment is simulated through containers to ensure the consistency of firewall policy matching logic, traffic forwarding rules, and physical firewall device functions. It supports mixed deployment simulation of multiple brands and types of firewall devices to ensure compatibility verification of policy code on different firewall devices.

[0076] Firewall network environment modeling: Simulates the network topology related to the firewall in the production network, generates virtual traffic consistent with the real environment (normal business traffic, simulated malicious traffic, and attack traffic targeting firewall vulnerabilities). Traffic characteristics include TCP / UDP ratio, packet size distribution, access frequency, etc., providing a realistic traffic scenario for validating the effectiveness of firewall policy code.

[0077] Firewall twin data synchronization: Synchronize existing policy configurations, traffic logs, device status data, and vulnerability protection configurations from physical firewall devices via a scheduled interface, update the firewall digital twin model, ensure real-time consistency between the virtual firewall environment and the production environment, and provide the latest benchmark for conflict detection of firewall policy code.

[0078] Step S62: Firewall policy code pre-deployment and conflict detection; The firewall API call code generated in step S5 is simulated and executed in a digital twin environment, and conflict detection is performed on the firewall policy generated by the code. Firewall API call simulation execution: Run firewall API call code in the isolated execution sandbox of the twin environment to simulate the firewall policy deployment process, record deployment logs, and not affect the physical firewall device; focus on detecting syntax errors, parameter mismatches and other issues during code execution to ensure that the code can run normally on the target firewall device.

[0079] Multi-dimensional conflict detection: Built-in conflict detection algorithm comprehensively identifies contradictions between new firewall policy code and existing policies. Rule conflict: For example, the existing firewall policy "Allow 203.0.113.0 / 24 to access 10.0.1.100:8080" contradicts the new policy code's corresponding action of "Deny access to this IP range"; Parameter conflict: For example, the existing firewall policy port range is 8000-8099, while the new policy code port is 8080-8090, resulting in port overlap; Priority conflict: such as conflicting firewall rules with the same priority; Dependency conflicts: For example, the network objects that the new firewall policy code depends on (such as specific firewall vulnerability protection rules) do not exist in the existing configuration; Device compatibility conflict: such as the API called by the policy code not being supported by the target firewall device model.

[0080] Conflict report generation: Outputs a conflict detection report, including the conflict type, the firewall policy code ID involved, the cause of the conflict, and remedial suggestions (such as adjusting parameters or modifying priorities).

[0081] Step S63: Verify the validity and security of the firewall policy code; Through traffic simulation and compliance checks, verify whether the firewall policy code matches the intent and has no side effects: Positive verification: Inject target traffic of the firewall policy (such as simulated DDoS attack traffic or attack traffic targeting firewall vulnerabilities), detect whether the firewall blocks / allows traffic as intended after the new policy code is deployed, record the traffic processing results, and verify the protection effect of the firewall policy on the target scenario.

[0082] Negative validation: Inject critical business traffic and legitimate access traffic to ensure that the new firewall policy code does not accidentally block legitimate traffic and avoid business interruption; verify the availability of commonly used services (including services affected by firewall vulnerabilities) to prevent policy code from affecting basic network functions.

[0083] Performance verification: Simulate high-traffic scenarios (such as large-scale DDoS attacks and peak business traffic) to test the performance metrics (CPU utilization, memory usage, and response time) of the twin firewall device after the new policy code is deployed, ensuring that the policy code does not cause the firewall device to overload.

[0084] Compliance verification: If the intention is to associate with a compliance scenario (such as compliance with Cybersecurity Classified Protection 2.0 or firewall vulnerability protection), the compliance check module is invoked to verify whether the firewall policy corresponding to the new policy code meets the standard requirements, such as whether the firewall vulnerability protection policy covers known high-risk vulnerabilities.

[0085] Step S64: Verification result processing and iteration; Verification passed: If all verification items pass, mark the firewall API call code as "deployable" and proceed to step S7; Verification failure: The reason for failure (such as code execution error, firewall policy conflict, or inadequate protection effect) is fed back to the LLM generation model. The model combines the failure information to correct the firewall API call parameters or code logic, and re-executes steps S5-S6 until the verification passes. If multiple corrections still fail, the manual review process is triggered.

[0086] Step S7: Firewall code execution This step securely deploys the pre-verified firewall API call code to firewall devices in the production network, ensuring the robustness and recoverability of the deployment process through monitoring: Step S71: Perform environment preparation; Build a secure, isolated firewall API execution environment to prevent malicious code and privilege abuse: Access control: Following the principle of least privilege, the execution environment is configured to only be able to call the firewall policy configuration API, and access to sensitive business data is prohibited; Isolation sandbox: Runs a code execution environment in a containerized environment, isolated from the host system and other business systems, to prevent erroneous code during execution from affecting the external environment; limits the use of CPU, memory, and network resources in the sandbox to avoid resource exhaustion.

[0087] Step S72: Secure execution of firewall API call code; Execute API call code in an orderly manner according to firewall subtask dependencies to ensure controllable deployment process: Batch execution and dependency handling: Based on the firewall subtask dependencies in step 4, execute the API call code in sequence, and execute the subsequent tasks only after the previous task is executed successfully; if the preceding task of a certain task fails, pause the execution and trigger a rollback.

[0088] Transactional execution: Bundle all related firewall API calls into a single atomic transaction to ensure consistency of firewall configuration changes. Before the transaction begins, back up the current firewall device configuration as a basis for rollback; If any firewall API call fails during execution, the transaction is immediately aborted, and the firewall recovery configuration API is called through the code to restore the firewall device to the state before the transaction started, thus avoiding network anomalies caused by partial configuration taking effect. After the transaction is executed successfully, submit the firewall configuration changes to ensure that all rules take effect simultaneously.

[0089] Step S73: Perform monitoring, result feedback, and rollback; Real-time monitoring: During execution, the status, execution time, return results, and device status of firewall API calls are monitored in real time through the log library; logs are retained for at least 90 days to meet auditing and tracing requirements.

[0090] Successful feedback: If all firewall API calls are executed successfully, a firewall policy deployment report is generated, including the policy ID, deployment time, execution result, verification report link, and associated natural language intent. Users are notified via email, SOC platform, or API interface, and a method for querying firewall policies is provided.

[0091] Post-deployment verification: After execution, check whether the policy has been successfully deployed by calling the query API of the firewall device, and compare whether the actual deployed parameters are consistent with the original intent. If they are inconsistent, a secondary correction process is triggered.

[0092] Automatic rollback: During the monitoring period after the transaction is committed, key metrics (traffic throughput, service response time, firewall vulnerability protection status) of the affected network segment are continuously tracked through monitoring scripts. If the metrics deviate from the preset baseline, it is determined to be a configuration anomaly, and the rollback mechanism is automatically triggered. Call the firewall restore configuration API to restore the firewall device to the backup configuration before deployment; Record rollback logs and analyze the causes of anomalies; The abnormal information is fed back to the LLM, and after the model is corrected, steps S5-S7 are re-executed. After the rollback is complete, notify the user and provide an anomaly analysis report and correction suggestions.

[0093] Working principle: The other parts of this embodiment are the same as those in Embodiment 1 above, so they will not be described again. Example 3:

[0094] Based on any one of Embodiments 1-2 above, this embodiment takes a certain type of NGFW firewall device as an example to implement the generation of a policy that "uses the firewall to deal with DDoS attacks and vulnerability exploitation, and denies external IP segment 203.0.113.0 / 24 from accessing port 8080 (TCP) of internal web server 10.0.1.100", and provides a detailed description of the implementation process.

[0095] Step S1: Collection and Preprocessing of Security-Related Training Data Step S11. Multi-source data acquisition; Threat intelligence: Collect data matching the NGFW firewall protection scenario from channels such as MITRE ATT&CK and the National Cybersecurity Threat Intelligence Sharing Platform, and focus on screening intelligence related to "DDoS attack IP segment blocking" and "Web vulnerability exploitation traffic interception", including attack mitigation measures against the NGFW firewall (such as "configuring IP blacklist through the NGFW's Access-Control module").

[0096] NGFW Device API Documentation: Obtain the complete API manual for this firewall model through the official NGFW developer platform. Focus on extracting the function signatures, parameter constraints (such as src_ip supporting CIDR format, priority value range 1-20), return value formats, and Python SDK call examples for the core policy configuration interfaces (such as create_access_rule to create access rules, set_rule_priority to configure priority, and get_existing_rules to query existing policies).

[0097] NGFW Security Research and Best Practices: This collection includes NGFW technical white papers, NGFW deployment cases released at industry security conferences (such as "Financial Industry Boundary Protection Configuration" and "Government Intranet Vulnerability Linkage Protection"), and NGFW officially recommended DDoS protection and port hardening strategy templates.

[0098] NGFW Historical Policy Data: Collects historical configuration logs of the enterprise's internal NGFW firewall (anonymized: real internal IP addresses are replaced with [INTERNAL_WEB_IP], and database ports are replaced with [DB_PORT]), including policy creation time, associated security events (such as "2024-XX-XX blocked SQL injection traffic from 198.51.100.0 / 24"), and rule enabled / disabled status.

[0099] Natural Language Intent - NGFW Policy Generation Mapping Samples: 108 manually labeled paired samples adapted to NGFW devices. Example: The intent "Reject external IP access to the internal database port (prevent MySQL vulnerability)" corresponds to the NGFW policy rule src_ip=0.0.0.0 / 0, dst_ip=[INTERNAL_DB_IP], port=3306, protocol=TCP, action=deny, policy_type=vulnerability_defense.

[0100] Vulnerability and attack data, related to NGFW protection scenarios: Obtain "high-risk vulnerabilities that NGFW can defend against" (such as the CNNVD-2024-XXXX Web server vulnerability) from CNNVD, including vulnerability exploitation methods (such as "uploading malicious files through port 8080") and NGFW's officially recommended defense strategy parameters; collect attack cases against this type of firewall from the NGFW threat event database (such as "lateral penetration using firewall configuration vulnerabilities").

[0101] NGFW-specific configuration data: Collects the device initialization configuration, interface binding rules, zone division standards (such as "DMZ zone - intranet zone access control"), log auditing activation process, and NGFW-specific "vulnerability linkage protection" function configuration manual (such as "automatic generation of blocking policies based on associated vulnerability IDs") for this firewall model.

[0102] Step S12: Data preprocessing; Text cleaning and structuring: Remove the hardware installation section from the NGFW API documentation, retaining the content related to the "Policy Configuration Module" and "Vulnerability Protection Module"; convert the unstructured NGFW best practice documentation to JSON format, and add a device_model: "NGFW-XXX" field to identify the device model.

[0103] Desensitization and Blocking: Sensitive information such as NGFW firewall management IP and administrator accounts in historical policy data is masked; the text is divided into blocks according to NGFW API function modules (such as access_control, ddos_defense, vulnerability_link) to ensure that each text block contains complete single-function configuration logic.

[0104] Data partitioning and vectorization: The training set (containing 80% of NGFW-specific samples), validation set, and test set were divided in a 7:2:1 ratio; the text blocks were vectorized using the sentence-transformers / all-MiniLM-L6-v2 model, and the vectors were stored in the Milvus vector database to create an "NGFW tag" index, thereby improving the accuracy of subsequent retrieval.

[0105] Step S2: Fine-tuning the large language model; Step S21: Basic model and training parameters; The Llama 2-13B open-source model, which supports a context window of 4096 tokens, was selected. LoRA low-rank adaptation technology (rank value set to 16) was used to reduce computational cost. Training parameters were set as follows: batch size of 16, training epochs of 5, and cross-entropy loss function was used to optimize model weights.

[0106] Step S22: Construction of training samples; Input example: "Intent: Deny external IP range 203.0.113.0 / 24 from accessing port 8080 (TCP) of internal web server 10.0.1.100 through a certain type of NGFW firewall, in response to DDoS attacks and web vulnerabilities (CNNVD-2024-XXXX)"; Output example: "Task breakdown: 1. Verify IP and port format (adapt to NGFW CIDR rules); 2. Associate vulnerability ID and configure protection type; 3. Generate NGFW create_access_rule API call; 4. Set policy priority to 8 (NGFW value range 1-20); API call: ngfw_api.create_access_rule(src_ip="203.0.113.0 / 24", dst_ip="10.0.1.100", port=8080, protocol="TCP", action="deny", vulnerability_id="CNNVD-2024-XXXX", priority=8)."

[0107] Step S23: Model evaluation; The NGFW policy generation verification set accuracy reached 90%, the intent understanding test set accuracy reached 93% (focusing on NGFW-specific scenarios such as "vulnerability linkage protection" and "DDoS rate limiting"), and the API generation accuracy reached 86% (with no parameter format errors), meeting the deployment requirements.

[0108] Step S3: Natural Language Policy Intent Input and Parsing; Step S31: Intent input and error checking; The security administrator enters the following command via Chatbot: "Block access to port 80800 of the internal web server (IP: 10.0.1.100) from external IP range 203.0.113.0 / 24 via the NGFW firewall to prevent DDoS attacks and the CNNVD-2024-XXXX vulnerability"; the system triggers an error check: Format check: The message "Port 80800 is outside the range of 0-65535 supported by NGFW. It is recommended to change it to 8080" is displayed. Integrity check: Asks "Is the NGFW vulnerability linkage protection function enabled? Vulnerability ID (e.g., CNNVD-2024-XXXX) needs to be provided"; Logical check: Confirmed that "denying external IP access + vulnerability linkage" is consistent with NGFW protection logic.

[0109] Step S4: Intended Disassembly; Step S41: Designing prompts; The prompt word template includes an "NGFW policy classification system" (such as: access control, DDoS protection, vulnerability linkage, log auditing), and requires that the sub-tasks be associated with NGFW functional modules after decomposition.

[0110] Step S42: Subtask generation and verification; LLM outputs a list of NGFW scenario subtasks, confirming that the subtasks cover the NGFW-specific "vulnerability linkage" aspect, have no circular dependencies, and that the decomposition results are valid.

[0111] Step S5: Intent translation; Step S51: RAG search; The subtask retrieves Top-5 related records from the vector database: This is a snippet from the NGFW create_access_rule API documentation, including a description of the vulnerability_id parameter. Example of NGFW vulnerability linkage strategy configuration, linking API call code of CNNVD-2024-XXXX; The official NGFW DDoS protection strategy parameter template suggests a priority value of 8-12.

[0112] Step S52: Prompt word construction and API generation; Concatenate an example of NGFW-specific context (e.g., "Subtask: Generate vulnerability linkage API → Code: ngfw_api.create_access_rule(...,vulnerability_id="CNNVD-2024-XXXX")"), and the LLM generator model outputs the corresponding Python code.

[0113] Step S53: Standardization verification; The code was checked and found to contain the NGFW-specific parameter vulnerability_id, which conforms to the SDK calling specifications and is marked as "pending verification".

[0114] Step S6: Code pre-verification; Step S61: Construction of NGFW digital twin model; Equipment modeling: Use the professional network simulation tool GNS3 to configure NGFW hardware parameters (CPU model, memory capacity) consistent with the production network, and import existing policy configurations (such as "allow 10.0.0.0 / 24 to access the DMZ zone").

[0115] Environment modeling: Simulate the enterprise network topology (internal network zone - DMZ zone - external network zone), generating three types of traffic: Target traffic: Simulated DDoS attack traffic (UDP flood, source IP=203.0.113.0 / 24), vulnerability exploitation traffic (malicious requests to port 8080 targeting CNNVD-2024-XXXX). Legitimate traffic: Internal network employees accessing 10.0.1.100:80 (Web service); Background traffic: Consistent with the typical TCP / UDP traffic ratio (7:3) of an enterprise.

[0116] Data synchronization: Synchronize policy logs and vulnerability protection status from the production network NGFW every 5 minutes and update the twin model.

[0117] Step S62: Pre-deployment and verification; Conflict detection: Simulated execution of API code, no conflict with existing policies was detected (no "Allow 203.0.113.0 / 24 to access port 8080" rule), code execution was successful (returning rule ID: R2025XXXX).

[0118] Validity verification: Positive verification: Injected DDoS and vulnerable traffic, NGFW twin device achieved a 100% blocking rate, and logs showed "Blocking triggered by associated vulnerability CNNVD-2024-XXXX"; Negative verification: Legitimate traffic is allowed to pass normally, with no service interruption; Performance verification: In high-traffic (20Gbps) scenarios, the CPU utilization of the twin device is ≤60%, which meets the NGFW performance indicators.

[0119] Compliance verification: The NGFW built-in Information Security Protection 2.0 check module was invoked to confirm that the policy meets the requirements of "Level 3 Information Security Protection for Web Server Ports". The verification was successful.

[0120] Step S7: Code Execution Step S71: Transactional execution and monitoring; Transaction backup: Before execution, call ngfw_api.backup_policy() to back up the current NGFW policy (backup ID: B2025XXXX); Ordered execution: Execute each subtask in sequence. Upon success, return the rule ID: R2025XXXX, and commit the transaction. Post-deployment monitoring: Continuously monitor NGFW metrics (traffic blocking rate, CPU utilization, logs with no abnormal alarms) for 1 hour, and find no configuration anomalies; Results Feedback: Generate an "Automatic NGFW Policy Deployment Report", which includes rule ID, vulnerability association information, and verification results, and notify the administrator through the enterprise SOC platform.

[0121] Working principle: This embodiment achieves end-to-end automation from firewall policy intent described in natural language to API call code execution, eliminating the need for manual writing of policy rules and API code. It reduces the firewall policy generation and deployment time from the traditional hours to days to minutes, improving efficiency by ≥90%. It supports multi-turn dialogue and batch firewall intent processing, further reducing operation and maintenance costs. With a high degree of automation, it significantly improves the efficiency of firewall policy generation.

[0122] This embodiment ensures accuracy through four safeguards: For the firewall domain, LLM is fine-tuned, and combined with an expanded firewall-specific training dataset, the accuracy of policy intent understanding and firewall API generation is improved. The accuracy of intent understanding on the test set is ≥90%, and the accuracy of API generation is ≥85%. Error checking at the firewall's intent input stage prevents policy deviations caused by incorrect input information from the source. RAG technology, combined with a dedicated firewall knowledge base (including a list of firewall APIs, configuration data for different brands of firewalls, etc.), ensures that API calls match the firewall device interface, avoiding the "illusion" generation of incorrect parameters. Firewall policy code pre-verification based on digital twins detects policy conflicts, validity issues, and performance problems, reducing the firewall configuration error rate in production environments by ≥80% and preventing business interruptions and security vulnerabilities.

[0123] This embodiment directly transforms the abstract natural language firewall policy generation intent into machine-executable API call code through a collaborative process of natural language understanding, firewall task decomposition guided by prompt word engineering, and RAG and context learning-enhanced translation. It eliminates the comprehension gap between "business requirements → firewall policy → machine configuration" and ensures a high degree of consistency between firewall policy and intent, thus bridging the semantic gap.

[0124] The other parts of this embodiment are the same as any one of the above embodiments 1-2, so they will not be described again.

[0125] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Any simple modifications or equivalent changes made to the above embodiments based on the technical essence of the present invention shall fall within the protection scope of the present invention.

Claims

1. A method for automatically generating firewall policies based on LLM, characterized in that, Specifically, the following steps are included: Step S1: Preprocess the acquired multi-source data related to firewall policies and build a vector database; Step S2: Fine-tune the LLM generation model according to the set fine-tuning target and the set training parameters; Step S3: Based on the obtained abstract firewall protection requirements and the set error checking mechanism, verify the firewall intent of the input natural language; Step S4: Invoke prompt word engineering techniques to transform firewall intents into a structured, executable sequence of subtasks; Step S5: Convert the subtask sequence into firewall device API call code, standardize the firewall device API call code according to the LLM generation model, and perform preliminary verification; Step S6: Simulate the execution of the firewall device API call code in a digital twin environment to pre-verify the firewall code; Step S7: Deploy the pre-verified firewall code to firewall devices in the production network.

2. The method for automatically generating firewall policies based on LLM according to claim 1, characterized in that, Step S1 specifically includes the following steps: Step S11: Collect multi-source data related to firewall policies; the multi-source firewall policy related data includes firewall threat intelligence, API documentation of mainstream firewall devices, firewall security research documents, historical firewall policy data, natural language intent, firewall vulnerability and attack response data, firewall security protection data, and firewall configuration data; Step S12: Preprocess the collected multi-source data related to firewall policies, and call the text segmentation tool to segment the text data into semantically coherent text blocks that meet the input constraints of the embedding model; Step S13: Call the pre-trained sentence conversion model to convert text blocks into high-dimensional numerical embedding vectors and build a vector database.

3. The method for automatically generating firewall policies based on LLM according to claim 1, characterized in that, Step S2 specifically includes the following steps: Step S21: Use an open-source LLM model that supports long context windows as the base model; Step S22: Construct training samples based on the acquired natural language intent and contextual information; Step S23: Set the training parameters based on the constructed training samples; Step S24: Fine-tune the LLM model based on the training parameters.

4. The method for automatically generating firewall policies based on LLM according to claim 1, characterized in that, Step S3 specifically includes the following steps: Step S31: Construct the firewall policy intent input interface based on the Chatbot class interaction interface; Step S32: Verify the natural language firewall intent obtained from the firewall policy intent input interface; the verification includes format error verification and logical rationality verification.

5. The method for automatically generating firewall policies based on LLM according to claim 1, characterized in that, Step S4 specifically includes the following steps: Step S41: Construct a prompt word template to guide the fine-tuned LLM model to complete the firewall task decomposition according to the set logic; Step S42: Construct a firewall policy classification system based on the firewall protection scenario; Step S43: Based on the prompt word template and the constructed firewall policy classification system, decompose the natural language intent into a sequence of sub-tasks; Step S44: Verify the subtask sequence according to the set constraints.

6. The method for automatically generating firewall policies based on LLM according to claim 1, characterized in that, Step S5 specifically includes the following steps: Step S51: Vectorize the verified subtask sequence, generate subtask vectors, and retrieve the Top-K records with the highest semantic similarity to the subtask vectors from the vector database; Step S52: Obtain a context learning example consistent with the current firewall subtask type, and concatenate it with system instructions, retrieved context information, and firewall subtask description to obtain the enhanced prompt words; Step S53: Input the enhanced prompt words into the LLM generation model to obtain the firewall API call code that meets the requirements; Step S54: Convert the generated firewall API call code into JSON format and perform preliminary verification.

7. The method for automatically generating firewall policies based on LLM according to claim 1, characterized in that, Step S6 specifically includes the following steps: Step S61: Construct a digital twin model of the firewall; Step S62: Simulate the execution of the preliminarily verified firewall API call code in the digital twin environment, and perform conflict detection based on the firewall policy generated by the code; Step S63: Verify whether the policy corresponding to the firewall policy code is consistent with the intent and has no side effects through traffic simulation and compliance checks; Step S64: If the verification passes, mark the firewall API call code as "deployable" and proceed to step S7; if the verification fails, report the reason for the failure to the LLM generation model, and the model will combine the failure information to correct the firewall API call parameters or code logic, and re-execute steps S5-S6 until the verification passes; if the verification still fails after multiple corrections, trigger the manual review process.

8. The method for automatically generating firewall policies based on LLM according to claim 7, characterized in that, Step S61 specifically includes the following steps: Step S611: Construct a firewall network topology model based on the target firewall device's hardware parameters, software version, and existing policy configuration; Step S612: Construct a firewall network environment, simulate the network topology related to the firewall in the production network, and generate virtual traffic consistent with the real environment; Step S613: Synchronize existing policy configurations, traffic logs, device status data, and vulnerability protection configurations from the physical firewall device via a timed interface, and update the firewall digital twin model.

9. The method for automatically generating firewall policies based on LLM according to claim 1, characterized in that, Step S7 specifically includes the following steps: Step S71: Based on the verified firewall API call code, construct the firewall API execution environment; Step S72: Execute the API call code in sequence according to the firewall subtask dependencies.

10. The method for automatically generating firewall policies based on LLM according to claim 9, characterized in that, Step S7 further includes: Step S73: During execution, monitor the status, execution time, return results, and device status of firewall API calls in real time through the log library; Step S74: If all firewall API calls are executed successfully, generate a firewall policy deployment report, notify the user via email, SOC platform or API interface, and provide a way to query firewall policies. Step S75: After execution, check whether the policy has been successfully deployed by calling the query API of the firewall device, and compare whether the actual deployed parameters are consistent with the original intent. If they are inconsistent, trigger the secondary correction process. Step S76: During the monitoring period after the transaction is committed, the key indicators of the affected network segment are continuously tracked through the monitoring script. If the indicator deviates from the preset baseline, it is determined to be a configuration anomaly, and the rollback mechanism is automatically triggered. The rollback mechanism includes calling the firewall recovery configuration API to restore the firewall device to the backup configuration before deployment; recording the rollback log and analyzing the cause of the anomaly. The anomaly information is fed back to the LLM, and after the model is corrected, steps S5-S7 are re-executed; after the rollback is completed, the user is notified and an anomaly analysis report and correction suggestions are provided.

Images