A firewall closed-loop management method and system for pre-interception and configuration verification

Abstract

The application relates to the technical field of network communication and network security, and discloses a firewall closed-loop management method and system for pre-interception and configuration verification, which pre-intercepts firewall policy work orders by calling network asset topology domain data, identifies and blocks ANY full-open rule items and cross-service domain unauthorized items, simultaneously calls a security risk rule knowledge base to perform hierarchical display and forced compliance auditing on risk permissions, and completes policy instruction conversion and issuing based on a multi-vendor firewall instruction template library, logs in to a target firewall device after issuing is completed, compares online running strategies item by item, and finally uniformly pushes all kinds of records to an audit platform for storage and generates an acceptance report, so that the problems of lacking pre-interception of illegal policies, weak compliance auditing, lacking verification after configuration issuing, difficult audit evidence collection and poor multi-vendor compatibility are solved, the whole-process management and control of firewall policies from submission to acceptance is realized, and the operation and maintenance efficiency and the safety management and control level are improved.

Description

Technical Field

[0001] This invention relates to the fields of network communication and network security technology, and in particular to a firewall closed-loop management method and system for pre-interception and configuration verification. Background Technology

[0002] As enterprise network boundaries continue to expand, automated operation and maintenance of firewall policies has become a critical aspect of ensuring network security. Currently, there are two main implementation paths in the industry: one is based on open-source scripts or simple operation and maintenance platforms, which complete the batch command issuance through work order parsing, but can only perform risk scanning after the policy is deployed and does not have the ability to intercept in advance; the other is the native management system provided by firewall vendors, which supports basic configuration issuance and simple conflict detection, but is only adapted to proprietary devices and has not established an independent work order compliance approval process.

[0003] The aforementioned solutions have significant shortcomings in practical application. The existing system lacks a pre-emptive work order interception mechanism; violations such as "ANY all-access" and cross-domain privilege escalation can be directly submitted to the database, requiring post-event rectification and posing significant security risks. Compliance control is weak, lacking risk grading display and mandatory audit nodes, making it easy to miss high-risk permissions and failing to meet financial-grade compliance requirements. Effective verification is lacking after configuration distribution; the system only pushes configuration commands without logging into devices to compare with online policies, failing to promptly detect configuration failures or loss. Furthermore, verification, distribution, and logging are handled by different systems, resulting in fragmented processes, cumbersome auditing and evidence collection, and hindering the formation of a closed management loop. In addition, poor compatibility with multiple devices, the closed nature of the original manufacturer's platform, and the need for manual maintenance of numerous vendor command templates for third-party tools lead to high operational costs.

[0004] Existing solutions merely simplify manual distribution processes, lacking an integrated closed loop encompassing compliance interception at the source, device configuration verification, and audit acceptance. This makes it difficult to balance operational efficiency with the demands of financial-grade security control. Therefore, a technical solution is urgently needed to address these issues. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention provides a firewall closed-loop management method and system for pre-blocking and configuration verification.

[0006] Firstly, the present invention provides a firewall closed-loop management method for pre-blocking and configuration verification, the technical solution of which is as follows: Retrieve network asset topology domain data. If the firewall policy work order contains any fully open rule entries or cross-business domain unauthorized entries, then intercept the firewall policy work order and report the interception result. Generate an interception record based on the any fully open rule entries, the cross-business domain unauthorized entries, and the interception result. For firewall policy work orders that have passed the pre-interception, the security risk rule knowledge base is retrieved to identify risk permissions, the identified risk items are displayed in a hierarchical manner, and after compliance review is passed, the firewall policy work order is allowed to enter the policy generation stage to generate a compliance detection record. Read the standard fields in the firewall policy work order, match them with the multi-vendor firewall instruction template library, convert them into policy instructions adapted to the target firewall device, push the policy instructions to the target firewall device for execution, and generate policy conversion records and execution records. After the distribution is completed, log in to the target firewall device to read the current online running policy, compare the online running policy with the policy instructions one by one, record the abnormal log of the comparison failure and issue an alarm, and generate the device verification record; The interception record, compliance detection record, policy conversion record, issuance and execution record, and device verification record are pushed to the audit platform for storage. Based on the interception record, compliance detection record, policy conversion record, issuance and execution record, and device verification record, a policy change acceptance report, a risk policy list, and execution records are generated.

[0007] The beneficial effects of the firewall closed-loop management method of pre-blocking and configuration verification of the present invention are as follows: The method of this invention pre-intercepts firewall policy work orders by retrieving network asset topology domain data, identifying and blocking all open rule entries and cross-business domain unauthorized entries. Simultaneously, it retrieves a security risk rule knowledge base to display risk permissions in a tiered manner and enforce compliance review. Based on a multi-vendor firewall instruction template library, it completes policy instruction conversion and distribution. After distribution, it logs into the target firewall device to compare each online running policy. Finally, all records are uniformly pushed to the audit platform for storage and an acceptance report is generated. This method solves the problems of lack of pre-interception of illegal policies, weak compliance review, lack of verification after configuration distribution, difficulty in auditing and evidence collection, and poor compatibility among multiple vendors. It achieves full-process control of firewall policies from submission to acceptance, improving operational efficiency and security management level.

[0008] Based on the above scheme, the firewall closed-loop management method of pre-blocking and configuration verification of the present invention can be further improved as follows.

[0009] In one alternative approach, after the step of intercepting the firewall policy ticket, the method further includes: The reason for the violation is determined based on the ANY fully open rule entry or the cross-business domain unauthorized entry, the reason for the violation is marked in the interception record and fed back to the submitting terminal.

[0010] The advantages of using the above optional methods are as follows: After intercepting the firewall policy work order, the reason for the violation is determined according to the ANY fully open rule entries or cross-business domain unauthorized entries. The reason for the violation is marked in the interception record and fed back to the submitting terminal, so that the submitting personnel clearly know the specific reason why the policy was blocked, which facilitates quick location of the problem and targeted modification, reduces the number of repeated submissions, and shortens the work order processing cycle.

[0011] In one optional approach, the compliance audit is a mandatory audit node; if the firewall policy work order fails the compliance audit, it is prohibited from entering the policy generation stage; the compliance audit is passed when the security auditor completes the risk confirmation and approval of the risk item.

[0012] The benefits of adopting the above optional methods are as follows: it further clarifies that compliance review is a mandatory node, prohibits entry into the policy generation stage when the firewall policy work order fails to pass the review, and requires security review personnel to complete the confirmation and approval of risk items, thereby preventing high-risk permissions from bypassing the review and issuing policies directly, strengthening the security control of policy changes, and meeting the requirements of financial-grade compliance management.

[0013] In one alternative approach, the step of hierarchically displaying the identified risk items includes: The identified risk items are displayed in a visually tiered manner, categorized into high security risk level, medium security risk level, and low security risk level; the risk items remain in this tiered display state until the compliance review is passed.

