Financial network isolation control method and system based on service awareness

Abstract

The invention discloses a financial network isolation control method and system based on service awareness, and belongs to the technical field of communication networks. The method comprises the following steps: collecting features of a multi-dimensional network and a terminal to form a feature vector; identifying service types and levels by improving a weighted random forest model; carrying out risk assessment in combination with the business level and the real-time behavior to form a'business level and risk level 'two-tuple; taking the two-tuple as an input, and dynamically matching and generating differentiated isolation rules and flow control rules from a rule template library; when abnormity is detected, isolation and flow control instructions are synchronously generated and issued in parallel, and rule conflict detection and solution are carried out; and issuing the adjusted rule to a simulation verification environment for verification, and then deploying the rule to a production network. According to the invention, fine perception of the service state, real-time cooperative linkage of security isolation and flow control and validity verification before strategy deployment are realized, and the operation risk of a production network is remarkably reduced.

Description

Technical Field

[0001] This invention relates to the field of communication network technology, and more particularly to network security technology in the field of financial technology. Specifically, it relates to a business-aware financial network isolation control method and system. Background Technology

[0002] As the financial industry undergoes profound digital transformation, financial networks have become a critical infrastructure supporting core businesses such as real-time transactions, fund clearing, and customer information management. Their security, isolation, and traffic controllability are directly related to the continuity of financial operations and data security.

[0003] In existing technologies, some solutions attempt to dynamically adjust network security strategies through data awareness to cope with constantly changing business environments. For example, published patent CN119918066A proposes a risk management system and method based on multi-source data awareness. This solution constructs a risk profile of cloud hosts by collecting historical multi-source data (such as vulnerability scan records, intrusion detection logs, network traffic data, etc.). Simultaneously, it divides the network into security domains based on business functions and configures basic access control policies. Based on this, the system can perceive the resource usage of cloud hosts in real time and identify the current business status (such as peak and off-peak periods). Then, combined with the risk profile, it matches security policies from a preset policy library and dynamically adjusts network segmentation and access control policies based on micro-segmentation technology.

[0004] However, the inventors of this application discovered in the process of implementing the technical solution of this application that the prior art (such as CN119918066A) still has the following technical problems when actually applied to financial networks: 1. Coarse-grained business status identification, making it difficult to support refined management: Existing technologies mainly rely on cloud server resource usage and business logs to identify business status, typically only distinguishing between macro-level states such as "peak periods" and "off-peak periods." This coarse-grained identification method cannot accurately perceive the diverse and complex business types (such as real-time transactions, fund clearing, and office document transmission) in the financial network and their varying importance. This results in a lack of targeted adjustments to subsequent security strategies, making it difficult to meet the refined needs of financial businesses for focused protection of core operations and reasonable management of ordinary operations.

[0005] 2. Delayed Security Policy Adjustments and Lack of Real-Time Collaboration: While existing technologies enable dynamic adjustments to security domains based on business status, these adjustments are typically based on preset rules or periodic assessments, resulting in a certain degree of lag. When faced with sudden security incidents or abnormal fluctuations in business traffic, this delayed adjustment mechanism struggles to provide an immediate response. More critically, adjustments to isolation and traffic control policies are often independent, failing to achieve real-time collaboration and impacting the efficiency and timeliness of risk management.

[0006] 3. Security policies directly impact the production network, posing potential operational risks: Current technologies typically adjust policies by directly issuing and deploying the matched security policies to the production network. While this approach offers rapid response, it lacks a step for validating the policy's effectiveness and detecting conflicts. Newly generated policies may cause unexpected consequences in the production network due to misconfigurations, conflicts with existing policies, or insufficient consideration of complex business scenarios, posing a potential threat to the continuity and stability of the financial network.

[0007] Therefore, how to build a financial network security protection system that can more precisely perceive the status of financial business, achieve real-time collaborative linkage between security isolation and traffic control strategies, and effectively verify the strategies before deployment to reduce operational risks is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0008] To address the technical problems existing in the background art mentioned above, the present invention provides a business-aware financial network isolation control method and system, which aims to achieve refined perception of financial business status, real-time coordinated linkage of security isolation and traffic control, and effectiveness verification before policy deployment, thereby reducing the operational risks of production networks.

[0009] Firstly, this invention provides a business-aware financial network isolation control method. This method achieves refined and dynamic adjustment of financial network security strategies by constructing a closed-loop management process of "awareness-hierarchy-isolation-control-linkage-verification," specifically including the following steps: Step S1, Business Multi-Dimensional Perception and Feature Extraction: The intelligent collection gateway deployed at the edge of the financial network captures the raw traffic data entering and leaving the network in real time, and extracts network layer features, transport layer features and application layer features through deep packet inspection technology; at the same time, it collects the hardware fingerprint and network access status information of the access terminal to form a multi-dimensional feature vector containing network layer features, transport layer features, application layer features and terminal features. Step S2, Business Identification and Classification Based on Improved Weighted Random Forest: The multi-dimensional feature vector obtained in Step S1 is input into the pre-trained improved weighted random forest model. The model identifies business types, business entities, and access scenarios through a dynamic adjustment mechanism of sample weights and a tree splitting rule that fuses multi-source heterogeneous features. It outputs business identification results containing business identifiers, business entity identities, and access scenario categories. Subsequently, according to the preset business classification standards, combined with business importance and data sensitivity, the identified financial businesses are divided into three levels: core businesses, important businesses, and ordinary businesses, and a corresponding control priority is assigned to each level. Step S3, Risk assessment based on business classification: Based on the business classification results output in step S2, and combined with the business access behavior characteristics, real-time traffic characteristics and terminal information collected in step S1, the access risk of various businesses is assessed, and three levels of risk assessment results of high risk, medium risk and low risk are output; The business classification results and the risk assessment results are associated and stored to form a "business level-risk level" binary. Step S4, Dynamic isolation rule generation and deployment based on the rule template library: A rule template library is predefined, which includes at least the fields of rule identifier, trigger condition, execution action, priority, associated business level, and associated risk level; using the "business level-risk level" tuple output in step S3 as input, differentiated security isolation rules are dynamically matched and generated from the rule template library; the generated isolation rules are distributed to network devices such as firewalls and switches for deployment, realizing differentiated isolation strategies for core business separate isolation domains, important business dedicated isolation domains, and general business general isolation domains; Step S5, Generation and Deployment of Differentiated Traffic Control Rules Based on Business Priority: Based on the business priorities determined in Step S2 and the risk assessment results output in Step S3, differentiated traffic control rules are generated. These rules include: allocating fixed minimum bandwidth and dynamic elastic bandwidth to core services, allocating guaranteed bandwidth to important services, and limiting maximum bandwidth usage for ordinary services. Simultaneously, corresponding rate limiting thresholds are set for services with different risk levels; high-risk services have strict rate limiting thresholds, while low-risk services have lenient thresholds. The generated traffic control rules are then distributed to routers and traffic management devices for deployment. Step S6, Coordinated handling of isolation and traffic control: Real-time monitoring of traffic anomalies and security risk events in the network. When an anomaly or risk is detected, a coordinated linkage mechanism is triggered. Simultaneously, isolation rule adjustment instructions and traffic control rule adjustment instructions matching the anomaly event are generated, and the two instructions are sent in parallel to the corresponding network execution devices through message queues to ensure the synchronous adjustment of isolation policies and traffic control policies. Before the instructions are sent, real-time conflict detection is performed on the newly generated rules. When a rule conflict is detected, a hierarchical resolution mechanism combining preset priority and arbitration algorithm as a fallback is adopted to determine the final effective rule and execution parameters to avoid control failure caused by rule contradictions. Step S7, Strategy Simulation Verification and Closed-Loop Feedback: The security isolation rules and traffic control rules adjusted in Step S6 are first sent to a simulation verification environment isolated from the production network for verification. The simulation verification environment is a lightweight simulation network built based on container technology, used to simulate the device nodes, communication protocols, and business interaction logic of the production network. Access requests of different levels of business and different risk scenarios are simulated in the simulation environment to verify whether the new rules effectively block illegal access and whether they affect the collaboration of legitimate business. After the verification is passed, the rules are officially sent to the corresponding execution devices in the production network for deployment, and the verification results are fed back to the rule generation process as the basis for subsequent rule optimization.

[0010] As a preferred technical solution, the improved weighted random forest model described in step S2 has a sample weight dynamic adjustment mechanism that specifically includes: allocating initial weights based on the sample category distribution so that the sum of the weights of normal business samples and abnormal business samples is equal; iteratively updating the weights based on the misclassification cost, setting the cost weight for misclassifying abnormal business as normal business to be higher than the cost weight for misclassifying normal business as abnormal business; and expanding the abnormal samples by combining SMOTE oversampling, generating virtual abnormal samples, and then renormalizing the sample weights.

[0011] As a preferred technical solution, the improved weighted random forest model described in step S2 has the following tree splitting rules for multi-source heterogeneous feature fusion: for numerical features, the correlation weight between the feature and the business category is introduced to improve the information gain ratio, so that features with higher correlation receive higher splitting priority; for categorical features, the association weight between the category and the business category is introduced to improve the Gini coefficient, so that categories with higher correlation receive higher splitting weight; at the same time, an interaction term between numerical features and categorical features is introduced, wherein the weight of the interaction term is the product of the weights of the two corresponding basic features, and participates in the tree splitting calculation.

[0012] As a preferred technical solution, the step S4 of dynamically matching and generating differentiated security isolation rules from the rule template library specifically includes: extracting core parameters from the "business level-risk level" tuple output in step S3, wherein the core parameters include business type, risk level, terminal IP, business port and access frequency; simultaneously extracting business identifier, business subject and access scenario information; automatically filling the extracted parameters into the trigger conditions and execution action parameters of the matched rule template to generate personalized rules; and automatically triggering rule updates and adjusting the trigger conditions, execution actions or priorities of the rules when the business perception results change or the business enters a peak period.

[0013] As a preferred technical solution, the real-time conflict detection of the newly generated rules in step S6 specifically includes: performing structured parsing on the input rules to extract the core features of the rules, including the control target, the type of execution action, and the range of action parameters; establishing a rule feature association matrix and comparing the feature vector of the new rule with the feature vector of the existing effective rules one by one; when the control targets overlap, the execution actions contradict each other, or the action parameters conflict, it is determined to be a rule conflict; the rule conflict includes at least three types: action conflict, parameter conflict, and range conflict.

[0014] As a preferred technical solution, the hierarchical resolution mechanism combining preset priority and arbitration algorithm as a fallback in step S6 specifically includes: for action conflicts and scope conflicts, calculating the priority score of the conflict rules, the priority score is calculated based on the risk level score, business level score and rule priority score, and the rule with the higher score takes precedence; for parameter conflicts and conflicts with the same priority score, using an arbitration algorithm to calculate the comprehensive score of the rules, the comprehensive score is calculated based on the impact scope score and business adaptability score, and the rule parameter with the best comprehensive score is selected as the final execution parameter.