[0014] The beneficial effects of adopting the above optional method are as follows: the identified risk items are further visualized and highlighted according to three security risk levels: high, medium and low, and the display status is maintained until the compliance review is passed, so that the reviewers can intuitively distinguish the risk permissions of different levels, give priority to high-risk items, and improve the accuracy of the review and processing efficiency.

[0015] In one optional approach, the multi-vendor firewall instruction template library stores policy templates corresponding to various firewall brands; when converting to policy instructions adapted to the target firewall device, the corresponding policy template is matched from the multi-vendor firewall instruction template library according to the vendor information of the target firewall device for conversion.

[0016] The advantages of adopting the above optional approach are as follows: it further clarifies that the multi-vendor firewall instruction template library stores policy templates corresponding to various brands of firewalls. When converting policy instructions, the corresponding template is automatically matched according to the vendor information of the target firewall device, so as to achieve unified adaptation to devices from different vendors, reduce the cost of manual template maintenance, and improve the accuracy and compatibility of policy conversion.

[0017] In one alternative approach, the step of logging into the target firewall device and reading the currently running online policies includes: After the distribution is completed, a device login session with the target firewall device is automatically established, and the current online operating policy of the target firewall device is read through the device login session.

[0018] The advantages of adopting the above optional method are: after the policy command is issued, a login session with the target firewall device is automatically established, and the currently running online policy is read directly through the session, avoiding the tedious operation of manually logging into each device one by one, reducing the risk of omission, and providing accurate actual device configuration data for subsequent comparison.

[0019] In one optional approach, when comparing the online running policy with the policy instructions one by one, if the comparison reveals that there is a policy loss anomaly, a syntax error anomaly, or a configuration failure anomaly in the online running policy of the target firewall device, then an anomaly log is recorded and an alarm is issued. The exception log contains exception information corresponding to the policy loss exception, the syntax error exception, or the configuration failure exception; the device verification record contains the exception log.

[0020] The advantages of adopting the above optional methods are: further identifying anomalies such as policy loss, syntax errors, or configuration failures during the item-by-item comparison process, recording anomaly logs and issuing alarms, the anomaly logs containing specific anomaly information and being included in the device verification record, helping operation and maintenance personnel to promptly discover deployment failures or configuration deviations, accurately locate the problem type, and ensure the accurate implementation of firewall policies on the target device.

[0021] Secondly, this invention provides a firewall closed-loop management system for pre-blocking and configuration verification, the technical solution of which is as follows: The interception module is used to retrieve network asset topology domain data. If the firewall policy work order contains any fully open rule entries or cross-business domain unauthorized entries, the firewall policy work order is intercepted and the interception result is fed back. An interception record is generated based on the any fully open rule entries, the cross-business domain unauthorized entries and the interception result. The detection module is used to retrieve the security risk rule knowledge base to identify risk permissions for the firewall policy work order that has passed the pre-interception, display the identified risk items in a hierarchical manner, and allow the firewall policy work order to enter the policy generation stage after the compliance review is passed, and generate a compliance detection record. The distribution module is used to read the standard fields in the firewall policy work order, match them with the multi-vendor firewall instruction template library, convert them into policy instructions adapted to the target firewall device, push the policy instructions to the target firewall device for execution, and generate policy conversion records and distribution execution records. The generation module is used to log in to the target firewall device after the distribution is completed, read the current online running policy, compare the online running policy with the policy instructions one by one, record the abnormal log of the comparison failure and issue an alarm, and generate the device verification record. The management module is used to push the interception records, compliance detection records, policy conversion records, issuance and execution records, and device verification records to the audit platform for storage, and to generate policy change acceptance reports, risk policy lists, and execution records based on the interception records, compliance detection records, policy conversion records, issuance and execution records, and device verification records.

[0022] The beneficial effects of the firewall closed-loop management system for pre-blocking and configuration verification of the present invention are as follows: The system of this invention pre-intercepts firewall policy work orders by retrieving network asset topology domain data, identifying and blocking all open rule entries and cross-business domain unauthorized entries. Simultaneously, it retrieves a security risk rule knowledge base to display risk permissions in a tiered manner and enforce compliance audits. Based on a multi-vendor firewall instruction template library, it completes policy instruction conversion and distribution. After distribution, it logs into the target firewall device to compare each online running policy. Finally, all records are uniformly pushed to the audit platform for storage and an acceptance report is generated. This solves the problems of lack of pre-interception of illegal policies, weak compliance audits, lack of verification after configuration distribution, difficulty in auditing and evidence collection, and poor compatibility among multiple vendors. It achieves full-process control of firewall policies from submission to acceptance, improving operational efficiency and security management level.

[0023] Thirdly, the technical solution of an electronic device according to the present invention is as follows: It includes a memory, a processor, and a program stored in the memory and running on the processor, wherein the processor executes the program to implement the steps of the firewall closed-loop management method of pre-blocking and configuration verification as described in this invention.

[0024] Fourthly, the technical solution of a computer-readable storage medium provided by the present invention is as follows: The computer-readable storage medium stores instructions that, when read, cause the computer-readable storage medium to perform the steps of the firewall closed-loop management method of the pre-blocking and configuration verification of the present invention.

[0025] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention, it can be implemented according to the contents of the specification. In order to make the above and other objects, features and advantages of the present invention more obvious and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0026] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This is a flowchart illustrating an embodiment of a firewall closed-loop management method for pre-blocking and configuration verification according to the present invention. Figure 2 This is a schematic diagram of the overall process; Figure 3 This is a schematic diagram of an embodiment of a firewall closed-loop management system for pre-blocking and configuration verification according to the present invention. Figure 4 This is a schematic diagram of an embodiment of an electronic device according to the present invention. Detailed Implementation

[0027] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein.

[0028] Figure 1 This diagram illustrates a flowchart of an embodiment of a firewall closed-loop management method for pre-blocking and configuration verification provided by the present invention. This method can be executed by electronic devices such as terminal devices or servers. The terminal device can be any fixed or mobile terminal, such as user equipment (UE), mobile device, user terminal, terminal, cellular phone, cordless phone, personal digital assistant (PDA), handheld device, computing device, in-vehicle device, or wearable device. The server can be a single server or a server cluster consisting of multiple servers. Any electronic device can implement the firewall closed-loop management method for pre-blocking and configuration verification by having its processor call computer-readable instructions stored in its memory. Figure 1 As shown, it includes the following steps: S1. Retrieve network asset topology domain data. If the firewall policy work order contains any fully open rule entries or cross-business domain unauthorized entries, then intercept the firewall policy work order and report the interception result. Generate an interception record based on the any fully open rule entries, the cross-business domain unauthorized entries, and the interception result.

[0029] Network asset topology domain data refers to a collection of information storing the business partition, network domain division, and asset network segment range of a network asset, used to determine whether an access request crosses a business boundary. For example, in a company's network asset topology domain data, business partition A corresponds to the office network segment 192.168.1.0 / 24, and business partition B corresponds to the production network segment 10.0.0.0 / 24. A firewall policy work order refers to a user-submitted permission request form containing fields such as source address, destination address, destination port, protocol type, and action. For example, a user submits a firewall policy work order where the source address is 0.0.0.0 / 0, the destination address is 10.0.0.5, the destination port is 3389, the protocol is TCP, and the action is "allow".

[0030] Among them, an "ANY Fully Open" rule entry refers to a rule in a firewall policy ticket where the source or destination address is set to any address, i.e., 0.0.0.0 / 0. For example, if the source address in the aforementioned firewall policy ticket is filled in as 0.0.0.0 / 0, then this entry is an "ANY Fully Open" rule entry. A cross-domain unauthorized access entry refers to a rule in a firewall policy ticket where the service partition where the access source is located is different from the service partition where the access destination is located, and the source partition does not have the right to access the destination partition. For example, if the source address 192.168.1.10 belongs to service partition A, and the destination address 10.0.0.5 belongs to service partition B, but service partition A in the network asset topology domain data does not have the right to access service partition B, then this entry is a cross-domain unauthorized access entry.

[0031] The interception result refers to the approval or rejection decision made after pre-verification of the firewall policy ticket. For example, if a firewall policy ticket is found to contain any fully open rule entries and cross-domain unauthorized access entries, a rejection decision is made, and this rejection decision is the interception result. The interception record refers to data that records the violation type, interception time, and interception result of the intercepted firewall policy ticket. For example, an interception record shows that the ticket was rejected because it contained any fully open rule entries and cross-domain unauthorized access entries.

[0032] S2. For the firewall policy work order that has passed the pre-interception, retrieve the security risk rule knowledge base to identify risk permissions, display the identified risk items in a hierarchical manner, and allow the firewall policy work order to enter the policy generation stage after the compliance review is passed, and generate a compliance detection record.

[0033] The security risk rule knowledge base refers to a set of rules that stores high-risk port numbers, excessively large address ranges, and minimum privilege determination criteria. For example, the security risk rule knowledge base records high-risk ports including 3389, 22, and 23; excessively large address ranges are defined as network segments with source or destination address masks less than or equal to 16; and the minimum privilege determination criteria are the minimum number of ports and address ranges required to open services. Risk permissions refer to permission settings in firewall policy work orders that violate the security policy requirements defined in the security risk rule knowledge base. For example, in a work order, destination port 3389 is a high-risk port, and the segment mask of destination address 10.0.0.5 is 24, which does not constitute an excessively large address range, but port 3389 makes this permission a risk permission.

[0034] Here, a risk item refers to a specific permission element identified from the firewall policy work order that violates the security risk rule knowledge base. For example, two risk items are identified from the work order: one is the high-risk port 3389, and the other is that the destination address range 10.0.0.0 / 8 belongs to an oversized address range. Tiered display means that the identified risk items are categorized and displayed according to predefined security risk levels. For example, the high-risk port 3389 is marked as a high security risk level, and the oversized address range 10.0.0.0 / 8 is marked as a medium security risk level, and displayed in red and yellow respectively on the interface.

[0035] Among them, the compliance inspection record refers to the data that records the risk permissions, risk item classification results and compliance review status identified during the compliance inspection process; for example, a compliance inspection record records a work order containing two risk items: high-risk port 3389 and oversized address range 10.0.0.0 / 8, and the review status is pending review.

[0036] S3. Read the standard fields in the firewall policy work order, match them with the multi-vendor firewall instruction template library, convert them into policy instructions adapted to the target firewall device, push the policy instructions to the target firewall device for execution, and generate policy conversion records and execution records.

[0037] The standard fields refer to the necessary information fields used to generate device policy instructions in firewall policy work orders, including source address, destination address, destination port, protocol, and action. For example, the source address 192.168.1.0 / 24, destination address 10.0.0.5, destination port 8080, protocol TCP, and action "allow" are read from the work order as standard fields. The multi-vendor firewall instruction template library refers to a collection of templates storing the policy configuration command formats for various brands of firewall devices. For example, the multi-vendor firewall instruction template library stores the access control list command format for device brand A as `access-list 100 permit tcp source any destination any eq 8080`, and the command format for device brand B as `policy add rule id 1 from any to any service 8080 action permit`.

[0038] The target firewall device refers to the specific firewall hardware or virtualization instance for which the policy directive needs to be issued. For example, the target firewall device for this work order is firewall brand A located at the network egress. The policy directive refers to a configuration command generated based on standard fields and a multi-vendor firewall directive template library, which can be directly executed on the target firewall device. For example, based on standard fields matching the template for device brand A, the policy directive `access-list 100 permit tcp source 192.168.1.0 0.0.0.255 destination10.0.0.5 0.0.0.0 eq 8080` is generated.

[0039] The policy conversion record refers to data recording the template matching and command generation process involved in converting standard fields into policy instructions. For example, a policy conversion record might record matching a device brand A template, resulting in the policy instruction: `access-list 100 permit tcp source 192.168.1.0 0.0.0.255destination 10.0.0.5 0.0.0.0 eq 8080`. The execution record refers to data recording the time the policy instruction was pushed to the target firewall device, the device's response status, and the execution result. For example, an execution record might record that the policy instruction was pushed to the target firewall device at 10:30 AM on August 1, 2026, and the device returned a success status code.

[0040] S4. After the distribution is completed, log in to the target firewall device to read the current online running policy, compare the online running policy with the policy instructions one by one, record the abnormal log of the comparison failure and issue an alarm, and generate the device verification record.

[0041] The currently running online policy refers to the set of all policy rules currently in effect on the target firewall device, read from the device after the policy instruction has been issued. For example, logging into the target firewall device and executing the `showaccess-list` command retrieves the currently running online policy, which includes ten existing access control list rules. The exception log refers to log information recording inconsistencies or errors when comparing the online policy with each policy instruction. For example, if the comparison reveals that a newly issued policy instruction is missing from the online policy, an exception log is recorded stating "Policy missing: Rule with ID 100 not found."

[0042] Among them, the device verification record refers to the complete data of the process of comparing online operation policies and policy instructions, comparison results and anomaly logs; for example, a device verification record records the comparison time as 10:35 on August 1, 2026, the comparison result as policy loss, and the anomaly log number as ERR-001.

[0043] S5. Push the interception record, the compliance detection record, the policy conversion record, the issuance and execution record, and the device verification record to the audit platform for storage, and generate a policy change acceptance report, a risk policy list, and an execution record based on the interception record, the compliance detection record, the policy conversion record, the issuance and execution record, and the device verification record.

[0044] The audit platform refers to a platform used for centralized storage and management of the entire process log of firewall policy changes. For example, interception records, compliance detection records, policy conversion records, issuance and execution records, and device verification records are uniformly formatted and pushed to the audit platform for storage via a secure file transfer protocol.