[0015] As a preferred technical solution, the simulation verification environment in step S7 is a lightweight simulation network built based on container technology. The container includes a soft PLC container image, a Modbus protocol server image, an HMI simulation container, and a sensor data source simulation container. Each container has a built-in corresponding industrial control protocol stack and data interaction service.

[0016] Secondly, the present invention provides a business-aware financial network isolation control system. The system adopts a modular architecture design corresponding to the method described in the first aspect, with each module interacting with the others and transmitting instructions through standardized interfaces. Specifically, it includes the following modules: The business perception module, as the data input front end of the system, is used to perform the function of step S1. It includes an intelligent acquisition gateway deployed at the boundary of the financial network and a perception data processing unit connected to the intelligent acquisition gateway. The intelligent acquisition gateway is used to capture traffic data entering and leaving the network in real time, extract network layer features, transport layer features and application layer features through deep packet inspection technology, and collect the hardware fingerprint and network access status information of the access terminal. After forming a multi-dimensional feature vector, it is transmitted to the perception data processing unit. The business identification and classification module, connected to the business perception module, is used to perform the function of step S2. It has an improved weighted random forest model built in, which identifies business types, business subjects and access scenarios through tree splitting rules that dynamically adjust sample weights and fuse multi-source heterogeneous features. It also classifies the identified businesses according to preset standards and outputs the business classification results. The risk assessment module is connected to the business perception module and the business identification and classification module respectively. It is used to perform the function of step S3, receive the business classification result and the real-time data collected by the business perception module, assess the access risk of various businesses, and output a "business level - risk level" tuple. The dynamic isolation module, connected to the risk assessment module, is used to perform the function of step S4, and includes a rule template library unit, a dynamic rule generation unit, and an isolation rule execution unit. The rule template library unit stores predefined security policy rule templates. The dynamic rule generation unit takes a "business level-risk level" tuple as input, dynamically matches and generates differentiated isolation rules from the rule template library. The isolation rule execution unit distributes the generated isolation rules to network devices for deployment. The traffic control module, connected to the risk assessment module, is used to perform the functions of step S5, including a bandwidth allocation unit, a rate limiting threshold setting unit, and a traffic rule execution unit; the bandwidth allocation unit allocates differentiated bandwidth to core, important, and ordinary services according to service priority; the rate limiting threshold setting unit sets corresponding rate limiting thresholds according to risk level; and the traffic rule execution unit distributes the generated traffic control rules to the traffic management equipment for deployment. The collaborative linkage module, connected to both the dynamic isolation module and the traffic control module, is used to execute the function of step S6. It includes a rule collaboration unit, a risk linkage handling unit, and a policy conflict detection and resolution unit. When the rule collaboration unit detects abnormal traffic or security risks, it simultaneously generates isolation rule adjustment instructions and traffic control rule adjustment instructions, and sends them out in parallel through a message queue. The risk linkage handling unit is used to coordinate with firewalls and intrusion detection devices to achieve risk blocking. The policy conflict detection and resolution unit performs real-time conflict detection on the adjusted rules and uses a hierarchical resolution mechanism combining preset priority and arbitration algorithm as a fallback to determine the final effective rule. The simulation verification platform, connected to the collaborative linkage module, is used to execute the function of step S7. It is a lightweight simulation network environment built based on container technology, used to simulate the device nodes, communication protocols and business interaction logic of the production network, and to verify the effectiveness and detect conflicts of the adjusted security isolation rules and flow control rules. The operation and maintenance supervision module is connected to each of the above modules and is used to provide full-process visualized operation and maintenance and supervision adaptation functions. It includes a visualized operation and maintenance unit, a log traceability unit, and a supervision adaptation unit. The visualized operation and maintenance unit is used to display business identification results, business classification, isolation rules, traffic status, and risk handling status in real time. The log traceability unit is used to record the entire risk handling process. The supervision adaptation unit is used to generate supervision reporting reports.

[0017] As a preferred technical solution, the dynamic isolation module further includes an isolation verification unit connected to the simulation verification platform. This unit is used to verify the isolation effect through the simulation verification platform after the isolation rules are deployed, so as to ensure that the isolation rules effectively block unauthorized access without affecting legitimate business collaboration.

[0018] As a preferred technical solution, the system further includes a policy library management module, which is connected to the dynamic isolation module, the traffic control module and the collaborative linkage module respectively, for unified management of the rule template library, and supports rule classification, version control and dynamic updates.

[0019] Compared with existing technologies, this invention constructs a complete technology chain from data acquisition, feature processing, strategy generation, instruction execution to deployment verification through a progressive design of steps S1 to S7. The steps are interconnected through clear data transfer relationships and logical dependencies, giving the technical solution of this invention significant integration and synergy. Specific beneficial effects are analyzed as follows: First, the progressive processing from steps S1 to S3 gradually transforms the original multidimensional data into decision-making basis with business semantics, solving the problem of single perception dimension and coarse recognition in existing technologies, and providing accurate and unified input for subsequent steps.

[0020] Existing technologies primarily rely on cloud server resource usage and business logs to identify business status. Their data sources are limited to the system resource level, resulting in a single dimension of perception. They typically only distinguish macro-level states such as "peak periods" and "off-peak periods," making it difficult to support refined management needs. This invention, through a progressive design of steps S1 to S3, constructs a complete transformation chain from raw data to decision-making basis.

[0021] Step S1 involves deploying an intelligent data acquisition gateway. This gateway uses deep packet inspection (DIP) technology to simultaneously extract network layer features, transport layer features, and application layer features. It also collects the hardware fingerprint and network access status information of the access terminals, forming a multi-dimensional feature vector containing these four types of features. These four types of features are not simply superimposed but form a mutually corroborating data system: network layer features determine the basic connection relationship between the communicating parties; transport layer features characterize the transmission mode of business traffic; application layer features carry specific semantic information related to financial services; and terminal features identify the legitimacy and type of the access device. These four types of features collectively characterize the same business flow from different dimensions, enabling subsequent processing to make decisions based on a complete data view.

[0022] Step S2 inputs the multi-dimensional feature vectors into an improved weighted random forest model. This model addresses the data imbalance problem caused by scarce abnormal samples through a dynamic adjustment mechanism for sample weights. It also mines the correlation value between features of different dimensions through tree splitting rules that fuse multi-source heterogeneous features, outputting accurate identification results including business type, business entity, and access scenario. Based on business importance, it categorizes businesses into three levels: core, important, and ordinary. Step S3, based on the business classification, combines business access behavior characteristics, real-time traffic characteristics, and terminal information to conduct a risk assessment, forming a "business level - risk level" binary pair.

[0023] The key technical advantage of the aforementioned progressive processing lies in the fact that the multidimensional features collected in step S1, after being identified and graded in step S2 and risk assessed in step S3, are no longer isolated values ​​or labels, but rather decision-making criteria carrying the dual attributes of "whether the business is important" and "whether the current access is dangerous." The "business level - risk level" tuple, as the common output of the first three steps, encapsulates both the importance attribute of the business and its real-time risk status, providing a unified and standardized input for subsequent steps S4 and S5. This design ensures clear semantic consistency and format standardization in the information transmission from data collection to policy generation, allowing subsequent steps to make policy decisions directly based on this tuple without repeatedly processing the original data.

[0024] Second, steps S4 and S5 are executed in parallel with the same "business level-risk level" tuple as input, so that isolation rules and flow control rules are generated synchronously based on the same decision basis, realizing the synergy of the two types of strategies at the generation source.

[0025] Based on the "Business Level - Risk Level" tuple output in step S3, steps S4 and S5 are executed in parallel using the same tuple as input. Step S4 dynamically matches and generates differentiated security isolation rules from a predefined rule template library; step S5 simultaneously generates differentiated traffic control rules, allocating fixed minimum bandwidth and dynamic elastic bandwidth to core services, allocating guaranteed bandwidth to important services, limiting maximum bandwidth usage for ordinary services, and setting corresponding flow limiting thresholds for different risk levels.

[0026] The technical advantage of "parallel execution with the same input" here is that both types of strategies are generated based on the exact same decision-making criteria, ensuring that isolation rules and flow control rules have a consistent understanding and handling intent for the same business flow. For high-risk access to a core business, isolation rules isolate it to a restricted area, while flow control rules simultaneously set strict flow-limiting thresholds. For low-risk access to a common business, isolation rules allow it to communicate within a general isolation domain, while flow control rules limit its maximum bandwidth usage. Both types of strategies maintain a collaborative understanding of the same business from the generation source, avoiding the shortcomings of traditional solutions where isolation rules and flow control rules operate independently based on different decision logics.

[0027] Third, step S6, through the close connection of three links—synchronous instruction generation, parallel distribution, and rule conflict verification—ensures that the isolation strategy and the flow control strategy can take effect simultaneously and remain consistent when risks occur, thus achieving real-time collaboration at the execution level.

[0028] The strategies generated in steps S4 and S5 are executed in step S6. When abnormal traffic or security risks are detected, step S6 triggers a collaborative mechanism: simultaneously generating isolation rule adjustment instructions and traffic control rule adjustment instructions matching the abnormal event; sending the two instructions in parallel to the corresponding network execution devices through message queues; before sending the instructions, real-time conflict detection is performed on the newly generated rules; when a rule conflict is detected, a hierarchical resolution mechanism combining preset priority and arbitration algorithm as a fallback is adopted to determine the final effective rules and execution parameters.

[0029] The three interconnected stages form a complete execution collaboration chain: "Synchronous generation" in the instruction generation stage ensures that two instructions are generated simultaneously based on a unified understanding of the same abnormal event, rather than generating isolation instructions first and then traffic instructions based on the isolation results, or vice versa; "Parallel issuance" in the instruction issuance stage ensures that two instructions arrive at the execution device approximately simultaneously, avoiding time differences caused by serial issuance; and "Conflict detection and resolution" in the rule verification stage ensures internal consistency of the issued rules, avoiding control failures or policy fluctuations caused by rule contradictions. These three stages are interdependent, enabling the isolation strategy and traffic control strategy to take effect simultaneously and remain consistent at the moment a risk occurs, forming a real-time protective synergy of "isolation + control," significantly improving the efficiency and accuracy of risk handling.

[0030] Fourth, step S7, through the closed-loop design of "generation-verification-deployment-feedback", ensures that all strategy adjustments must be verified through simulation before entering the production network, and feeds back the verification results to the rule generation process, thus forming a risk control barrier and continuous optimization mechanism before deployment.