[0045] The strategy change acceptance report refers to a formal document generated based on the entire process record, used to prove to the business party that the strategy change has been completed and meets the requirements. For example, a strategy change acceptance report includes the change work order number, change time, changed device, strategy instruction list, and verification results. The risk strategy list refers to a list of all risk permissions involved in this change and their corresponding handling measures. For example, a risk strategy list shows that the high-risk port 3389 has passed compliance review and been allowed, and the oversized address range 10.0.0.0 / 8 has been reduced to 10.0.0.5 / 32. The execution record refers to a time-series record summarizing the entire process operation steps and status from work order submission to acceptance report output. For example, an execution record lists the completion time and status of each step in chronological order: work order submission, pre-interception, compliance detection, strategy generation, issuance and execution, device verification, and report output.

[0046] The technical solution in this embodiment intercepts firewall policy work orders by retrieving network asset topology domain data, identifying and blocking all open rule entries and cross-business domain unauthorized entries. Simultaneously, it retrieves a security risk rule knowledge base to display risk permissions in a tiered manner and enforce compliance review. Based on a multi-vendor firewall instruction template library, it completes policy instruction conversion and distribution. After distribution, it logs into the target firewall device to compare each online running policy. Finally, all records are uniformly pushed to the audit platform for storage and an acceptance report is generated. This solution addresses the problems of lack of pre-interception of illegal policies, weak compliance review, lack of verification after configuration distribution, difficulty in auditing and evidence collection, and poor compatibility among multiple vendors. It achieves full-process control of firewall policies from submission to acceptance, improving operational efficiency and security management level.

[0047] In one alternative approach, after the step of intercepting the firewall policy ticket, the method further includes: The reason for the violation is determined based on the ANY fully open rule entry or the cross-business domain unauthorized entry, the reason for the violation is marked in the interception record and fed back to the submitting terminal.

[0048] The reason for violation refers to the specific basis for determining that the firewall policy ticket violates the pre-blocking rules. For example, the reason for the violation is that the source address is entered as 0.0.0.0 / 0, which constitutes an ANY fully open rule, and the source partition A does not have permission to access the destination partition B, which constitutes cross-domain unauthorized access. The submitting terminal refers to the computer device or client application used by the user to submit the firewall policy ticket. For example, if the user submits the ticket through the ticket submission page on a laptop, the laptop is the submitting terminal.

[0049] In the above-mentioned optional methods, after intercepting the firewall policy work order, the reason for the violation is determined according to any fully open rule entries or cross-business domain unauthorized entries. The reason for the violation is marked in the interception record and fed back to the submitting terminal, so that the submitting personnel clearly know the specific reason why the policy was blocked, which facilitates quick location of the problem and targeted modification, reduces the number of repeated submissions, and shortens the work order processing cycle.

[0050] In one optional approach, the compliance audit is a mandatory audit node; if the firewall policy work order fails the compliance audit, it is prohibited from entering the policy generation stage; the compliance audit is passed when the security auditor completes the risk confirmation and approval of the risk item.

[0051] The mandatory review node refers to a fixed process point where firewall policy work orders must be manually confirmed by security auditors before entering the policy generation stage. For example, compliance review is set as a mandatory review node; after the work order is displayed in tiers, it must be approved by security auditors before proceeding. The policy generation stage refers to the processing phase where policy instructions for the target device are automatically generated based on the standard fields of the work order that has passed compliance review and a multi-vendor firewall instruction template library. For example, after compliance review is passed, the policy generation stage begins, converting the standard fields into policy instructions for device brand A.

[0052] Among the above optional methods, compliance review is further clarified as a mandatory step. If the firewall policy work order fails to pass the review, it is prohibited from entering the policy generation stage. Security review personnel shall complete the confirmation and approval of risk items to prevent high-risk permissions from bypassing the review and issuing directly, thereby strengthening the security control of policy changes and meeting the requirements of financial-grade compliance management.

[0053] In one alternative approach, the step of hierarchically displaying the identified risk items includes: The identified risk items are displayed in a visually tiered manner, categorized into high security risk level, medium security risk level, and low security risk level; the risk items remain in this tiered display state until the compliance review is passed.

[0054] The high security risk level refers to the highest risk level assigned to permission settings that may directly lead to network intrusion or data leakage; for example, access permissions to the high-risk port 3389 are marked as high security risk level. The medium security risk level refers to the moderate risk level assigned to permission settings that may expand the attack surface but are not directly high-risk; for example, access permissions to the very large address range 10.0.0.0 / 8 are marked as medium security risk level. The low security risk level refers to the lowest risk level assigned to permission settings that only have minor compliance deviations with minimal impact; for example, situations where the destination port range is too large but does not include high-risk ports are marked as low security risk level.

[0055] The visual hierarchical highlighting refers to the use of different colors or markers in the user interface to clearly distinguish and display risk items with high, medium, and low security risk levels. For example, in the audit interface, the high-risk port 3389 is highlighted in red, the oversized address range 10.0.0.0 / 8 is highlighted in yellow, and low-risk items are highlighted in green.

[0056] Among the above optional methods, the identified risk items are further visualized and highlighted according to three security risk levels: high, medium, and low. This display remains until the compliance review is passed, allowing reviewers to intuitively distinguish between different levels of risk permissions, prioritize high-risk items, and improve the accuracy and efficiency of the review process.

[0057] In one optional approach, the multi-vendor firewall instruction template library stores policy templates corresponding to various firewall brands; when converting to policy instructions adapted to the target firewall device, the corresponding policy template is matched from the multi-vendor firewall instruction template library according to the vendor information of the target firewall device for conversion.

[0058] Here, "policy template" refers to a predefined policy command format framework for a specific brand of device within a multi-vendor firewall instruction template library. For example, the policy template for device brand A is: `access-list 100 permit tcpsource src src-wildcard destination dst dst-wildcard eq port`. "Vendor information" refers to the brand and model identifier of the target firewall device, used to match the corresponding policy template from the multi-vendor firewall instruction template library. For example, if the target firewall device's vendor information is detected as device brand A, then the policy template for device brand A will be matched.

[0059] Among the above optional methods, it is further clarified that the multi-vendor firewall instruction template library stores policy templates corresponding to various brands of firewalls. When converting policy instructions, the corresponding template is automatically matched according to the vendor information of the target firewall device, so as to achieve unified adaptation for devices from different vendors, reduce the cost of manual template maintenance, and improve the accuracy and compatibility of policy conversion.

[0060] In one alternative approach, the step of logging into the target firewall device and reading the currently running online policies includes: After the distribution is completed, a device login session with the target firewall device is automatically established, and the current online operating policy of the target firewall device is read through the device login session.

[0061] The device login session refers to a secure communication connection established with the target firewall device after the command is issued, which is used to execute command reading. For example, a device login session with the target firewall device is established through the Secure Shell protocol, and the session identifier is SSH-20260801-001.

[0062] In the above-mentioned optional methods, a login session with the target firewall device is automatically established after the policy command is issued. The currently running online policy is read directly through the session, avoiding the tedious operation of manually logging into each device one by one, reducing the risk of omission, and providing accurate actual device configuration data for subsequent comparison.

[0063] In one optional approach, when comparing the online running policy with the policy instructions one by one, if the comparison reveals that there is a policy loss anomaly, a syntax error anomaly, or a configuration failure anomaly in the online running policy of the target firewall device, then an anomaly log is recorded and an alarm is issued. The exception log contains exception information corresponding to the policy loss exception, the syntax error exception, or the configuration failure exception; the device verification record contains the exception log.

[0064] Among these, "Policy Loss Anomaly" refers to the situation where, during comparison of online running policies, the target firewall device is found to lack the issued policy instructions; for example, if the comparison reveals that there is no access control list rule with ID 100 in the online running policies, it is determined to be a policy loss anomaly. "Syntax Error Anomaly" refers to the situation where the target firewall device returns an error message when receiving policy instructions because the command format does not conform to the device specifications; for example, if the destination address format of the issued policy instruction lacks a wildcard, the device returns a syntax error message, which is determined to be a syntax error anomaly. "Configuration Not Effective Anomaly" refers to the situation where the policy instructions are saved in the target firewall device but have not entered the running state; for example, if the comparison reveals that the policy instructions exist in the startup configuration but are not in the currently running configuration, it is determined to be a configuration not effective anomaly.

[0065] In the above-mentioned optional methods, further anomalies such as policy loss, syntax errors, or configuration failures are identified during the item-by-item comparison process. Anomaly logs are recorded and alarms are issued. The anomaly logs contain specific anomaly information and are included in the device verification record. This helps operation and maintenance personnel to promptly discover deployment failures or configuration deviations, accurately locate the problem type, and ensure the accurate implementation of firewall policies on the target device.

[0066] The firewall closed-loop management method for pre-blocking and configuration verification provided in this embodiment is designed for heterogeneous firewall devices from multiple vendors. The overall architecture, from front to back, consists of a work order access interception layer, a security compliance verification layer, a policy auto-generation layer, a batch deployment execution layer, a device configuration verification layer, and an audit and acceptance closed-loop layer. These six functional layers execute sequentially according to the work order flow, forming a complete control chain from work order submission to acceptance and delivery. The work order access interception layer performs pre-verification and violation interception at the time of work order submission. The security compliance verification layer performs risk identification and mandatory compliance review on work orders that pass pre-verification. The policy auto-generation layer automatically generates policy instructions adapted to different firewall brands based on work orders that pass compliance review. The batch deployment execution layer pushes policy instructions to the firewall cluster to complete the configuration operation. The device configuration verification layer logs into the device after deployment to read the online running configuration and compares it with the policy instructions for consistency. The audit and acceptance closed-loop layer collects the entire process operation record, pushes it to the audit platform, and outputs acceptance data for delivery to the business party. The six functional layers are uniformly connected to three underlying databases: the network asset topology domain database, the security risk rule knowledge base, and the multi-vendor firewall instruction template library. The network asset topology domain database stores business partition information, network domain division information, and asset network segment information. The security risk rule knowledge base stores high-risk port numbers, excessively large address ranges, and minimum privilege judgment standards. The multi-vendor firewall instruction template library stores policy templates corresponding to various firewall brands.

[0067] like Figure 2 As shown, the specific execution flow of the method in this embodiment is as follows: Users submit firewall policy work orders to the system. These work orders include fields such as source address, destination address, destination port, protocol type, and action. Upon submission, the work order first enters the work order admission and interception layer. The system immediately retrieves network asset topology domain data to perform pre-verification on the work order. The system identifies whether the firewall policy work order contains any "ANY" (all-open) rule entries. If the source or destination address in the work order is set to 0.0.0.0 / 0, the system determines that the work order contains any "ANY" rule entries and directly rejects the work order, preventing it from proceeding to the next stage. The system also combines the service partition information, network domain division information, and asset network segment information in the network asset topology domain data to identify whether there are cross-service domain unauthorized entries in the firewall policy work order. If the service partition to which the source IP belongs in the work order is different from the service partition to which the destination IP belongs, and the source partition has no right to access the destination partition, the system determines that the work order contains a cross-service domain unauthorized entry and blocks it. For blocked firewall policy work orders, the system provides real-time feedback on the blocking results to the submitter. The system determines the reason for the violation based on any fully open rule entries or cross-business domain unauthorized entries, and marks the reason for the violation in the blocking record. The blocking record includes the type of violation entry in the blocked work order, the blocking time, and the blocking result.

[0068] Firewall policy work orders that pass the pre-entry verification at the work order access interception layer automatically enter the security compliance verification layer. The system retrieves the security risk rule knowledge base and, based on the high-risk port numbers, excessively large address ranges, and minimum privilege judgment standards stored in the knowledge base, matches and identifies the risk permissions contained in the firewall policy work order. Risk permissions include high-risk port access permissions, excessively large address range access permissions, and non-minimum privilege access permissions. The system marks each specific permission element that violates the security risk rule knowledge base as a risk item and visually highlights the identified risk items according to high security risk level, medium security risk level, and low security risk level. Different colors or markers are used in the user interface to clearly distinguish the three levels of risk items. The security compliance verification layer has a mandatory review node. Firewall policy work orders must be manually confirmed by security reviewers before entering the policy generation stage. Only after the security reviewers have confirmed and approved the risk items can the work order enter the policy generation stage. If a firewall policy work order fails the compliance review, the system prohibits the work order from entering the policy generation stage, and the work order maintains a hierarchical display status until the compliance review is passed. After the security and compliance verification layer is completed, the system generates a compliance inspection record, which includes the identified risk permissions, risk item classification results, and compliance audit status.

[0069] After compliance review is passed, the firewall policy ticket enters the automatic policy generation layer. The system reads the standard fields from the firewall policy ticket, including source address, destination address, destination port, protocol type, and action. The system matches the multi-vendor firewall command template library, matching the corresponding policy template based on the target firewall device's vendor information. The standard fields are automatically converted into policy commands adapted to the target firewall device according to the policy template format. These policy commands are configuration commands that can be directly executed on the target firewall device. After the automatic policy generation layer completes, the system generates a policy conversion record, which contains template matching information and the command generation process.

[0070] After the policy instructions are generated, they enter the batch delivery execution layer. The system establishes a management communication channel with the firewall cluster and pushes the policy instructions in batches to each target firewall device in the firewall cluster for execution. After the batch delivery execution layer completes its execution, the system generates a delivery execution record, which includes the policy instruction push time, device response status, and delivery result.

[0071] After the policy command is issued, the system proceeds to the device configuration verification layer. The system automatically establishes a device login session with the target firewall device, logs into the target firewall device through this session, and reads all currently running policies. The system compares the read currently running policies with the issued policy commands one by one. If the comparison reveals policy loss, syntax error, or configuration ineffectiveness anomalies in the target firewall device's online running policies, the system records an anomaly log and issues an alarm. The anomaly log contains the corresponding anomaly information for the policy loss, syntax error, or configuration ineffectiveness anomaly. If no anomalies are found, the system determines that the policy was issued successfully. After the device configuration verification layer completes, the system generates a device verification record based on the comparison process and results. The device verification record includes the anomaly log.