[0031] The final rules determined in step S6 will proceed to the deployment and verification phase in step S7. Step S7 will first distribute the adjusted security isolation rules and traffic control rules to a simulation verification environment isolated from the production network for verification. This simulation verification environment is a lightweight simulation network built on container technology, used to simulate the device nodes, communication protocols, and business interaction logic of the production network. Access requests from different levels of business and different risk scenarios will be simulated in the simulation environment to verify whether the new rules effectively block unauthorized access and whether they affect legitimate business collaboration. Only after successful verification will the rules be officially distributed to the corresponding execution devices in the production network for deployment, and the verification results will be fed back to the rule generation process as a basis for subsequent rule optimization.

[0032] The above mechanism forms a complete closed loop of "generation-verification-deployment-feedback". The first closed loop is formed between the "generation" stage (steps S4-S5) and the "verification" stage (step S7): generated rules must be verified before deployment. The second closed loop is formed between the "verification" stage and the "feedback" stage: verification results are fed back to the rule generation process for subsequent rule optimization. The third closed loop is formed between the "deployment" stage and the "generation" stage: the actual effect after deployment can serve as input for rule generation. These three nested closed loops ensure that every strategy adjustment is fully verified, effectively avoiding the risk of business interruption due to rule errors or conflicts. Simultaneously, the rule generation process can be continuously optimized based on verification feedback, forming an adaptive strategy evolution capability.

[0033] Fifth, steps S1 to S7 are interconnected through clear input-output relationships and logical dependencies, forming a complete technical system from raw data to final strategy execution. The improvements in each step are superimposed through data transmission, resulting in an overall technical effect of 1+1>2.

[0034] The steps described above are not isolated, but are interconnected through explicit input-output relationships and logical dependencies, forming a complete technology chain: The multidimensional feature vector output in step S1 is directly used as the input to step S2; the business classification result output in step S2 and the real-time data collected in step S1 are used together as the input to step S3; the "business level-risk level" tuple output in step S3 is used as the input to both steps S4 and S5; the policy rules generated in steps S4 and S5 are used together as the input to step S6; the final rule determined in step S6 is used as the input to step S7; the verification result of step S7 is fed back to the rule generation process of steps S4 and S5.

[0035] This chain-like design gives the technical solution of this invention a significant integrated feature: the initial step S1 provides the data foundation for subsequent steps; steps S2 and S3 realize the transformation from data to decision-making basis; steps S4 and S5 generate an integrated strategy based on a unified decision-making basis; step S6 ensures real-time collaboration in the strategy execution stage; and step S7 guarantees the security, controllability, and continuous optimization of strategy deployment. Improvements in any step will affect subsequent steps through data transmission, and defects in any step will be compensated for or verified by subsequent steps, forming a progressive and interconnected technical whole. Attached Figure Description

[0036] Figure 1 The main flowchart of the business-aware financial network isolation control method of this invention; Figure 2 : Figure 1 Sub-flowchart of step S2 (service identification and classification based on improved weighted random forest); Figure 3 : Figure 1 Collaborative flowchart for steps S4 and S5 (dynamic isolation and flow control rule generation); Figure 4 : Figure 1 Sub-flowchart for step S6 (Collaborative and Joint Handling); Figure 5 : Figure 1 Flowchart of step S7 (Simulation verification and closed-loop feedback of the strategy); Figure 6 This invention presents a business-aware financial network isolation control system module architecture diagram. Detailed Implementation

[0037] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. The specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of protection of this invention in any way.

[0038] Glossary To facilitate understanding of the technical solution of this invention, several technical terms appearing in this document are first defined and explained as follows: Business Identifier: A standardized code used in financial networks to uniquely identify the type of financial business and transaction scenario. It adopts a hierarchical, fixed-length coding format combining numbers and letters. The coding structure includes three parts: a business category code, a business sub-category code, and a scenario channel code. It is uniformly assigned by financial institutions or financial alliances according to industry standards and has the characteristics of uniqueness, fixedness, and scalability. For example, "0101W001" represents a personal online banking mobile transaction, where "01" is the real-time fund transaction category, "01" is the personal online banking sub-category, and "W001" is the mobile channel.

[0039] Terminal fingerprint: refers to a composite set of features used to uniquely identify a financial network access terminal, generated using a hybrid approach of primary hardware fingerprint and secondary software fingerprint. The core hardware fingerprint includes the device's physical MAC address, device serial number, motherboard serial number, and the encryption chip number for financial-specific equipment. The secondary software fingerprint includes the terminal's network access authentication number, operating system type and version number, and browser or business client identifier. Upon initial access, the network access system automatically collects these features and generates a 64-bit fixed-length terminal fingerprint hash value using the SM3 hash algorithm, serving as the terminal's unique identifier.

[0040] Message characteristics refer to the inherent set of characteristics of application-layer messages in financial transactions during network transmission, divided into general basic characteristics and financial-specific core characteristics. General basic characteristics include fixed field lengths and positions, protocol encapsulation formats, and data encoding formats; financial-specific core characteristics include business identification fields, business entity association fields, financial transaction characteristic fields, and institution-specific feature codes. Message characteristics are extracted by the business identification module at the network application layer, bypassing the encapsulation and parsing of the network and transport layers.

[0041] Traffic shaping refers to the technical means of smoothing and rate limiting various business traffic in financial networks through standardized traffic scheduling algorithms, using a combination of token bucket and leaky bucket algorithms. The token bucket algorithm is used for core and important financial businesses, allowing for traffic bursts; the leaky bucket algorithm is used for ordinary businesses and cross-institutional non-core businesses, strictly limiting the traffic output rate. The shaping granularity is refined based on business identifiers, rather than traditional shaping based on ports or IP addresses.

[0042] Multi-dimensional fusion identification method: This refers to a technical approach that integrates four feature dimensions—network layer features, transport layer features, application layer features, and terminal features—and uses an improved weighted random forest model to accurately identify financial transactions. Network layer features include source IP address, destination IP address, port number, and protocol number; transport layer features include packet length distribution and session duration; application layer features include HTTP user agent and financial transaction code; and terminal features include terminal fingerprint and network access status. The fusion algorithm employs feature importance evaluation based on information gain ratio, dynamically allocates weights for each dimension, and outputs the identification results through a voting mechanism.

[0043] The improved weighted random forest model refers to a machine learning model that improves upon the conventional weighted random forest model in two aspects for financial business identification scenarios. The first improvement is a dynamic sample weight adjustment mechanism, which dynamically allocates sample weights based on SMOTE oversampling and sample misclassification costs, thereby increasing the identification weight of abnormal samples. The second improvement is a tree splitting rule based on multi-source heterogeneous feature fusion, which designs differentiated splitting criteria for numerical and categorical features respectively, and introduces feature interaction terms to participate in tree splitting calculations.

[0044] Rule Template Library: This refers to a database that stores predefined security policy rule templates. The template format includes six core fields: rule identifier, trigger condition, execution action, priority, associated business level, and associated risk level. The rule templates are designed based on financial industry compliance requirements and common business scenarios, and can be dynamically updated and maintained. They support rule categorization, version control, and dynamic adaptation.

[0045] Micro-segmentation technology refers to the technique of dividing a cloud host network into multiple fine-grained security domains. Resources within each security domain are isolated from each other. By monitoring cross-security domain traffic in real time, abnormal traffic is identified and blocked, ensuring that resource access within each security domain complies with preset security policies. Micro-segmentation technology supports dynamic adjustment of security domain division and access control policies based on changes in business needs and security risks.

[0046] Simulation verification environment: This refers to a lightweight simulation network environment physically isolated from the production network. Built using container technology, it simulates the device nodes, communication protocols, and business interaction logic of the production network. The simulation verification environment includes a soft PLC container image, a Modbus protocol server image, an HMI simulation container, and a sensor data source simulation container. Each container has a built-in corresponding industrial control protocol stack and data interaction services.

[0047] Example 1: Implementation of a Business-Aware Financial Network Isolation Control Method This embodiment provides a business-aware financial network isolation control method, such as... Figure 1As shown, the method achieves refined and dynamic adjustment of financial network security strategies by constructing a closed-loop management process of "perception-grading-isolation-control-linkage-verification".

[0048] Step S1: Multi-dimensional business perception and feature extraction Intelligent data acquisition gateways deployed at the boundary of financial networks capture raw traffic data entering and leaving the network in real time. These gateways support port mirroring, optical splitter access, or transparent bridge deployment modes, and are compatible with existing financial network topologies. Taking a commercial bank as an example, an intelligent data acquisition gateway is deployed between its core switch and the internet egress to capture all traffic entering and leaving the data center in real time.

[0049] Deep packet inspection (DIP) technology is used to perform protocol parsing and feature extraction on captured traffic data. Specifically, this includes: extracting network layer features, which include source IP address, destination IP address, source port number, destination port number, and protocol number; extracting transport layer features, which include packet length distribution, session duration, and average interval between packets; and extracting application layer features, which include the location and value of HTTP user agent, financial transaction code, and business identifier fields.

[0050] Simultaneously, the hardware fingerprint and network access status information of the access terminal are collected. The hardware fingerprint includes the device's physical MAC address, device serial number, motherboard serial number, and encryption chip number for financial special equipment; the network access status information includes the terminal's network access authentication number, the department code to which the terminal belongs, and the current network access status. Taking a corporate customer initiating an online banking transaction through an office terminal as an example, the intelligent data collection gateway collects the terminal's MAC address as "00:1A:2B:3C:4D:5E", motherboard serial number as "SN123456789", and network access authentication number as "EMP-2025-00123".

[0051] The collected data is integrated into a multidimensional feature vector, which is represented as follows:

[0052] in, Represents the feature set of the network layer. Represents the transport layer feature set. Represents the application layer feature set. This represents the terminal feature set. For the above example of corporate online banking transactions, the specific values ​​of its multidimensional feature vector are: source IP = 10.10.1.100, destination IP = 172.20.1.50, source port = 54321, destination port = 443, protocol number = 6 (TCP), message length = 512 bytes, session duration = 350ms, packet interval = 25ms, HTTP user agent is "Mozilla / 5.0 (Windows NT10.0; Win64; x64)", financial transaction code is "TRX2025031800012345", and terminal fingerprint hash value is "7A3F8B2C1D9E4F5A6B7C8D9E0F1A2B3C".

[0053] Step S2: Service identification and classification based on improved weighted random forest The multidimensional feature vector obtained in step S1 is input into the pre-trained improved weighted random forest model, such as... Figure 2 As shown, the model accurately identifies business types, business entities, and access scenarios through a dynamic adjustment mechanism for sample weights and a tree splitting rule that integrates multi-source heterogeneous features.

[0054] The specific implementation of the improved weighted random forest model is as follows: (a) Dynamic adjustment mechanism of sample weights Let the financial transaction identification sample set be... ,in, For the first Multidimensional feature vectors of each sample (0 represents normal business, 1 represents abnormal business), the total number of samples is The normal sample size is The number of abnormal samples is ( ).