[0072] After the entire process is completed, it enters the audit and acceptance closed-loop layer. The system collects interception records generated during the execution of the work order access interception layer, compliance detection records generated during the execution of the security compliance verification layer, policy conversion records generated during the execution of the policy automatic generation layer, distribution execution records generated during the execution of the batch distribution execution layer, and device verification records generated during the execution of the device configuration verification layer. After standardizing and formatting all collected records, they are pushed to the audit platform for storage, and all operations are fully traceable. Based on the interception records, compliance detection records, policy conversion records, distribution execution records, and device verification records, the system generates a policy change acceptance report, a risk policy list, and execution records. The policy change acceptance report includes the change work order number, change time, changed device, policy instruction list, and verification results. The risk policy list lists all risk permissions involved in this change and corresponding handling measures. The execution records list the completion time and status of each step from firewall policy work order submission to report output in chronological order. The system delivers the policy change acceptance report, risk policy list, and execution records to the business side to complete the change acceptance, forming a complete closed loop from security pre-control, automated distribution, equipment verification, audit archiving to business acceptance.

[0073] In another embodiment of the firewall closed-loop management method of pre-blocking and configuration verification of the present invention, the firewall closed-loop management method of pre-blocking and configuration verification is applied to the network security management scenario of an insurance company. The internal network of the insurance company is divided into underwriting business domain, claims business domain, reinsurance business domain, and customer information domain. Access control policies are configured between different business domains in accordance with the data security compliance requirements of the insurance industry, and each business domain is equipped with firewall devices of corresponding brands.

[0074] S10. Receive a firewall policy work order submitted by the insurance client. The firewall policy work order includes a source address, a destination address, a destination port, a protocol type, and an action field. The source address field is used to identify the source IP address that initiated the access request. The destination address field is used to identify the destination IP address that was accessed. The destination port field is used to identify the service port number that was accessed. The protocol type field is used to identify the transport layer protocol type. The action field is used to identify whether to allow or deny access.

[0075] S20. Retrieve insurance network asset topology domain data. If the firewall policy work order contains any fully open rule entries or cross-business domain unauthorized entries, then intercept the firewall policy work order and report the interception result. Generate an interception record based on the any fully open rule entries, the cross-business domain unauthorized entries, and the interception result. The insurance network asset topology domain data records the first network segment corresponding to the underwriting business domain, the second network segment corresponding to the claims business domain, the third network segment corresponding to the reinsurance business domain, the fourth network segment corresponding to the customer information domain, and the legal access permission relationships between each business domain.

[0076] S30. For the firewall policy work order that has passed the pre-interception, retrieve the insurance security risk rule knowledge base to identify risk permissions, display the identified risk items in a hierarchical manner, and allow the firewall policy work order to enter the policy generation stage after compliance review is passed, generating a compliance detection record. The insurance security risk rule knowledge base stores the range of high-risk ports in the insurance industry, the threshold for judging excessively large address ranges, and the minimum permission judgment criteria. The minimum permission judgment criteria have different permission opening thresholds set according to the type of insurance business and the sensitivity level of customer data.

[0077] Before compliance review is approved, calculate the comprehensive compliance risk assessment value of the firewall policy work order using the following formula: in, This indicates the comprehensive compliance risk assessment value of the aforementioned firewall policy work order. The value of is greater than 0 and less than or equal to 2; This indicates the total number of risk items identified in the firewall policy work order. It is an integer greater than or equal to 1; Indicates the sequence number of the risk item; Indicates the first The business weight coefficient corresponding to each risk item, wherein the value of the business weight coefficient is greater than 0 and less than or equal to 1, and the business weight coefficient is based on the first... The type of insurance business involved in each risk item is obtained by matching from the insurance security risk rules knowledge base; Indicates the first The permission deviation of the first risk item, wherein the permission deviation is the first... The ratio of the source address range size in each risk item to the minimum source address range size defined by the least privilege criterion. The value of is greater than or equal to 1; This represents the maximum value of the permission deviation for all risk items in the firewall policy work order; Indicates the first The risk level coefficients for each risk item are as follows: the risk level coefficient corresponding to the high safety risk level is the first risk value, the risk level coefficient corresponding to the medium safety risk level is the second risk value, and the risk level coefficient corresponding to the low safety risk level is the third risk value. The first risk value is 3, the second risk value is 2, and the third risk value is 1. The inter-domain access sensitivity factor is defined as a value greater than 0 and less than or equal to 1. The inter-domain access sensitivity factor is obtained from the insurance security risk rule knowledge base based on the sensitivity of insurance data interaction between the business domain where the source address is located and the business domain where the destination address is located, as specified in the firewall policy work order. This represents the count of unauthorized access risks between the service domains of the source and destination addresses in the firewall policy work order. The unauthorized access risk count is one less than the number of service domain boundary layers crossed between the source and destination addresses in the firewall policy work order. It is an integer greater than or equal to 0; This indicates the maximum number of cross-domain layers between the service domains of the source and destination addresses in the firewall policy work order. The value is an integer greater than or equal to 1; the comprehensive assessment value of the compliance risk is... Compared with the preset compliance threshold, if If the risk exceeds the preset compliance threshold, the corresponding risk item in the firewall policy work order will be highlighted and the reviewer will be prompted to pay close attention.

[0078] It should be noted that the above formula quantifies the risk of firewall policy work orders from three dimensions: network topology compliance, security rule compliance, and insurance business sensitivity. The numerator calculates the weighted risk contribution value by introducing the ratio of permission deviation to the minimum privilege criterion and combining it with the logarithmic growth function of the risk level coefficient. The denominator normalizes the permission deviation value in the numerator by weighted summation of the risk level coefficient, so that a single risk item will not excessively dominate the overall assessment result due to excessive permission deviation. At the same time, the cross-domain unauthorized access penalty factor is used to reflect the incremental impact of cross-domain access unauthorized access risk on the compliance assessment result by calculating the ratio of the number of business domain boundary layers actually crossed between the source address and the destination address to the maximum number of cross-domain layers and combining it with the business domain access sensitivity factor.

[0079] The above formula integrates multiple heterogeneous risk features identified in firewall policy work orders into a quantifiable comprehensive compliance risk assessment value. It automatically prioritizes risk items and predicts risk levels before manual confirmation by compliance auditors. By comparing with preset compliance thresholds, it automatically marks and prompts high-risk work orders or high-risk items, thereby providing objective and quantitative decision support for the mandatory compliance audit process.

[0080] S40. Read the standard fields in the firewall policy work order, match them with the multi-vendor firewall instruction template library, convert them into policy instructions adapted to the target firewall device in the insurance business domain, push the policy instructions to the target firewall device for execution, and generate policy conversion records and execution records. The target firewall device is an underwriting business domain firewall device, a claims business domain firewall device, a reinsurance business domain firewall device, or a customer information domain firewall device.

[0081] S50. After the distribution is completed, log in to the target firewall device to read the current online running policy, compare the online running policy with the policy instructions one by one, record the abnormal log of the comparison failure and issue an alarm, and generate the device verification record.

[0082] S60. Push the interception record, the compliance detection record, the policy conversion record, the issuance and execution record, and the device verification record to the audit platform for storage, and generate a policy change acceptance report, a risk policy list, and an execution record based on the interception record, the compliance detection record, the policy conversion record, the issuance and execution record, and the device verification record. The policy change acceptance report includes the insurance business domain identifier, change work order number, change time, change device information, policy instruction list, and verification results.

[0083] The technical solution of this embodiment executes a dual pre-interception of ANY fully open rules and cross-business domain unauthorized access on firewall policy work orders by retrieving insurance network asset topology domain data. Before compliance review, the number of unauthorized access layers and the deviation of risk permissions are included in the comprehensive compliance risk assessment value for quantitative calculation to provide an objective basis for risk ranking and highlighting. After the issuance is completed, the system logs into the target firewall device to read the currently running policies and compares them with the issued instructions one by one to actively capture three types of anomalies: policy loss, syntax errors, and configuration failure. The entire process operation record is uniformly pushed to the audit platform and outputs a policy change acceptance report and a risk policy list. At the same time, the system achieves unified adaptation of firewall devices of different brands by matching and converting the firewall instruction template library of multiple vendors. This solves the comprehensive problems of lack of pre-interception of illegal policies, lack of quantitative reference for compliance review, inability to verify the effectiveness status after configuration is pushed, and difficulty in tracing multiple systems. It reduces the operation and maintenance complexity in a multi-device environment and improves the auditability of policy changes.

[0084] Figure 3 This diagram illustrates the structure of an embodiment of a firewall closed-loop management system 200 for pre-blocking and configuration verification provided by the present invention. Figure 3 As shown, the firewall closed-loop management system 200 for pre-blocking and configuration verification includes: The interception module 201 is used to retrieve network asset topology domain data. If the firewall policy work order contains any fully open rule entries or cross-business domain unauthorized entries, the firewall policy work order is intercepted and the interception result is fed back. An interception record is generated based on the any fully open rule entries, the cross-business domain unauthorized entries and the interception result. The detection module 202 is used to retrieve the security risk rule knowledge base to identify risk permissions for the firewall policy work order that has passed the pre-interception, display the identified risk items in a hierarchical manner, and allow the firewall policy work order to enter the policy generation stage after the compliance review is passed, and generate a compliance detection record. The distribution module 203 is used to read the standard fields in the firewall policy work order, match them with the multi-vendor firewall instruction template library, convert them into policy instructions adapted to the target firewall device, push the policy instructions to the target firewall device for execution, and generate policy conversion records and distribution execution records. The generation module 204 is used to log in to the target firewall device after the distribution is completed, read the current online running policy, compare the online running policy with the policy instructions one by one, record the abnormal log of the comparison failure and issue an alarm, and generate the device verification record. The management module 205 is used to push the interception record, the compliance detection record, the policy conversion record, the issuance and execution record, and the device verification record to the audit platform for storage, and to generate a policy change acceptance report, a risk policy list, and execution records based on the interception record, the compliance detection record, the policy conversion record, the issuance and execution record, and the device verification record.

[0085] In an alternative embodiment, the interception module 201 is further configured to: The reason for the violation is determined based on the ANY fully open rule entry or the cross-business domain unauthorized entry, the reason for the violation is marked in the interception record and fed back to the submitting terminal.

[0086] In one optional approach, the compliance audit is a mandatory audit node; if the firewall policy work order fails the compliance audit, it is prohibited from entering the policy generation stage; the compliance audit is passed when the security auditor completes the risk confirmation and approval of the risk item.

[0087] In one alternative embodiment, the detection module 202 is specifically used for: The identified risk items are displayed in a visually tiered manner, categorized into high security risk level, medium security risk level, and low security risk level; the risk items remain in this tiered display state until the compliance review is passed.

[0088] In one optional approach, the multi-vendor firewall instruction template library stores policy templates corresponding to various firewall brands; when converting to policy instructions adapted to the target firewall device, the corresponding policy template is matched from the multi-vendor firewall instruction template library according to the vendor information of the target firewall device for conversion.

[0089] In an alternative embodiment, the generation module 204 is specifically used for: After the distribution is completed, a device login session with the target firewall device is automatically established, and the current online operating policy of the target firewall device is read through the device login session.

[0090] In one optional approach, when comparing the online running policy with the policy instructions one by one, if the comparison reveals that there is a policy loss anomaly, a syntax error anomaly, or a configuration failure anomaly in the online running policy of the target firewall device, then an anomaly log is recorded and an alarm is issued. The exception log contains exception information corresponding to the policy loss exception, the syntax error exception, or the configuration failure exception; the device verification record contains the exception log.

[0091] It should be noted that the beneficial effects of the firewall closed-loop management system 200 with pre-blocking and configuration verification provided in the above embodiments are the same as those of the firewall closed-loop management method with pre-blocking and configuration verification, and will not be repeated here. Furthermore, the system provided in the above embodiments is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the system can be divided into different functional modules according to the actual situation to complete all or part of the functions described above. In addition, the system and method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process is detailed in the method embodiments, and will not be repeated here.

[0092] The firewall closed-loop management system 200 for pre-blocking and configuration verification of the present invention can be a computer program (including program code) running on a computer device. For example, the firewall closed-loop management system 200 for pre-blocking and configuration verification of the present invention is an application software that can be used to execute the corresponding steps in the firewall closed-loop management method for pre-blocking and configuration verification of the present invention.

[0093] In some embodiments, the firewall closed-loop management system 200 for pre-blocking and configuration verification of the present invention can be implemented in a combination of hardware and software. As an example, the firewall closed-loop management system 200 for pre-blocking and configuration verification of the present invention can be a processor in the form of a hardware decoding processor, which is programmed to execute the firewall closed-loop management method for pre-blocking and configuration verification of the present invention. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0094] The modules described in the embodiments of this invention can be implemented in software or hardware. The names of the modules are not, in some cases, limiting the scope of the module itself.

[0095] An electronic device according to an embodiment of the present invention includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements any of the aforementioned firewall closed-loop management methods for pre-interception and configuration verification. That is, an electronic device according to an embodiment of the present invention may include, but is not limited to: a processor and a memory; the memory is used to store the computer program; the processor is used to execute the firewall closed-loop management method for pre-interception and configuration verification shown in any embodiment of the present invention by calling the computer program.

[0096] In one alternative embodiment, an electronic device is provided, such as Figure 4 As shown, Figure 4 The illustrated electronic device 4000 includes a processor 4001 and a memory 4003. The processor 4001 and the memory 4003 are connected, for example, via a bus 4002. Optionally, the electronic device 4000 may further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one type, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of the present invention.