[0055] Taking a financial institution as an example, its daily transaction log sample set contains 10,000 samples, including 9,800 samples from normal business transactions and 200 samples from abnormal business transactions. The initial weight allocation is as follows: Normal business sample:

[0056] Abnormal business sample:

[0057] The initial weights of abnormal business samples are approximately 49 times that of normal business samples, ensuring that the model gives sufficient attention to a small number of abnormal samples.

[0058] (1) Initial sample weight allocation: Based on the sample category distribution, the initial weight calculation formula is as follows:

[0059] This allocation method ensures that the total weights of normal samples and abnormal samples are equal, thus preventing the model from being biased towards normal samples.

[0060] (2) Weight update based on misclassification cost: Let the misclassification cost matrix be... ,in This indicates that the real category is... Sample misclassification The cost of misclassifying abnormal business transactions as normal business transactions is far greater than the cost of misclassifying normal business transactions as abnormal business transactions in financial scenarios.

[0061] In this embodiment, the value of the misclassification cost matrix is ​​determined based on the risk tolerance of the financial business: abnormal business ( It was mistakenly identified as normal business activity. This could lead to financial losses or security incidents, therefore a higher cost is set; misjudging normal business as abnormal only incurs manual review costs, therefore a lower cost is set. Based on this principle, we take... , , It should be noted that the above-mentioned costs can be adjusted according to the risk appetite of different financial institutions; risk-averse institutions can increase them. Organizations with high business continuity requirements may appropriately reduce their requirements to 15 or 20. The values ​​are all up to 0.5, but all are within the protection scope of this invention.

[0062] After each iteration, the sample weight update formula is:

[0063] in, For the first Samples in round iteration Prediction categories, For the first The classification error rate of each iteration is calculated using the following formula: , This is an indicator function.

[0064] In the first iteration, a certain abnormal business sample (real category) A fraudulent transaction initiated by an illegal terminal was misclassified by the model as a normal business transaction (prediction category). The cost of misclassification for this sample is... The classification error rate in this round The weights of this sample are updated as follows:

[0065] The sample weight was increased from 0.005 to 0.00681, an increase of approximately 36.2%, which led to greater attention being paid to it in subsequent iterations.

[0066] (3) SMOTE oversampling-assisted optimization: SMOTE oversampling is applied to abnormal samples to generate virtual abnormal samples. After oversampling, the sample weights are renormalized to ensure that the sum of the weights is 1.

[0067] in, The number of virtual anomaly samples generated, with a value of [value]. This ensures that the number of normal samples and abnormal samples are consistent after oversampling.

[0068] Taking the aforementioned misclassified sample as an example, a new sample is generated by random interpolation among its nearest neighbors in the feature space. The message length feature value of this sample is 512 bytes, and the message length of a certain nearest neighbor sample is 528 bytes. Therefore, the message length feature value of the generated new sample is... ,in A random number between [0, 1]. If the value is 0.3, then the length of the new sample message is 512 + 0.3 × 16 = 516.8 ≈ 517 bytes. This method generates 200 virtual abnormal samples, bringing the total number of abnormal samples to 400. The ratio of abnormal samples to normal samples is adjusted to 9800:400 ≈ 24.5:1, effectively alleviating the data imbalance problem.

[0069] (II) Tree splitting rules for multi-source heterogeneous feature fusion Input features are divided into two categories: numerical features. (such as message length, transmission delay, access frequency) and category characteristics (Such as service identifier, terminal fingerprint, protocol type).

[0070] (1) Numerical feature splitting rule: Introduce the correlation weight between features and business categories. Improved information gain rate The calculation formula is:

[0071] in, For conventional information gain, For sample set Entropy; For split information; The feature relevance weights are calculated from the Pearson correlation coefficient: The higher the relevance, the greater the weight.

[0072] Taking the "message length" feature as an example, calculate its improved information gain ratio. Let the entropy H(D) of the sample set D be 0.95, and the weighted sum of the entropies of the subsets after partitioning by message length be 0.62. Then, the information gain IG = 0.95 - 0.62 = 0.33. Split information SplitInfo = 1.25. The Pearson correlation coefficient between message length and business category is also calculated. =0.78 (indicating that message length is highly correlated with whether the transaction is abnormal, such as some fraudulent transactions with abnormally long messages). Therefore, the improved information gain ratio is:

[0073] (2) Categorical feature splitting rule: Introduce category association weights After improvement coefficient The calculation formula is:

[0074] in, For category With business category The association weights are calculated using mutual information. The higher the correlation, the greater the weight.

[0075] Taking the "business identifier" feature as an example, calculate its improvement. Coefficients. Business identifier values ​​include 0x0001 (personal online banking), 0x0002 (corporate clearing), and 0x0003 (corporate batch transfers). The distribution ratio of each value in the sample set is: 0x0001 60%, 0x0002 25%, and 0x0003 15%. The association weight is calculated based on the mutual information between each value and the abnormal business category. They are respectively: (0x0001) = 0.2 (0x0002) = 0.3 (0x0003) = 0.9 (This indicates a high correlation between the company's bulk transfer transactions and abnormal transactions, requiring close monitoring). Therefore, improvements are needed. The coefficient is:

[0076] Because the business identifier 0x0003 has a high association weight of 0.9 with abnormal business, this feature receives high priority during splitting, enabling the model to quickly identify the key type of enterprise bulk transfer business.

[0077] (3) Feature Interaction Term Fusion: Interaction terms of numerical and categorical features are introduced (such as "service identifier × transmission delay" and "terminal fingerprint × access frequency") to capture the synergistic effect generated by the combination of features of different dimensions. The construction of interaction terms adopts the multiplication of indicator functions, that is, for each possible value k of the categorical feature, an interaction feature of the form X_num × I (X_cat = k) is constructed, where I(·) is the indicator function (takes a value of 1 when the category is equal to k, otherwise it is 0). The feature weight of the interaction term is the product of the weights of the two corresponding basic features, which participates in the tree splitting calculation:

[0078] Taking the "Business Identifier × Access Frequency" interaction item as an example, let the business identifier be a categorical feature, with values ​​including 0x0001 (personal online banking), 0x0002 (corporate clearing), and 0x0003 (corporate batch transfer). For business identifier 0x0003, construct the interaction item feature: Access Frequency × I(Business Identifier = 0x0003). When the access frequency of a certain business flow's corporate batch transfer business (business identifier = 0x0003) is 120 times / minute, the interaction item feature value = 120 × 1 = 120; when the business flow is another business type (such as business identifier = 0x0001), the interaction item feature value = 120 × 0 = 0. This interaction item participates in the tree splitting calculation, enabling the model to identify the specific pattern of "high-frequency access to corporate batch transfer business," distinguishing it from high-frequency access to other business types. The interaction item weight is calculated as the product of the numerical feature weight and the categorical feature weight, participating in the feature importance evaluation during tree splitting.

[0079] Suppose the numerical encoding of service identifier 0x0003 is 3 (mapped after One-Hot encoding), the access frequency is 120 times / minute, and the numerical feature weight is... Categorical feature weights Then the interaction item weight .

[0080] (III) Overall output logic of the model The improved weighted random forest consists of T decision trees, each trained on a weighted sample set. Tree splitting follows the improved splitting rule described above. The final output uses a weighted voting mechanism, where each tree's voting weight is its classification accuracy, expressed as:

[0081] in, For the first The prediction results of each decision tree; For the first The weights of each decision tree are calculated using the following formula: The higher the classification accuracy, the greater the voting weight.

[0082] Suppose the improved weighted random forest consists of 128 decision trees. For the above sample of batch transfers by enterprises, the distribution of prediction results for each decision tree is as follows: 98 trees predict it as a normal transaction (…). 30 trees were predicted as abnormal business activity. The weights of each decision tree. Based on their classification accuracy, trees with higher accuracy have larger weights. Assuming the cumulative weight of the 98 normal prediction trees is 0.75 and the cumulative weight of the 30 abnormal prediction trees is 0.25, the final output will be:

[0083] The model determines that the company's bulk transfer business is a normal business, which is consistent with the actual situation.

[0084] The model outputs business identification results, including business type (such as real-time transaction, fund clearing, customer information management, credit approval, regulatory reporting, office document transmission), business entity identity (legitimate user terminal, illegal access terminal, registered enterprise customer, individual customer), and access scenario category (internal network access, external network access, cross-institutional access).

[0085] Subsequently, based on pre-defined business classification standards and considering both business importance and data sensitivity, the identified financial businesses were categorized into three levels: core businesses, important businesses, and ordinary businesses. Core businesses include real-time transactions and fund clearing; important businesses include customer information management and credit approval; and ordinary businesses include office document transmission and internal communication. A corresponding control priority was assigned to each level, with core businesses having the highest priority, followed by important businesses, and ordinary businesses having the lowest priority. The aforementioned enterprise bulk transfer business was identified as a core business.

[0086] Step S3, Risk assessment based on business classification Based on the service classification results output in step S2, and combined with the service access behavior characteristics, real-time traffic characteristics, and terminal information collected in step S1, the access risks of various services are assessed.

[0087] The risk assessment employs a multi-factor comprehensive scoring model. Assessment factors include: abnormal access behavior (e.g., access during non-business hours, login via uncommon terminals), abnormal traffic characteristics (e.g., sudden increase in access frequency, abnormal message length), and terminal trustworthiness (whether the terminal fingerprint matches, whether the network access status is normal). The comprehensive score is calculated as follows:

[0088] Where A represents the access behavior anomaly score (range 0-100, the lower the score, the more normal), F represents the traffic characteristic anomaly score (0-100), and T represents the terminal credibility score (0-100, the lower the score, the more credible). Let be the weight coefficients of each factor, satisfying .

[0089] In this embodiment, the weighting coefficients are determined based on the contribution of each factor to the risk of financial business: abnormal access behavior directly reflects attack intent, so it is given a higher weight; abnormal traffic characteristics may be caused by network fluctuations, so the weight is moderate; terminal trustworthiness, as a basic authentication method, has a relatively low weight. Based on this principle, the following is selected: , , It should be noted that the above weighting coefficients can be adjusted according to different business scenarios. For example, the terminal credibility weight can be increased to 0.35 for remote access scenarios, and the access behavior anomaly weight can be increased to 0.5 for core transaction scenarios, but all of these are within the protection scope of this invention.

[0090] Taking the aforementioned bulk transfer business of enterprises as an example, the risk assessment calculation is as follows: Access Behavior Anomaly Level A: This business occurred at 10:00 AM on a weekday (normal time period), and the terminal was a registered enterprise terminal. The access behavior anomaly level score A = 10 points (calculated based on the behavior baseline model, with deviation below the threshold).

[0091] Traffic anomaly score F: Access frequency 120 times / minute (below the threshold of 150 times / minute), message length stable at 512±10 bytes, traffic anomaly score F=15 points.

[0092] Terminal trustworthiness T: The terminal fingerprint matches the filing record and the network access status is normal. The terminal trustworthiness score T = 5 points.

[0093] The overall risk score is as follows:

[0094] The risk assessment results are divided into three levels: high risk, medium risk, and low risk. The threshold for these levels is set based on the risk tolerance of financial institutions.

[0095] In this embodiment, the threshold setting principle is as follows: high risk corresponds to serious threats that must be blocked immediately (such as DDoS attacks and unauthorized access), medium risk corresponds to suspicious behaviors that need to be monitored, and low risk corresponds to normal or minor anomalies.

[0096] Based on historical data statistics and expert experience, a high-risk threshold of 60 and a medium-risk threshold of 30 are set. That is: If the RiskScore is ≥ 60, the risk level is high. If 30 ≤ RiskScore < 60, then the risk level is medium risk; If RiskScore < 30, the risk level is low.

[0097] It should be noted that the above thresholds can be adjusted according to the actual risk tolerance of financial institutions. For example, the high-risk threshold can be appropriately lowered to 50 for core business and raised to 70 for ordinary business, but these are all equivalent variations of the present invention.

[0098] In this example, RiskScore = 10.5 < 30, so the risk level is low.

[0099] The business classification results are associated and stored with the risk assessment results to form a "business level - risk level" tuple, represented as:

[0100] in, , The above examples form a pair. This serves as the basis for subsequent dynamic isolation and flow control decisions.

[0101] Figure 3 This demonstrates the parallel processing of security isolation rules and traffic control rules generated by the dynamic isolation module and the traffic control module respectively from the rule template library, using the "business level-risk level" tuple as a common input. Details of the two parallel processes are provided in steps S4 and S5 below.

[0102] Step S4: Dynamic isolation rule generation and deployment based on the rule template library A predefined rule template library is provided, designed based on financial industry compliance requirements and common business scenarios, and can be dynamically updated and maintained. Each template in the rule template library contains six core fields, the specific definitions of which are shown in the table below:

[0103] Here is an example of a rule template: Example 1 (High-risk isolation rules for core online banking business): Rule Identifier: Online Banking - High Risk - 001 Triggering conditions: Transaction type = Online banking transaction & Terminal status = Unauthorized terminal & Risk level = High Action to be performed: Isolate (block the terminal's IP address from accessing the online banking server). Priority: Level 1 Related business level: Core business Risk level associated with: High risk Example of a corresponding ACL rule: access-list 3001 deny ip [illegal terminal IP range] [wildcard mask] [online banking server IP] 0.0.0.0 Example 2 (Risk-limiting rules for third-party API calls): Rule Identifier: Third-Party Interface - Medium Risk - 002 Triggering conditions: Business type = third-party API call & access frequency > 100 times / minute & risk level = medium Action to be performed: Rate limiting (limiting concurrent requests to ≤50 times / minute) Priority: Level 3 Related business level: Important business Associated risk level: Medium risk Example 3 (Low-risk approval rules for bulk corporate transfers): Rule Identifier: Corporate Bulk Transfer - Low Risk - 003 Triggering conditions: Business type = bulk corporate transfer & Business entity = registered corporate client & Risk level = low Action to be performed: Release Priority: Level 5 Related business level: Core business Risk level associated with: Low Taking the <core business, low risk> tuple output from step S3 as input, the system dynamically matches and generates differentiated security isolation rules from the rule template library. Specific implementation includes: Extract the core parameters from the binary data set: Business Type = Enterprise Batch Transfer, Risk Level = Low, Terminal IP = 10.10.1.100, Business Port = 443, Access Frequency = 120 times / minute. Also extract the Business Identifier = 0x0003, Business Entity = Registered Enterprise Customer, Access Scenario = Internal Network Office IP Segment.

[0104] Match the rule template "Enterprise Batch Transfer - Low Risk - 003". The extracted parameters will be automatically filled into the trigger conditions and execution action parameters of the matched rule template to generate personalized rules. Rule Identifier: Corporate Bulk Transfer - Low Risk - 003 - INST-001 Triggering conditions: Transaction type = Enterprise bulk transfer & Transaction entity = Registered enterprise customer & Terminal IP = 10.10.1.100 & Risk level = Low Action executed: Allow access (allow this terminal IP to access the online banking server 172.20.1.50) Priority: Level 5 Related business level: Core business Risk level associated with: Low When the business perception results change (such as the risk level rising from medium risk to high risk, or the addition of a new terminal type), or when the business enters a peak period (such as the peak of enterprise batch transfers from 9:00 to 11:00 on weekdays), the rules will be automatically updated to adjust the triggering conditions, execution actions, or priorities of the rules.

[0105] Taking the company's bulk transfer business as an example, when the access frequency reaches 200 times / minute during the peak period of 10:00-11:00 on trading days, the peak period correlation analysis process is triggered. The system extracts the business identifier 0x0003, the business entity is a registered company, and the access scenario is an internal office IP segment, and performs correlation verification with the traffic characteristics (access frequency 200 times / minute). Since the business identifier is a legitimate bulk transaction type, the business entity is a registered customer, and the access scenario is compliant, it is determined to be a legitimate bulk transaction. The rule triggering condition automatically skips the "high concurrency" rate limiting logic and only performs regular monitoring to avoid false rate limiting.

[0106] The generated isolation rules are synchronized to network devices such as firewalls and switches via a distribution interface for deployment, implementing differentiated isolation policies. These differentiated isolation policies include: core services are allocated separate isolation domains, prohibiting direct communication with high-risk services and unauthorized terminals; important services are allocated dedicated isolation domains, allowing only authorized terminals and services to access them; ordinary services are allocated general isolation domains, implementing basic isolation rules; and cross-organizational services utilize a combination of dedicated VPN isolation and access control to achieve cross-domain isolated access. Deployment response time is ≤100ms.

[0107] Step S5: Generate and deploy differentiated traffic control rules based on business priorities. Based on the business priorities determined in step S2 and the risk assessment results output in step S3, differentiated traffic control rules are generated.

[0108] The traffic control rules include bandwidth allocation rules, flow limiting threshold rules, and traffic scheduling rules.

[0109] The bandwidth allocation rules are detailed in the table below:

[0110] The bandwidth allocation ratios (30%, 20%, 30%) mentioned above are exemplary values. The specific values ​​can be dynamically adjusted according to the total network bandwidth and business distribution characteristics of the financial institution. For example, institutions with a high proportion of core business can increase the fixed bandwidth of core business to 40%, but all of these are within the protection scope of this invention.

[0111] The specific rules for rate limiting thresholds are as follows: Appropriate rate limiting thresholds are set for services with different risk levels. High-risk services are subject to strict rate limiting thresholds (e.g., concurrent connections ≤ 10 times / minute, frequency ≤ 10 times / minute); medium-risk services are subject to standard rate limiting thresholds (e.g., concurrent connections ≤ 50 times / minute, frequency ≤ 50 times / minute); and low-risk services are subject to lenient thresholds or no rate limiting. For services accessed by unauthorized terminals, regardless of the risk level, strict rate limiting thresholds are set or traffic transmission is directly prohibited. The thresholds (10, 50) mentioned above are exemplary values. In actual applications, they can be dynamically adjusted according to the normal fluctuation range of the business. For example, for large enterprise batch transfer services, the lenient threshold can be increased to concurrent connections ≤ 500 times / minute.

[0112] Taking the aforementioned enterprise bulk transfer business as an example, its risk level is low, and the flow restriction threshold is set to a lenient mode: concurrency ≤ 200 times / minute, frequency ≤ 300 times / minute, to ensure that bulk transactions are not affected during peak periods.

[0113] The traffic scheduling rules are as follows: Core and important businesses are prioritized for low-latency, high-reliability forwarding paths; ordinary businesses are assigned regular forwarding paths; and cross-organizational businesses are assigned dedicated VPN forwarding paths. For example, enterprise bulk transfers, as a core business, are forwarded through a dedicated low-latency path, with end-to-end latency controlled within 50ms; office document transfers, as ordinary businesses, are forwarded through a regular path, with latency requirements relaxed to within 200ms.

[0114] The generated traffic control rules are synchronized to routers and traffic management devices via the distribution interface for deployment.

[0115] Step S6: Coordinated handling of isolation and flow control The processing procedure in step S6 is as follows: Figure 4 As shown, it specifically includes: Real-time monitoring of network traffic anomalies and security risk events. Traffic anomalies include sudden bandwidth overload, sharp increases in transmission latency, and abnormal packet loss rates; security risk events include malicious traffic attacks, unauthorized terminal access, and unauthorized access.

[0116] When an anomaly or risk is detected, a collaborative mechanism is triggered. Isolation rule adjustment commands and flow control rule adjustment commands matching the anomaly event are generated simultaneously. The command format follows a standardized interface definition as follows: The first interface address is / api / coordination / isolation, which is used to issue isolation commands. Its core parameters include: command ID (instructionId), action (supports blocking or unblocking), target object (e.g., IP network segment), priority, and expiration time (expireTime).

[0117] The second interface address is / api / coordination / traffic, which is used to issue traffic control commands. Its core parameters include: command ID (instructionId), action (supports limit or allow), target object (target), limit parameters (limitParam, including concurrency and frequency), and priority.

[0118] Suppose a DDoS attack is detected at a certain time from the IP range 192.168.5.0 / 24, targeting the online banking server 172.20.1.50. A coordinated response mechanism simultaneously generates two commands: Isolation directive: action=block, target=192.168.5.0 / 24, priority=1, expireTime=3600 Rate limiting command: action=limit, target=192.168.5.0 / 24, limitParam={concurrency ≤ 10, frequency ≤ 10 times / minute}, priority=1 The two generated instructions are sent in parallel to the corresponding network execution devices via a message queue. The message queue is implemented using RabbitMQ, which supports asynchronous parallel instruction sending and execution status tracking, ensuring that the two instructions arrive at the firewall and traffic control devices at approximately the same time.

[0119] Before issuing instructions, newly generated rules undergo real-time conflict detection. The conflict detection process includes: (1) Rule parsing: The input rules are parsed in a structured manner to extract the core features of the rules and form a standardized rule feature vector. The core features include rule identifier, triggering condition, execution action, action parameters, priority, validity period, associated business level, and associated risk level.

[0120] (2) Feature extraction: The key features extracted from the rules are the "control objectives", "action types", and "action parameter ranges". Control objectives are uniformly standardized into three types: IP segment, terminal ID, and business interface URL; action types are divided into "blocking" (isolation), "restriction" (rate limiting), and "allowing" (allowing transmission); action parameter ranges are quantified into specific values.

[0121] (3) Association comparison: Establish a rule feature association matrix and compare the feature vector of the new rule with the feature vector of the existing effective rule one by one. The comparison adopts the cosine similarity algorithm. When the similarity is ≥80% and the core features (target, action) are inconsistent, it is judged as a potential conflict.

[0122] Rule conflicts are explicitly defined in the following three categories: Category 1: Conflicting Actions. These are actions that conflict with each other, targeting the same control objective and within the same effective timeframe (e.g., one rule blocks / limits traffic, while another allows passage). Regardless of whether the control objectives are completely identical (this applies to both inclusive and overlapping relationships), any conflicting actions fall into this category.

[0123] The second type is parameter conflict. For the same control objective, the same effective time range, and the same type of action (both are blocking or both are rate limiting), the core parameters of the actions are contradictory (such as inconsistent rate limiting concurrency thresholds).

[0124] The third category: Scope conflict. This refers to situations where the control objectives are inclusive or overlapping, share the same effective time range, but have the same type of action and identical or compatible parameters, resulting in a potential conflict only due to differences in the scope of the control objectives. This type of conflict is actually a subset of the first two categories and is handled separately when it cannot be categorized into the first two.

[0125] Suppose that at a certain moment, two rules exist simultaneously: Rule A (newly generated): Isolation command, target=192.168.5.0 / 24, action=block, priority=level 1, expireTime=3600 seconds Rule B (currently in effect): Allow access, target=192.168.5.100, action=allow, priority=level 3, expireTime=7200 seconds Conflict detection revealed that the control objective 192.168.5.100 of rule B is included by the control objective 192.168.5.0 / 24 of rule A, and the actions are contradictory (block vs. allow), and the validity periods overlap (both are valid for 3600 seconds), thus it is determined to be a scope conflict.

[0126] When a rule conflict is detected, a hierarchical resolution mechanism combining preset priority as the primary factor and arbitration algorithm as a fallback is adopted to determine the final effective rule and execution parameters.

[0127] Preset priority resolution (applicable to action conflicts and range conflicts): The priority score for conflicting rules is calculated using the following formula:

[0128] in, Let be the weighting coefficient, satisfying Rules with higher scores take precedence, while rules with lower scores are automatically deactivated or suspended. If scores are the same, blocking or restrictive rules are retained (security first principle).

[0129] In this embodiment, the weighting coefficients are determined based on the importance of each factor to security control: risk level directly reflects the degree of threat, so it is given the highest weight; business level reflects asset value, so it is given the next highest weight; rule priority is a management indicator, so it is given a relatively low weight.

[0130] Based on this principle, take , , RiskLevelScore represents the risk level score (high risk = 10, medium risk = 5, low risk = 2), BizLevelScore represents the business level score (core business = 8, important business = 5, ordinary business = 3), and RulePriority represents the rule priority score (level 1 = 10, level 2 = 8, level 3 = 6, level 4 = 4, level 5 = 2). The above score mapping table is an example of values. In actual applications, it can be adjusted according to management strategies. For example, the core business score can be increased to 10 to strengthen protection, but all of this is within the scope of this invention.

[0131] Taking the aforementioned scope conflict as an example: Rule A: Risk Level H (Score 10), Business Level A (Score 8), Rule Priority Level 1 (Score 10) ConflictPriority_A=0.5×10+0.3×8+0.2×10=5+2.4+2=9.4 Rule B: Risk Level L (Score 2), Business Level A (Score 8), Rule Priority Level 3 (Score 6) ConflictPriority_B=0.5×2+0.3×8+0.2×6=1+2.4+1.2=4.6 Rule A, which scores higher, takes effect first, while Rule B is temporarily invalidated and will be automatically activated after Rule A expires.

[0132] If the scores are the same, prioritize retaining the blocking or restricting rules (safety first); if they are all of the same action type, retain the rule with stricter parameters.

[0133] Arbitration algorithm as a fallback (applicable to conflicts involving parameter clashes or identical priority scores): A dual-objective arbitration algorithm, combining "minimizing the scope of impact" and "maximizing business adaptability," is used to calculate the comprehensive score of the rules.

[0134] in, This is a weighting coefficient used to balance the importance of the scope of impact and business adaptability. The rule parameter with the best overall score is selected as the final execution parameter. If the difference in ArbitrationScore is ≤0.05 and involves core business or high-risk scenarios, a manual intervention process is triggered.

[0135] In this embodiment, considering the stability of the production environment as a priority, we take... This prioritizes minimizing the impact scope. ImpactScope is the impact scope score (0-1, calculated as the normal business volume affected by the rule / total business volume), and BusinessFit is the business fit score (0-1, calculated as the degree of matching between the rule triggering conditions and the business scenario).

[0136] Example of parameter conflict: Rule C: Rate limiting command, target=third-party interface URL, limitParam=concurrency ≤ 50 times / minute, impactScope=0.3 (affecting 30% of normal business volume), BusinessFit=0.8 (suitable for general scenarios) Rule D: Rate limiting instruction, target=same third-party interface URL, limitParam=concurrency ≤20 times / minute, impactScope=0.6 (affecting 60% of normal business volume), BusinessFit=0.9 (suitable for high-risk scenarios) Calculate the ArbitrationScore: Rule C: 0.6 × (1 - 0.3) + 0.4 × 0.8 = 0.6 × 0.7 + 0.3² = 0.4² + 0.3² = 0.74 Rule D: 0.6 × (1 - 0.6) + 0.4 × 0.9 = 0.6 × 0.4 + 0.36 = 0.24 + 0.36 = 0.60 Rule C scored higher overall, and the final execution parameter was set to "concurrency ≤ 50 times / minute", which ensures security while minimizing the impact on normal business operations.

[0137] Human intervention as a safety net: When a conflict rule involves core business or high-risk scenarios, and the difference in the overall score of the arbitration algorithm is ≤0.05, or the conflict type is a complex conflict (with simultaneous conflicts in actions, parameters, and scope), manual intervention is triggered. The module automatically triggers an alarm and pushes the details of the conflict rule, the conflict type, and the preliminary judgment result of the arbitration algorithm to the administrator's backend, whereby the administrator can manually determine the priority of rule implementation or adjust rule parameters.

[0138] Step S7: Simulation verification and closed-loop feedback of the strategy The implementation process of step S7 is as follows: Figure 5 As shown, it specifically includes: The security isolation rules and flow control rules adjusted in step S6 are first sent to a simulation verification environment isolated from the production network for verification.

[0139] The simulation verification environment is a lightweight simulation network built on container technology, specifically including: using Docker and Kubernetes to manage twin nodes and constructing two logically isolated network spaces (management channel and simulation channel). The management channel is used for remote control, configuration distribution, and monitoring communication; the simulation channel is used to simulate the business flow and protocol interaction in an industrial setting.

[0140] The containers in the simulation verification environment include: Soft PLC container image: Built-in corresponding protocol stack (such as Modbus, S7, DNP3), supports periodic read and write, event-triggered command issuance, response messages and exception response. Modbus Protocol Server Image: Supports Modbus TCP / RTU protocol, simulating register read / write behavior of a real PLC. HMI simulation container: Simulates data acquisition and command issuance behavior of human-computer interaction interface Sensor data source simulation container: Simulates the periodic data reporting behavior of sensors. Each container has a built-in industrial control protocol stack and data interaction service to ensure that the simulation environment can realistically simulate the equipment nodes, communication protocols and business interaction logic of the production network.

[0141] Taking the DDoS attack handling rules generated in step S6 as an example, the results are verified in a simulation environment: Deploy a soft PLC container to simulate an online banking server, IP address 172.20.1.50 Deploy a client emulation container to simulate a legitimate endpoint (IP=10.10.1.100) and an attack endpoint (IP=192.168.5.100). The verification process includes: (1) Forward verification: The simulated attack terminal (192.168.5.100) sends a DDoS attack request to the online banking server. The simulation environment detects that the request is successfully blocked by the new rule and the attack traffic is blocked by the firewall. The attack interception rate is 100%.

[0142] (2) Negative verification: Simulate a legitimate terminal (10.10.1.100) to initiate a batch transfer request for the enterprise. The simulation environment detects that the request is allowed normally. The end-to-end transmission delay is 35ms (lower than the threshold of 50ms), and the legitimate business is not affected.

[0143] (3) Conflict verification: Deploy rule A (block 192.168.5.0 / 24) and rule B (allow 192.168.5.100) simultaneously in the simulation environment to verify whether the conflict detection and resolution mechanism works as expected, and ensure that rule B is temporarily disabled to avoid rule contradictions.

[0144] Validation metrics include: Security risk mitigation effectiveness: Attack interception rate ≥ 95%, vulnerability remediation rate ≥ 90%. Impact on business traffic: latency ≤100ms, throughput ≥1Gbps Resource utilization: CPU utilization ≤ 80%, memory utilization ≤ 70%. The above verification indicator thresholds are exemplary values. In actual applications, they can be adjusted according to business SLA requirements. For example, for ultra-low latency services, the latency threshold can be set to 20ms.

[0145] Once verified, the rules will be officially deployed to the corresponding execution devices in the production network, and the verification results will be fed back to the rule generation process as a basis for subsequent rule optimization. Rules that fail verification will be prevented from being deployed and will trigger the rule reconstruction process.

[0146] Example 2: Example of a business-aware financial network isolation control system This embodiment provides a business-aware financial network isolation control system. The system adopts a modular architecture design corresponding to the method described in Embodiment 1, and the modules interact with each other and transmit instructions through standardized interfaces.

[0147] Reference Figure 6 (Schematic diagram of the system structure of the present invention), the system includes the following modules: The business perception module, as the data input front end of the system, is used to execute the function of step S1 in Embodiment 1. The business perception module includes an intelligent data acquisition gateway deployed at the boundary of the financial network, and a perception data processing unit connected to the intelligent data acquisition gateway.

[0148] Taking a commercial bank as an example, an intelligent data acquisition gateway is deployed between its core switch and the internet egress to capture all traffic entering and leaving the data center in real time. The intelligent data acquisition gateway supports port mirroring mode and is compatible with existing mainstream network equipment such as Cisco and Huawei. When a corporate customer initiates an online banking transaction through an office terminal (IP=10.10.1.100), the intelligent data acquisition gateway captures the transaction traffic in real time and extracts network layer characteristics (source IP=10.10.1.100, destination IP=172.20.1.50, source port=54321, destination port=443, protocol=TCP), transport layer characteristics (packet length=512 bytes, session duration=350ms, packet interval=25ms), and application layer characteristics (HTTP user agent=“Mozilla / 5.0”, financial transaction code=“TRX2025031800012345”) through deep packet inspection. Simultaneously, the hardware fingerprint (MAC address = "00:1A:2B:3C:4D:5E", motherboard serial number = "SN123456789") and network access status information (network access authentication number = "EMP-2025-00123") of the terminal are collected, and after forming a multi-dimensional feature vector, they are transmitted to the perception data processing unit.

[0149] The perception data processing unit performs preliminary processing and formatting of the collected multidimensional feature vectors to provide standardized input data for subsequent modules.

[0150] The business identification and classification module, connected to the business perception module, is used to perform the function of step S2 in embodiment 1. The business identification and classification module incorporates an improved weighted random forest model. Through dynamic adjustment of sample weights and tree splitting rules that fuse multi-source heterogeneous features, it accurately identifies business types, business entities, and access scenarios. Based on preset standards, it classifies the identified businesses into levels and outputs the business classification results.

[0151] The parameter configurations for the improved weighted random forest model are shown in the table below:

[0152] Taking the aforementioned corporate online banking transaction as an example, the business identification and classification module inputs multi-dimensional feature vectors into the model. After weighted voting by 128 decision trees, it outputs the business identification result: business type = corporate batch transfer, business entity = registered corporate customer, access scenario = intranet access. Subsequently, according to the preset classification standard, the identified business is divided into core businesses, and the business classification result = core business is output.

[0153] The risk assessment module is connected to both the business perception module and the business identification and classification module, and is used to perform the function of step S3 in Embodiment 1. The risk assessment module receives the business classification results and the real-time data collected by the business perception module, uses a multi-factor comprehensive scoring model to assess the access risk of various businesses, and outputs a "business level - risk level" binary pair.

[0154] Taking the above-mentioned enterprise batch transfer business as an example, the risk assessment module receives the business classification result = core business, and the real-time data (access behavior, traffic characteristics, terminal information) collected by the business perception module. It calculates the access behavior anomaly degree A = 10 points, the traffic characteristic anomaly degree F = 15 points, and the terminal credibility T = 5 points. It sets the weight coefficients w1 = 0.4, w2 = 0.35, w3 = 0.25, and the comprehensive risk score RiskScore = 10.5 points. Based on the preset threshold (high risk ≥ 60, medium risk 30-59, low risk < 30), it determines the risk level = low risk and outputs the tuple <core business, low risk>.

[0155] The dynamic isolation module, connected to the risk assessment module, is used to perform the function of step S4 in Embodiment 1. The dynamic isolation module includes a rule template library unit, a rule dynamic generation unit, and an isolation rule execution unit.

[0156] The rule template library unit is used to store predefined security policy rule templates, supporting rule classification, version control, and dynamic updates. The rule templates are designed based on financial industry compliance requirements and common business scenarios. The template format includes six core fields: rule identifier, triggering condition, execution action, priority, associated business level, and associated risk level, as shown in Table 1 of Example 1.

[0157] The rule dynamic generation unit takes the "business level - risk level" tuple as input and dynamically matches and generates differentiated isolation rules from the rule template library. Taking the above <core business, low risk> tuple as an example, the rule dynamic generation unit extracts core parameters (business type = enterprise batch transfer, risk level = low, terminal IP = 10.10.1.100, business port = 443, access frequency = 120 times / minute), and at the same time extracts business identifier = 0x0003, business subject = registered enterprise customer, access scenario = intranet office IP segment, matches the "enterprise batch transfer - low risk - 003" template from the rule template library, generates personalized rules, and adds the rule identifier "enterprise batch transfer - low risk - 003-INST-001".

[0158] When the perceived results of the business change or the business enters a peak period, the rule dynamic generation unit automatically triggers rule updates. For example, when the access frequency of the business rises to 200 times / minute during peak periods, the rule dynamic generation unit starts peak period correlation analysis. Based on the correlation verification of business identifier, business subject, access scenario and traffic characteristics, it determines that it is a legitimate batch transaction, and the rule triggering condition automatically skips the "high concurrency" rate limiting logic.

[0159] The isolation rule execution unit generates isolation rules and distributes them to network devices such as firewalls and switches via standardized interfaces. Taking the above rule as an example, the isolation rule execution unit converts it into an ACL rule "aclnumber3001rule10permitipsource10.10.1.1000destination172.20.1.500" and distributes it to the core firewall via SSH or RESTful interface.

[0160] The flow control module, connected to the risk assessment module, is used to perform the function of step S5 in Embodiment 1. The flow control module includes a bandwidth allocation unit, a flow limiting threshold setting unit, and a flow rule execution unit.

[0161] The bandwidth allocation unit allocates differentiated bandwidth to core, important, and ordinary services based on service priority, employing an allocation strategy that combines fixed minimum bandwidth, dynamic elastic bandwidth, guaranteed bandwidth, and shared bandwidth. Taking the aforementioned enterprise batch transfer service as an example, the bandwidth allocation unit allocates a fixed minimum bandwidth of 100Mbps and sets a dynamic elastic bandwidth upper limit of 150Mbps to ensure smooth service during peak periods.

[0162] The rate limiting threshold setting unit sets corresponding rate limiting thresholds according to the risk level. Taking the aforementioned low-risk business as an example, the rate limiting threshold setting unit sets lenient thresholds: concurrency ≤ 200 times / minute, frequency ≤ 300 times / minute.

[0163] The traffic rule execution unit generates traffic control rules and distributes them to routers and traffic management devices via standardized interfaces. For example, it distributes bandwidth allocation rules to SDN switches via the OpenFlow protocol and rate limiting rules to traffic shaping devices via SNMP or NetConf.

[0164] The collaborative linkage module is connected to both the dynamic isolation module and the flow control module, and is used to execute the function of step S6 in Embodiment 1. The collaborative linkage module includes a rule coordination unit, a risk linkage handling unit, and a strategy conflict detection and resolution unit.

[0165] When the rule coordination unit detects abnormal traffic or security risks, it simultaneously generates isolation rule adjustment instructions and traffic control rule adjustment instructions, and sends them out in parallel through a message queue. Taking the detection of a DDoS attack from the IP segment 192.168.5.0 / 24 as an example, the rule coordination unit simultaneously generates an isolation instruction (action=block, target=192.168.5.0 / 24, priority=1) and a rate limiting instruction (action=limit, target=192.168.5.0 / 24, limitParam={concurrency ≤ 10, frequency ≤ 10 times / minute}, priority=1), and sends them out in parallel to the firewall and traffic control device through a RabbitMQ message queue.

[0166] The risk linkage and response unit is used to coordinate with firewalls and intrusion detection devices to block risks, including blacklisting illegal terminal IPs, blocking malicious packets, and triggering alarms. In the DDoS attack example, the risk linkage and response unit triggers the firewall to blacklist the attacking IP range, simultaneously triggers the IDS device to update its attack signature database, and sends alarm information to the security operations and maintenance center.

[0167] The strategy conflict detection and resolution unit performs real-time conflict detection on the adjusted rules and uses a hierarchical resolution mechanism that combines preset priority as the primary factor with arbitration algorithm as a fallback to determine the final effective rule. Taking the scope conflict between rule A and rule B in Example 1 as an example, the strategy conflict detection and resolution unit calculates ConflictPriority_A=9.4 and ConflictPriority_B=4.6, determines that rule A takes priority and rule B is temporarily invalid, and records the conflict resolution result in the log.

[0168] The simulation verification platform, connected to the collaborative linkage module, is used to execute the function of step S7 in Embodiment 1. The simulation verification platform is a lightweight simulation network environment built based on container technology, used to simulate the device nodes, communication protocols, and business interaction logic of a production network, and to verify the effectiveness and detect conflicts of the adjusted security isolation rules and traffic control rules.

[0169] The simulation verification platform consists of: a container scheduling and orchestration system (Docker + Kubernetes), a network configuration platform (for building management and simulation channels), and a device image library (soft PLC container images, Modbus protocol server images, HMI simulation containers, and sensor data source simulation containers). Taking DDoS attack handling rule verification as an example, the simulation verification platform deploys a soft PLC container to simulate an online banking server (172.20.1.50), and deploys client simulation containers to simulate legitimate terminals (10.10.1.100) and attacking terminals (192.168.5.100), performing positive verification, negative verification, and conflict verification, and outputting a verification report.

[0170] The operation and maintenance supervision module connects to each of the above modules to provide full-process visualized operation and maintenance and supervision adaptation functions. The operation and maintenance supervision module includes a visualized operation and maintenance unit, a log traceability unit, and a supervision adaptation unit.

[0171] The visualized operation and maintenance unit is used to display service identification results, service classification, isolation rules, traffic status, and risk handling status in real time, supporting operation and maintenance personnel to view and operate in real time. For example, the visualized operation and maintenance unit can display the list of currently active core services, the bandwidth usage of each service, the number of deployed isolation rules, and the statistics of risk events in the past hour.

[0172] The log traceability unit is used to record the entire risk handling process, including the time of the anomaly, the content of the anomaly, the handling measures, and the handling result. The log retention period meets financial regulatory requirements (at least one year) and supports querying and tracing by business type, time, and risk level. For example, a DDoS attack event record would be: Time = 2025-03-18 10:30:22, Anomaly Type = DDoS Attack, Attack Source = 192.168.5.0 / 24, Handling Measures = Isolation + Rate Limiting, Handling Result = Successful Blocking, Handling Time = 356ms.

[0173] The regulatory adaptation unit is used to generate regulatory reporting reports to meet financial regulatory compliance requirements. For example, it generates a quarterly "Cybersecurity Isolation and Traffic Control Compliance Report," which includes a list of isolation rule configurations, a risk event statistics table, and regulatory indicators such as core business bandwidth availability. This report can be directly exported as a PDF or XML file for submission to regulatory agencies.

[0174] As a preferred technical solution, the dynamic isolation module further includes an isolation verification unit connected to the simulation verification platform. The isolation verification unit is used to verify the isolation effect through the simulation verification platform after the isolation rules are deployed. It simulates access requests from different levels of business and different risk scenarios to detect whether the isolation rules effectively block unauthorized access and whether they affect legitimate business collaboration, ensuring the effectiveness and security of the isolation rules.

[0175] As a preferred technical solution, the system further includes a policy library management module, which is connected to the dynamic isolation module, the traffic control module, and the collaborative linkage module, respectively. The policy library management module is used for unified management of the rule template library, supporting rule classification, version control, and dynamic updates, including adding policies (designing new policies for new security threats and business needs), modifying policies (optimizing the rules and execution conditions of existing policies based on actual application feedback), and deleting policies (deleting policies that are no longer applicable).

[0176] As a preferred technical solution, the system supports three deployment variants to adapt to the network architecture requirements of financial institutions of different sizes: A variant of the centralized management and control system: All modules are centrally deployed on cloud servers or physical server clusters in the core data center of the financial institution's headquarters, establishing a unified global management and control center. This center has full authority to manage the business awareness, dynamic isolation, traffic control, collaborative linkage, and operation and maintenance supervision of all branch nodes, business centers, and network nodes within the institution. Each branch node only deploys lightweight data acquisition agents, edge forwarding nodes, and basic execution equipment, lacking local management and decision-making capabilities. This is suitable for scenarios such as rural banks and city commercial banks where branch nodes lack independent operation and maintenance capabilities.

[0177] A variant of the cloud-edge distributed collaborative system: This variant adopts a layered deployment model of "global cloud management + local edge autonomy + lightweight terminal access." The cloud deploys a global business awareness module, a cross-regional collaborative linkage module, a network-wide security situation awareness module, and a full-scale operation and maintenance supervision and compliance module; the edge deploys a local business awareness module, a local dynamic isolation layer, a local traffic control layer, and a local collaborative linkage module; the terminal only deploys a lightweight data collection agent and basic execution unit. This is suitable for large-scale cross-regional deployment scenarios such as nationwide joint-stock banks and large city commercial banks.

[0178] A variant of the financial consortium multi-node interoperability system: Based on financial consortium blockchain technology, it constructs a distributed management and control architecture of "consortium master node + institutional sub-nodes + cross-institutional interoperability nodes". The consortium master node formulates unified cross-institutional management and control specifications and common standards; each institutional sub-node retains completely independent management and control rights within its own internal network; the cross-institutional interoperability nodes are responsible for end-to-end awareness of cross-institutional business, enforcement of cross-institutional isolation rules, cross-institutional traffic control, and preliminary cross-institutional risk detection. It is suitable for cross-institutional collaboration scenarios such as commercial bank consortia, bank-insurance cooperation, and financial-enterprise integration.

[0179] The embodiments described above are merely preferred embodiments of the present invention and are not intended to limit the present invention. The core protection scope of the business-aware financial network isolation control method and system provided by the present invention is defined by the appended claims.

[0180] It should be noted that all specific numerical values ​​appearing in this specification are exemplary values, used to help those skilled in the art understand how the technical solution of the present invention can be implemented in specific scenarios. In practical applications, the above parameters can be adaptively adjusted according to factors such as the business characteristics, risk appetite, network size, and regulatory requirements of different financial institutions. Such parameter adjustments do not change the core inventive concept of the present invention and should still fall within the protection scope of the present invention.

[0181] For those skilled in the art, various changes, modifications, substitutions, and variations can be made to the above embodiments within the scope of the present invention. For example, the improved weighted random forest model in step S2 can be replaced by other machine learning models, such as deep learning models (CNN-LSTM), gradient boosting trees (XGBoost, LightGBM), etc.; the rule template library in step S4 can be designed with different template fields and matching logic based on different business scenarios; the conflict detection and resolution mechanism in step S6 can be implemented using other algorithms, such as dynamic decision-making algorithms based on reinforcement learning; the simulation verification environment in step S7 can be constructed using different virtualization technologies, such as VMware, KVM, etc. These changes, modifications, substitutions, and variations, if they do not depart from the spirit and scope of the present invention, should all be covered within the protection scope of the present invention.

[0182] Furthermore, the technical solution of the present invention can be implemented in the form of a method, system, computer device, computer-readable storage medium, or computer program product. Accordingly, the scope of protection of the present invention also includes computer program products implementing the method and readable storage media storing the computer program product.

[0183] The scope of protection of this invention shall be determined by the actual content of the claims. The specific embodiments and variations described in the specification are for interpreting the claims only and should not be used to limit the interpretation of the claims. Any technical solution falling within the equivalent meaning and scope of the claims is within the scope of protection of this invention.

Claims

1. A business-aware financial network isolation control method, characterized in that, The method includes the following steps: Step S1, Business Multi-Dimensional Perception and Feature Extraction: The intelligent collection gateway deployed at the edge of the financial network captures the raw traffic data entering and leaving the network in real time, and extracts network layer features, transport layer features and application layer features through deep packet inspection technology; at the same time, it collects the hardware fingerprint and network access status information of the access terminal to form a multi-dimensional feature vector containing network layer features, transport layer features, application layer features and terminal features. Step S2, Business identification and classification based on improved weighted random forest: The multidimensional feature vector obtained in step S1 is input into the pre-trained improved weighted random forest model to identify business types, business entities and access scenarios, and output business identification results; then, according to the preset business classification standards, the identified financial businesses are divided into three levels: core business, important business and ordinary business. Step S3, Risk assessment based on business classification: Based on the business classification results output in step S2, and combined with the business access behavior characteristics, real-time traffic characteristics and terminal information collected in step S1, the access risks of various businesses are assessed, and a three-level risk assessment result is output; the business classification results and the risk assessment results are associated and stored to form a "business level - risk level" tuple. Step S4, Dynamic isolation rule generation and deployment based on the rule template library: Predefine the rule template library; take the "business level-risk level" tuple output in step S3 as input, dynamically match and generate differentiated security isolation rules from the rule template library; distribute the generated isolation rules to network devices for deployment. Step S5, Generation and Deployment of Differentiated Traffic Control Rules Based on Business Priority: Based on the business priorities determined in Step S2 and the risk assessment results output in Step S3, generate differentiated traffic control rules; distribute the generated traffic control rules to the traffic management device for deployment. Step S6, coordinated handling of isolation and flow control: Real-time monitoring of abnormal traffic and security risk events in the network. When an anomaly or risk is detected, a coordinated mechanism is triggered. Simultaneously, isolation rule adjustment instructions and flow control rule adjustment instructions matching the anomaly event are generated, and the two instructions are sent to the corresponding network execution devices in parallel. Before the instructions are sent, real-time conflict detection is performed on the newly generated rules. When a rule conflict is detected, a preset hierarchical resolution mechanism is adopted to determine the final effective rule and execution parameters. Step S7, Strategy Simulation Verification and Closed-Loop Feedback: The security isolation rules and traffic control rules adjusted in Step S6 are first sent to a simulation verification environment isolated from the production network for verification; in the simulation environment, access requests of different levels of business and different risk scenarios are simulated to verify the effectiveness of the new rules; after the verification is passed, the rules are officially sent to the corresponding execution devices in the production network for deployment, and the verification results are fed back to the rule generation process.

2. The business-aware financial network isolation control method according to claim 1, characterized in that, The improved weighted random forest model described in step S2 has a sample weight dynamic adjustment mechanism that specifically includes: allocating initial weights based on the sample category distribution to make the sum of the weights of normal business samples and abnormal business samples equal; iteratively updating the weights based on the misclassification cost, setting the cost weight for misclassifying abnormal business as normal business to be higher than the cost weight for misclassifying normal business as abnormal business; and expanding the abnormal samples by combining SMOTE oversampling, generating virtual abnormal samples, and then renormalizing the sample weights.

3. The business-aware financial network isolation control method according to claim 1, characterized in that, The improved weighted random forest model described in step S2 has the following tree splitting rules for multi-source heterogeneous feature fusion: for numerical features, the correlation weight between the feature and the business category is introduced to improve the information gain ratio; for categorical features, the association weight between the category and the business category is introduced to improve the Gini coefficient; at the same time, an interaction term between numerical features and categorical features is introduced, the weight of which is the product of the weights of the two corresponding basic features, and participates in the tree splitting calculation.

4. The business-aware financial network isolation control method according to claim 1, characterized in that, The step S4, which involves dynamically matching and generating differentiated security isolation rules from the rule template library, specifically includes: extracting core parameters from the "business level - risk level" tuple output in step S3, whereby the core parameters include business type, risk level, terminal IP, business port, and access frequency; simultaneously extracting business identifier, business subject, and access scenario information; automatically filling the extracted parameters into the trigger conditions and execution action parameters of the matched rule template to generate personalized rules; and automatically triggering rule updates and adjusting the trigger conditions, execution actions, or priorities of the rules when the business perception results change or the business enters a peak period.

5. The business-aware financial network isolation control method according to claim 1, characterized in that, The real-time conflict detection of the newly generated rules in step S6 specifically includes: performing structured parsing on the input rules and extracting the core features of the rules, including the control target, the type of execution action, and the range of action parameters; establishing a rule feature association matrix and comparing the feature vector of the new rule with the feature vector of the existing effective rules one by one; when the control targets overlap, the execution actions are contradictory, or the action parameters conflict, it is determined to be a rule conflict.

6. The business-aware financial network isolation control method according to claim 1, characterized in that, The pre-defined hierarchical resolution mechanism mentioned in step S6 specifically includes: for action conflicts and scope conflicts, calculating the priority score of the conflict rules, the priority score is calculated based on the risk level score, business level score and rule priority score, and the rule with the higher score takes precedence; for parameter conflicts and conflicts with the same priority score, using an arbitration algorithm to calculate the comprehensive score of the rules, the comprehensive score is calculated based on the impact scope score and business adaptability score, and the rule parameter with the best comprehensive score is selected as the final execution parameter.

7. The business-aware financial network isolation control method according to claim 1, characterized in that, The simulation verification environment described in step S7 is a lightweight simulation network built on container technology. The containers include a soft PLC container image, a Modbus protocol server image, an HMI simulation container, and a sensor data source simulation container. Each container has a built-in corresponding industrial control protocol stack and data interaction service.

8. A business-aware financial network isolation control system, characterized in that, The system for implementing the method according to any one of claims 1 to 7, wherein the system comprises: The business perception module is used to perform the function of step S1, including an intelligent data acquisition gateway deployed at the boundary of the financial network, and a perception data processing unit connected to the intelligent data acquisition gateway. The business identification and classification module is connected to the business perception module and is used to perform the function of step S2. It has an improved weighted random forest model built in. The risk assessment module is connected to the business perception module and the business identification and classification module respectively, and is used to perform the function of step S3; The dynamic isolation module, connected to the risk assessment module, is used to perform the function of step S4, and includes a rule template library unit, a rule dynamic generation unit, and an isolation rule execution unit. The flow control module, connected to the risk assessment module, is used to perform the functions of step S5, including a bandwidth allocation unit, a flow limiting threshold setting unit, and a flow rule execution unit. The collaborative linkage module is connected to the dynamic isolation module and the flow control module respectively, and is used to perform the function of step S6, including a rule collaboration unit, a risk linkage handling unit and a strategy conflict detection and resolution unit. The simulation verification platform is connected to the collaborative linkage module and is used to perform the function of step S7; The operation and maintenance supervision module is connected to each of the above modules to provide full-process visualized operation and maintenance and supervision adaptation functions, including a visualized operation and maintenance unit, a log traceability unit, and a supervision adaptation unit.

9. The business-aware financial network isolation control system according to claim 8, characterized in that, The dynamic isolation module also includes an isolation verification unit connected to the simulation verification platform. After the isolation rules are deployed, the simulation verification platform is used to verify the isolation effect to ensure that the isolation rules effectively block unauthorized access without affecting legitimate business collaboration.

10. The business-aware financial network isolation control system according to claim 8, characterized in that, The system also includes a policy library management module, which is connected to the dynamic isolation module, the traffic control module and the collaborative linkage module, respectively, for unified management of the rule template library and supports rule classification, version control and dynamic updates.

Images