[0097] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this invention. Processor 4001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0098] Bus 4002 may include a path for transmitting information between the aforementioned components. Bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 4002 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 4 The bus 4002 is represented by only one thick line, but this does not mean that there is only one bus or one type of bus.

[0099] The memory 4003 may be ROM (Read Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto.

[0100] The memory 4003 stores application code (computer program) for executing the present invention, and its execution is controlled by the processor 4001. The processor 4001 executes the application code stored in the memory 4003 to implement the content shown in the foregoing method embodiments.

[0101] Among them, electronic devices can also be terminal devices. A terminal device can be any terminal device that can install applications and access web pages through applications, including at least one of smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, smart TVs, and smart in-vehicle devices.

[0102] It should be noted that, Figure 4 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0103] An embodiment of the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the aforementioned pre-interception and configuration verification firewall closed-loop management methods.

[0104] Alternatively, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, a floppy disk, and an optical data storage device, etc.

[0105] In an exemplary embodiment, a computer program product or computer program is also provided, which includes computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the aforementioned firewall closed-loop management method for pre-blocking and configuration verification.

[0106] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0107] It should be understood that the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of methods and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0108] The computer-readable storage medium provided in this invention can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0109] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the method shown in the above embodiments.

[0110] The above description is merely a preferred embodiment of the present invention and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.

[0111] It should be noted that the terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and represent a limitation on a specific order or sequence. Where appropriate, the order of use for similar objects can be interchanged so that the embodiments of this application described herein can be implemented in an order other than that shown or described.

[0112] Those skilled in the art will recognize that this invention can be implemented as a system, method, or computer program product. Therefore, this invention can be specifically implemented in the following forms: it can be entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software, generally referred to herein as a "circuit," "module," or "system." Furthermore, in some embodiments, this invention can also be implemented as a computer program product contained in one or more computer-readable media, which includes computer-readable program code.

[0113] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A firewall closed-loop management method for pre-blocking and configuration verification, characterized in that, include: Retrieve network asset topology domain data. If the firewall policy work order contains any fully open rule entries or cross-business domain unauthorized entries, then intercept the firewall policy work order and report the interception result. Generate an interception record based on the any fully open rule entries, the cross-business domain unauthorized entries, and the interception result. For firewall policy work orders that have passed the pre-interception, the security risk rule knowledge base is retrieved to identify risk permissions, the identified risk items are displayed in a hierarchical manner, and after compliance review is passed, the firewall policy work order is allowed to enter the policy generation stage to generate a compliance detection record. Read the standard fields in the firewall policy work order, match them with the multi-vendor firewall instruction template library, convert them into policy instructions adapted to the target firewall device, push the policy instructions to the target firewall device for execution, and generate policy conversion records and execution records. After the distribution is completed, log in to the target firewall device to read the current online running policy, compare the online running policy with the policy instructions one by one, record the abnormal log of the comparison failure and issue an alarm, and generate the device verification record; The interception record, compliance detection record, policy conversion record, issuance and execution record, and device verification record are pushed to the audit platform for storage. Based on the interception record, compliance detection record, policy conversion record, issuance and execution record, and device verification record, a policy change acceptance report, a risk policy list, and execution records are generated.

2. The firewall closed-loop management method for pre-interception and configuration verification according to claim 1, characterized in that, Following the step of intercepting the firewall policy work order, the following is also included: The reason for the violation is determined based on the ANY fully open rule entry or the cross-business domain unauthorized entry, the reason for the violation is marked in the interception record and fed back to the submitting terminal.

3. The firewall closed-loop management method for pre-interception and configuration verification according to claim 2, characterized in that, The compliance review is a mandatory review node; if the firewall policy work order fails the compliance review, it is prohibited from entering the policy generation stage; the compliance review is passed when the security reviewer completes the risk confirmation and approval of the risk item.

4. The firewall closed-loop management method for pre-interception and configuration verification according to claim 3, characterized in that, The steps for classifying and displaying identified risk items include: The identified risk items are displayed in a visually tiered manner, categorized into high security risk level, medium security risk level, and low security risk level; the risk items remain in this tiered display state until the compliance review is passed.

5. The firewall closed-loop management method for pre-interception and configuration verification according to claim 4, characterized in that, The multi-vendor firewall instruction template library stores policy templates corresponding to various firewall brands. When converting to policy instructions adapted to the target firewall device, the corresponding policy template is matched from the multi-vendor firewall instruction template library according to the vendor information of the target firewall device for conversion.

6. The firewall closed-loop management method for pre-blocking and configuration verification according to claim 5, characterized in that, The steps for logging into the target firewall device and reading the currently running online policies include: After the distribution is completed, a device login session with the target firewall device is automatically established, and the current online operating policy of the target firewall device is read through the device login session.

7. The firewall closed-loop management method for pre-blocking and configuration verification according to claim 6, characterized in that, When comparing the online running policy with the policy instructions one by one, if the online running policy of the target firewall device is found to have policy loss anomaly, syntax error anomaly, or configuration failure anomaly, an anomaly log is recorded and an alarm is issued. The exception log contains exception information corresponding to the policy loss exception, the syntax error exception, or the configuration failure exception; the device verification record contains the exception log.

8. A firewall closed-loop management system for pre-blocking and configuration verification, characterized in that, include: The interception module is used to retrieve network asset topology domain data. If the firewall policy work order contains any fully open rule entries or cross-business domain unauthorized entries, the firewall policy work order is intercepted and the interception result is fed back. An interception record is generated based on the any fully open rule entries, the cross-business domain unauthorized entries and the interception result. The detection module is used to retrieve the security risk rule knowledge base to identify risk permissions for the firewall policy work order that has passed the pre-interception, display the identified risk items in a hierarchical manner, and allow the firewall policy work order to enter the policy generation stage after the compliance review is passed, and generate a compliance detection record. The distribution module is used to read the standard fields in the firewall policy work order, match them with the multi-vendor firewall instruction template library, convert them into policy instructions adapted to the target firewall device, push the policy instructions to the target firewall device for execution, and generate policy conversion records and distribution execution records. The generation module is used to log in to the target firewall device after the distribution is completed, read the current online running policy, compare the online running policy with the policy instructions one by one, record the abnormal log of the comparison failure and issue an alarm, and generate the device verification record. The management module is used to push the interception records, compliance detection records, policy conversion records, issuance and execution records, and device verification records to the audit platform for storage, and to generate policy change acceptance reports, risk policy lists, and execution records based on the interception records, compliance detection records, policy conversion records, issuance and execution records, and device verification records.

9. An electronic device, characterized in that, The electronic device includes a processor coupled to a memory, the memory storing at least one computer program, which is loaded and executed by the processor to enable the electronic device to implement the firewall closed-loop management method of pre-blocking and configuration verification as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one computer program, which, when executed by a processor, implements the firewall closed-loop management method for pre-blocking and configuration verification as described in any one of claims 1 to 7.

Images