System and method for adaptive observation and verified defense control of a versioned network digital twin based on semantic change and evidence completion conditions

Abstract

The present invention relates to a system and method for constructing an approval reference network digital twin using heterogeneous network observation information and selectively performing in-depth observation and defense only on the parts where semantic changes occur in low-cost change monitoring. New changes are separated into candidate twin branches, and the observation target, analysis level, and packet retention scope are adjusted according to the evidence completion conditions and unsatisfied evidence of the situational hypothesis. Multiple response candidates are evaluated in the counterfactual branch, and after distinguishing and verifying the request status, actual application status, and actual effect of the selected response, only verified changes are promoted to the reference twin, and only the failed parts are reverted and replanned.

Description

Technology Field

[0001] The present invention relates to computer network observation, network digital twin, detection of network anomalies and semantic changes, artificial intelligence-based situational reasoning, adaptive data collection, security control, and service recovery.

[0002] More specifically, the present invention relates to a technology for representing assets, identities, services, applications, data flows, policies, dependencies, and corresponding functions existing in a network of an enterprise or institution as a graph, and for constructing an approval standard network digital twin by combining source information, observation time, validity period, reliability, and state version with each state.

[0003] Furthermore, the present invention relates to a technology that reduces normal resource usage by utilizing change monitoring information having a lower observation cost than the approval standard network digital twin, and selectively increases observation fidelity only for parts among raw change candidates that are determined to be meaningful changes in light of policies, tasks, normal cycles, scheduled changes, and the scope of influence of dependencies.

[0004] Furthermore, the present invention relates to a technology that separates newly observed changes into observation candidate twin branches without immediately reflecting them in the approval standard state, calculates unsatisfied evidence by comparing the evidence completion conditions required for a situational hypothesis with current evidence, and dynamically changes the observer, target, protocol analysis level, time interval, and original packet preservation range according to the unsatisfied evidence.

[0005] Furthermore, the present invention relates to a verification-type defense control that simulates a plurality of response candidates in a counterfactual branch of a network digital twin, evaluates risk reduction, business impact, loss of observability, return costs, and authorization satisfaction to apply a selected response as a temporary response overlay, and distinguishes and verifies the requested response state, the actually applied response state, and the effect verified in the real network.

[0006] Some embodiments of the present invention may be linked with a firewall, router, switch, network access control device, software-defined network controller, proxy, identity and access management system, endpoint security system, cloud security control means, or a formal control interface of a service provider.

[0007] Some embodiments of the present invention may generate corresponding candidates for targets outside the management boundary, but actual implementation may be limited to the scope where legitimate authority, such as ownership, management rights, contractual delegation, provider authority, or public approval, is mechanically verified, and if authority is not verified, only simulated implementation or recommendations may be provided. Background Technology

[0008] In an enterprise network, different types of resources, such as user terminals, servers, network equipment, virtual machines, containers, databases, file storage, application programming interfaces (AIPs), cloud services, and external services, are connected simultaneously. These resources do not exist as a fixed list but rather their states and relationships continuously change based on user logins, address allocation, auto-scaling, deployment, failover, and the use of external services.

[0009] While conventional packet analyzers can provide details of individual packets or sessions, it is difficult to automatically determine which segments and relationships within a vast amount of packets should be analyzed first, how various observations constitute a single operational or security situation, and what additional evidence is needed to confirm the current conclusion.

[0010] Network performance management systems monitor traffic volume, latency, loss rates, and equipment status, while network detection and response systems can detect potential threats by utilizing deviations from normal behavior criteria or attack indicators. However, since security alerts, failure alerts, normal deployments, and the use of new business services can manifest as the same network change, it is difficult to determine the actual significance based solely on a single anomaly score.

[0011] Some systems graph network assets and connectivity or simulate attack paths. However, if newly observed real-world states are automatically merged into the normal criteria, a standard corruption problem may occur where backdoor communications or incorrect settings maintained by attackers for a long time are learned as the new normal.

[0012] Conversely, if the baseline state is fixed and never updated, normal service deployments, address changes, cloud expansions, and business process changes may be repeatedly detected as anomalies. Therefore, a structure is required that separates verified approved baseline states from unverified observation candidate states, and incorporates a candidate state into a new baseline version only when it satisfies defined promotion conditions.

[0013] Conventional anomaly detection technologies can detect raw changes themselves, such as new IP addresses, new domains, traffic increases, certificate changes, or changes in account login locations. However, not all raw changes are semantic changes worth investigating, and failure to consider scheduled deployments, normal cycles, policy-based permissions, service dependencies, and data classes results in excessive alerts and consumption of analysis resources.

[0014] Continuously storing original packets across the entire corporate network and performing in-depth analysis of all protocols significantly increases communication replication, storage volume, indexing volume, and analysis computational load. Furthermore, the unnecessary preservation of unencrypted payloads, user identification information, and business data may increase the risk of exposure to personal information and trade secrets.

[0015] Although techniques exist to initiate packet capture when an event occurs or to preserve a portion of the circular buffer, applying a fixed capture level for a fixed event alone can result in the collection of data unrelated to what evidence is lacking for the current judgment. For example, even when it is sufficient to verify the approval status of a target service, storing the entire payload can be excessive.

[0016] Therefore, it is necessary to define the evidence items constituting the situational hypothesis and the machine-evaluable evidence completion conditions, calculate unsatisfied evidence by comparing it with currently secured evidence, and then select the observer and observation level that can most efficiently reduce the said unsatisfied evidence.

[0017] In network defense, there are various response candidates for the same threat, including sustained observation, rate limiting, destination blocking, session termination, account suspension, endpoint isolation, route bypassing, and service recovery. The strongest block is not always the best option, as it can disrupt normal operations or eliminate management channels, evidence collection channels, and even return command paths.

[0018] Some security technologies simulate security controls in a virtual environment or perform automated responses based on risk scores. However, it is necessary to separately verify not only whether the measures reduce the anticipated risk, but also whether the status can be monitored and shutdown or rollback commands can be delivered after the measures are taken, and whether the requested settings have been applied to the actual equipment.

[0019] Even if a firewall or network access control device sends a response acknowledging receipt of a command, the actual status may differ from the request due to rule conflicts, equipment delays, insufficient privileges, or partial failures. Furthermore, even if settings are applied, attack communications may persist via other routes or only normal services may be interrupted; therefore, it is necessary to distinguish between command receipt, actual application, and the actual effect.

[0020] If existing policies are directly overwritten for temporary incident response, it is difficult to restore the original state after the incident is concluded, and there is a risk of reverting to past policies modified by the administrator during processing. Therefore, it is necessary to apply a temporary response overlay with an expiration period and priority while preserving the existing default policy, and to conditionally revert by re-querying the latest approval criteria at the time of conclusion.

[0021] Network state, permissions, policies, or service dependencies may change during the execution of a multi-stage defense plan. In such cases, re-executing the entire plan from scratch could result in the redundant application of already verified measures or the escalation of service disruptions; therefore, it is necessary to selectively invalidate only the actions affected by the changes, preserve verified actions, and replan only the incomplete parts.

[0022] While network situations can be described in natural language using generative AI or language models, it is difficult to detect hallucinations or overinterpretation if the explanatory sentences are not linked to original evidence. It is necessary to distinguish between established propositions, those for which counter-evidence exists, and those for which evidence is still insufficient, and to link each judgment to packets, flows, logs, and the actual state.

[0023] There may be a need to control targets outside the administrative boundary to counter attacks originating from the outside. However, external addresses may not be actual assets of the attacker but rather compromised transit points, and accessing or modifying targets without verified authorization can result in damage to third parties. Therefore, external active response must be distinguished from general internal defense and restricted to execution only when legitimate authorization regarding the target, action, duration, and scope is mechanically verified.

[0024] Accordingly, an integrated closed-loop is required that selectively performs in-depth observations only on parts where meaningful changes have occurred without contaminating the verified baseline state of the real network, actively supplements insufficient evidence, compares the risk reduction and side effects of candidate responses in the digital twin, and updates the baseline state or maintains the response only after verifying actual application and effectiveness. The problem to be solved

[0025] One objective of the present invention is to provide a system and method for reconstructing heterogeneous network observation information into a versioned network digital twin including assets, identities, services, data flows, policies, and dependencies, and for managing the source, observation time, validity period, reliability, and whether each state was observed or inferred.

[0026] Another objective of the present invention is to generate a network blueprint verified through initial intensive observation as an approval standard twin, and to reduce communication volume, storage volume, and analysis computation volume by using only change monitoring information with a lower cost than the approval standard twin during normal operation.

[0027] Another objective of the present invention is to reduce standard contamination, where an attack or error is incorporated into a normal standard solely because it has existed for a long period, by separating newly observed changes into candidate observation twin branches instead of immediately merging them into the accepted standard twin.

[0028] Another objective of the present invention is to determine raw change candidates as semantic changes based on scheduled changes, normal cycles, policy relevance, business impact, data class, dependency diffusion range, and observation reliability, and to enhance observation fidelity by selecting only the impact subgraphs consisting of related assets and relationships.

[0029] Another objective of the present invention is to set evidence items and evidence completion conditions for each situational hypothesis, calculate unsatisfied evidence by comparing it with current evidence, and dynamically select observers, protocol analysis levels, time intervals, sampling rates, and packet retention ranges to reduce said unsatisfied evidence.

[0030] Another objective of the present invention is to make the basis of natural language explanation reproducible by connecting supporting evidence, counter-evidence, and unsatisfied evidence for each judgment proposition of artificial intelligence regarding network situations.

[0031] Another objective of the present invention is to simulate multiple corresponding candidates in a counterfactual twin branch and to evaluate not only risk reduction but also the preservation of observability, such as business continuity, management channels, evidence collection channels, and termination and return command paths.

[0032] Another objective of the present invention is to convert a selected correspondence into an execution package mapped to actual control functions, targets, preconditions, permissions, policies, approvals, verifications, and return conditions, and to apply it as a temporary correspondence overlay that does not directly overwrite the default policy.

[0033] Another objective of the present invention is to distinguish between a requested response state, a state actually applied to a control means, and an effect confirmed in a real network, and to determine at which of these stages a failure occurred to generate a safe follow-up measure.

[0034] Another objective of the present invention is that when the reference policy changes during a response, it does not revert to the old policy but instead re-queries the latest approval reference policy to perform a conditional return, and promotes only verified normal changes to the new approval reference twin version.

[0035] Another objective of the present invention is to selectively invalidate only the affected behaviors without discarding the entire response when policies, permissions, status, or dependencies are changed, and to replan only the failed or incomplete parts while preserving verified behaviors.

[0036] Another objective of the present invention is to verify authorization tokens and allowances for corresponding candidates outside the management boundary, and to provide only simulated execution or recommendations while blocking actual execution if authorization is not verified or is disabled by product policy.

[0037] Another objective of the present invention is to provide a Network Vertical Contract containing local twin versions, common semantic projection information, semantic consumption specifications, observation and response capabilities, policy and authorization requirements, verification providers, and recovery capabilities so that NetworkGuard can operate as an independent network operation domain while optionally linking with a higher-level AI control plane; receive global operation goals, global invariants, cross-domain semantic deltas, or allowable response ranges from the higher-level control plane; and provide an interface that responds with actual application status, effects, evidence, side effects, and version information. means of solving the problem

[0038] A network digital twin-based adaptive observation and verification defense control system according to one embodiment for achieving the above objective may include an observation information integration unit, an approval standard twin management unit, a semantic change determination unit, an impact subgraph calculation unit, an evidence condition management unit, an adaptive observation planning unit, a response branch simulation execution unit, a response execution package generation unit, an actual application status verification unit, an effect verification unit, and a twin promotion / return management unit.

[0039] The above observation information integration unit can receive heterogeneous observation information from at least two of packet mirroring or network taps, NetFlow or IPFIX, DNS, DHCP, TLS, HTTP, QUIC, SMB, SSH, authentication, virtual private network, firewall, proxy, network equipment, endpoint, application, cloud and software-as-a-service audit logs.

[0040] The above observation information integration unit can normalize the above heterogeneous observation information into a semantic observation object that includes at least some of the subject, action, target, time, communication path, result, change from normal, evidence reference information, reliability, and personal information grade.

[0041] The above approval standard twin management unit can generate an approval standard network digital twin including asset nodes, identity nodes, service nodes, data nodes, policy nodes, and defense capability nodes, and edges representing communication, calling, ownership, use, permission, blocking, dependency, and verification relationships.

[0042] Each node, edge, or state of the above approval criteria twin may include at least one of an information source, observation time, validity period, reliability, classification of observation or inference value, state version, and privacy grade.

[0043] The above approval criteria twin can be generated by comparing information acquired from multiple observers during the initial intensive observation period with at least one of the asset list, configuration management information, approval service list, deployment record, change schedule, and policy information.

[0044] The above semantic change determination unit receives change monitoring information acquired at a cost lower than the cost of reconstructing the entire state of the above approval standard twin after the initial intensive observation is completed, and can calculate raw change candidates by comparing the change monitoring information with the approval standard twin.

[0045] The above semantic change determination unit can calculate whether there is a semantic change in a raw change candidate or a semantic change score by using at least two of novelty, normal cycle consistency, scheduled change consistency, policy relevance, data grade, business impact, dependency diffusion range, and observation reliability.

[0046] The above approval standard twin management unit may not immediately merge change candidates determined to be semantic changes into the approval standard twin, but may instead generate an observation candidate twin branch including a standard version identifier and a candidate branch identifier.

[0047] The above-mentioned impact subgraph calculation unit can select a subgraph that may be affected, starting from the node or edge where the change occurred, along with service dependencies, communication paths, identity linkages, policy coverage, data movement relationships, or controllability.

[0048] The above evidence condition management unit may generate a situation hypothesis corresponding to at least one of normal change, failure, policy violation, misuse, or cyber threat based on the above impact subgraph and observation information, and set an evidence completion condition including one or more evidence items required for each situation hypothesis and a machine-evaluable satisfaction determination formula.

[0049] The above evidence condition management department can calculate unsatisfied evidence items, reasons for non-satisfaction, or remaining uncertainty by comparing the currently secured supporting evidence, counter-evidence, and unconfirmed evidence with the above evidence completion conditions.

[0050] The above adaptive observation planning unit can generate a plurality of candidate observation actions to reduce the above unsatisfactory evidence and calculate the expected information gain or expected uncertainty reduction amount of each candidate observation action and at least one cost among communication volume, storage volume, analysis computation volume, latency, exposure of personal information, and business impact.

[0051] The above candidate observation behavior can change at least one of the target asset, target account, target service, observer, packet filter, protocol parser, analysis level, sampling rate, observation start time, observation end time, circular buffer request interval, original packet retention period, log lookup range, or identity release level.

[0052] The above adaptive observation planning unit performs selected observation actions based on assets, relationships, or paths included in the above influence subgraph rather than the entire network, and can link additional observation results to observation candidate twin branches and evidence items of situational hypotheses.

[0053] The above system may define at least two of the following: a zero observation level including a normal live state or brief counter; a first observation level including flow and metadata; a second observation level including service, identity, and dependency analysis; a third observation level including protocol deep analysis and heterogeneous log combination; and a fourth observation level including limited original packet or endpoint evidence.

[0054] The above system can gradually increase the observation level of the necessary parts while the evidence completion condition is not met, and return the corresponding parts to the basic observation level when the evidence completion condition is met or the termination condition occurs.

[0055] The above system can decompose a natural language description or structured judgment generated by an artificial intelligence model into multiple judgment propositions and associate at least one of an identifier of supporting evidence, an identifier of counter-evidence, an identifier of unsatisfied evidence, confidence, and a judgment version with each judgment proposition.

[0056] The above response branch simulation execution unit can generate at least two response candidates among observation persistence, observation intensification, rate limiting, session limiting, destination blocking, account or token limiting, terminal isolation, network segment isolation, traffic bypassing, service failover, configuration rollback, cooperative external response, or authorization verification external active response.

[0057] The above-mentioned response branch simulation execution unit generates a counterfactual twin branch corresponding to each response candidate and can calculate at least one of the expected risk reduction, business impact, loss of observability, return cost, execution delay, and authorization satisfaction based on network topology, policies, service dependencies, past response results, models, or rules.

[0058] The above observability may include the ability for at least one of the management channel, evidence collection channel, termination command path, return command path, time synchronization channel, status reply channel, or minimum connection of the core service to be maintained even after the response.

[0059] The above response execution package generation unit can generate a structured response execution package for a selected response candidate that includes at least some of a target, execution function, precondition, authority, policy, approval level, expected effect, verification provider, validity period, automatic termination condition, return action, and failure branch.

[0060] The above corresponding execution package does not execute the natural language or structured plan output by the artificial intelligence model as is, but can be converted to an executable state only after matching it with the registered control functions and the actual capabilities, access rights, policies, and verification means of the target, and passing schema verification and deterministic policy checks.

[0061] The above response execution package generation unit can convert the above response execution package into device-specific execution commands through a firewall, router, switch, network access control device, software-defined network controller, proxy, identity and access management system, endpoint security system, cloud control surface, or service provider interface adapter.

[0062] The above device-specific execution command can be applied as a temporary response overlay including a transaction identifier, reference policy identifier, reference policy version, priority, scope, expiration time, and auto-return condition, without directly overwriting the stored default policy or approval criteria settings.

[0063] The above actual application status verification unit distinguishes and obtains the request corresponding parameter, the execution parameter converted by the adapter, and the parameter actually applied to the control means, and can link them to the same corresponding transaction identifier and execution cycle.

[0064] The above effect verification unit can obtain a post-response observation state from a network observer, a status inquiry interface, or a service status provider that is logically distinct from the provider that received the execution command, and verify at least one of actual risk reduction, normal service maintenance, and observability maintenance.

[0065] The above Twin Promotion / Return Management Department may promote a change in an observation candidate twin branch to a new approval standard twin version only if the change satisfies at least one of the promotion conditions among scheduled change, policy, stabilization period, evidence completion condition, and operator approval.

[0066] The above-mentioned Twin Promotion / Return Management Department does not unconditionally revert to the past default policy at the time of observation or response start upon the termination of a response, but can verify whether the return is complete by re-querying the currently valid latest approval standard twin or the latest default policy and comparing it with the actual return status.

[0067] If the version of an asset state, network relationship, policy, authority, response function, or verification provider changes during response execution, the above system can selectively invalidate only the affected actions and their subsequent actions by comparing the set of impact dependencies of each response action with the current version.

[0068] The above system can generate a patch response execution package using unachieved subgoals, actual application status, effectiveness verification results, and available alternative functions while preserving verified actions and already secured evidence.

[0069] The above system manages identity information as pseudonymized asset or role identifiers, can progressively unlink actual users or accounts based on the risk level of the situation, the purpose of the investigation, access rights, and conditions for evidence completion, and can store identity unlinking and inquiry history as audit records.

[0070] In the case of an authorization-verified external active response, the above response execution package may include an authorization token indicating the ownership or management relationship of the target, contractual delegation, the service provider's formal control authority, public approval, statutory authority, or control test environment.

[0071] The above authorization token may include at least one of an issuer, scope, permitted acts, prohibited acts, validity period, jurisdiction policy, maximum duration, maximum scope of influence, and electronic signature, and may prohibit actual external execution if the authorization token is not verified, the scope is inconsistent, or the validity period has expired.

[0072] Even if an external active response executor is not implemented or is disabled due to product policy, the above system can simulate the same response candidate in the digital twin and assign at least one of SIMULATION_ONLY, RECOMMENDATION_ONLY, or EXECUTION_DENIED execution states.

[0073] The aforementioned external active response is not interpreted to imply intrusion into an information and communications network by a third party without legitimate access rights, data corruption, or the inducement of disruption, and may only be executed within the scope of permitted acts and for targets where lawful authority has been verified. Effects of the invention

[0074] According to the present invention, after constructing a network blueprint verified by initial intensive observation, low-cost change monitoring information is used during normal operation, thereby reducing the amount of communication replication, storage, indexing, and analysis computation compared to a method that constantly maintains the entire original packet and deep protocol analysis.

[0075] According to the present invention, newly observed changes are isolated as candidate branches rather than being immediately merged into the acceptance standard twin, thereby reducing standard contamination in which long-term attacks or incorrect settings are incorporated into the normal standard.

[0076] According to the present invention, since semantic change is determined by utilizing not only the magnitude of the original change but also policies, tasks, scheduled changes, normal cycles, and the scope of influence of dependencies, the amount of alerts that unconditionally treat normal deployments and task changes as abnormal can be reduced.

[0077] According to the present invention, by selecting only the influence subgraphs related to semantic change to increase the level of observation, unnecessary in-depth analysis of assets and communications unrelated to the event and exposure of personal information can be reduced.

[0078] According to the present invention, since unsatisfied evidence of a situational hypothesis is specified and subsequent observations are selected based on expected information gain and cost, judgment uncertainty can be reduced with fewer observations than a method of repeating a fixed high-sensitivity mode.

[0079] According to the present invention, since each judgment proposition is linked with supporting evidence, counter-evidence, and unsatisfied evidence, artificial intelligence explanations can be retrospectively audited and re-verified with other model or policy versions.

[0080] According to the present invention, multiple response candidates are compared in a counterfactual twin branch before actual application, so a response that is likely to maintain normal business and service dependencies while reducing security risks can be selected.

[0081] According to the present invention, by evaluating the management channel, evidence collection channel, and termination and return command path after the response, the problem of losing the continuity of investigation and the ability to return safely due to a strong block can be reduced.

[0082] According to the present invention, since the requested response, the response actually applied to the control means, and the effect verified in reality are distinguished, it is possible to reduce the misjudgment that defense is completed based solely on the command success response.

[0083] According to the present invention, by using a temporary response overlay that does not directly overwrite the default policy and conditionally reverting based on the latest approval criteria, the problem of reverting the latest policy changed by the administrator to a past value during event processing can be reduced.

[0084] According to the present invention, since the candidate state is promoted to the approval standard only when the change is verified to be normal and stable, the reliability of the reference state and synchronization with reality can be maintained together.

[0085] According to the present invention, when the state or policy changes during response execution, only the affected actions are selectively invalidated and verified actions and evidence are preserved, thereby reducing the risk and delay of unnecessarily re-executing the entire response.

[0086] According to the present invention, response outside the management boundary is executed only when the authorization token and permission range are mechanically verified, and is limited to simulated execution or recommendations when there is no authorization or the executor is deactivated, thereby providing both the scalability of external active response and safe default operation.

[0087] Since the present invention can apply the same observation, evidence, and response closed loop not only to security incidents but also to service failures, configuration errors, backup congestion, external API failures, unauthorized service usage, and changes in data flow, network security and operational visibility can be integrated in a single digital twin. Brief explanation of the drawing

[0088] FIG. 1 is a block diagram illustrating the overall configuration of a network digital twin-based adaptive observation and verification defense control system according to one embodiment of the present invention. FIG. 2 is a conceptual diagram illustrating the graph configuration and state metadata of a version-type network digital twin according to one embodiment of the present invention. FIG. 3 is a conceptual diagram illustrating the transition flow of network blueprint generation by initial intensive observation and low-cost change monitoring according to one embodiment of the present invention. FIG. 4 is a conceptual diagram illustrating the separation, promotion, and exclusion flow of an approval criterion twin and an observation candidate twin branch according to one embodiment of the present invention. FIG. 5 is a conceptual diagram illustrating the determination of semantic change of a raw change candidate and the selection of an influence subgraph according to an embodiment of the present invention. FIG. 6 is a conceptual diagram illustrating a flow of changing observation fidelity stepwise in response to evidence completion conditions and unsatisfied evidence according to one embodiment of the present invention. FIG. 7 is a conceptual diagram illustrating the connection relationships of a situational hypothesis, a judgment proposition, supporting evidence, counter-evidence, and unsatisfied evidence according to one embodiment of the present invention. FIG. 8 is a conceptual diagram illustrating the counterfactual twin branching and corresponding utility evaluation of multiple corresponding candidates according to one embodiment of the present invention. FIG. 9 is a conceptual diagram illustrating the configuration of a verification-type response execution package and a temporary response overlay according to an embodiment of the present invention. FIG. 10 is a conceptual diagram illustrating a three-stage verification of a request response state, an actual application state, and an actual effect state according to an embodiment of the present invention. FIG. 11 is a conceptual diagram illustrating the promotion of an observation candidate state to an approval standard and a conditional return to the latest approval standard state according to an embodiment of the present invention. FIG. 12 is a conceptual diagram illustrating influence-dependent selective nullification and partial replanning according to one embodiment of the present invention. FIG. 13 is a conceptual diagram illustrating an authority and safety execution gate of an authority verification type external active response according to an embodiment of the present invention. FIG. 14 is a conceptual diagram illustrating the flow of observation, situation judgment, response simulation execution, and verification for a large-capacity external transmission event according to one embodiment of the present invention. FIG. 15 is a conceptual diagram illustrating the exchange of goal, semantic delta, execution, and verification information between a Network Vertical Contract and an upper artificial intelligence control plane according to an embodiment of the present invention. Specific details for implementing the invention

[0089] Embodiments of the present invention will be described in detail below with reference to the attached drawings. The following embodiments are merely examples to explain the technical concept of the present invention, and the scope of the present invention is not limited to a specific network protocol, a specific security product, a specific artificial intelligence model, a specific cloud, or a specific operating system.

[0090] Identical or corresponding components in each drawing have been assigned the same reference numeral whenever possible. Functionally distinct components may be implemented by one or more processors executing program instructions stored in memory, and may be integrated into the same computing device or distributed across multiple servers, edge nodes, virtual machines, containers, or managed services.

[0091] 1. Definition of Terms

[0092] In this specification, the term “managed network” may mean a wired network, wireless network, virtual network, cloud network, industrial control network, remote work network, service mesh, container network, or a combination thereof that is owned, operated, or entrusted to a company, institution, or other managing entity, or that can be observed or controlled by lawful authority.

[0093] “Management boundary” may refer to the scope of assets and relationships that a managing entity can observe, modify, control access to, recover, or audit, either directly or through delegation. The management boundary is not limited to a physical internal network and may include contracted cloud accounts, remote terminals, and formal control interfaces of Software-as-a-Service tenants and service providers.

[0094] “Network observer” may refer to a logical or physical resource that provides data regarding the status or activity of a managed network. A network observer may include at least one of TAP, SPAN, packet sensors, flow collectors, protocol analyzers such as Zeek or Suricata, DNS, DHCP, VPN, firewall, or proxy logs, network equipment telemetry, endpoint agents, identity systems, application logs, cloud audit logs, and external threat intelligence.

[0095] A “semantic observation object” may refer to a data unit normalized into a common semantic structure from raw observation information of different formats. A semantic observation object may include at least some of the following: subject, action, object, time, path, result, measurement value, change relative to a reference, evidence reference, observation source, reliability, validity period, and personal information classification.

[0096] A “network digital twin” may refer to a virtual model that represents at least some of the assets, identities, services, applications, data, communications, policies, dependencies, and corresponding functions of a reality management network as machine-readable nodes, edges, attributes, and state versions, and is updateable based on real-world observations.

[0097] “Version type” may mean that all or part of the state of a network digital twin is associated with at least one of a state version, effective time, parent version, cause of change, and acknowledgment state, so that a past state, current reference state, or candidate state can be distinguished.

[0098] “Acceptance Criteria Twin” may refer to a version of the network digital twin that has been verified to be in a normal or acceptable state and adopted as a comparison standard. Acceptance criteria may be established by at least one of the following: explicit approval by the operator, consistency with scheduled changes, passage of the stabilization period, policy compliance, and satisfaction of proof completion conditions.

[0099] A “candidate observation twin branch” may refer to a branch that represents a change newly observed in reality but not yet approved as normal or allowed, distinguishing it from the approval standard twin. A candidate branch can store the parent standard version and change deltas without directly overwriting the standard version.

[0100] “Criteria contamination” may refer to a phenomenon where an attack, misuse, error, or unidentified change is incorporated into a normal standard solely because it has been continuously observed, thereby distorting subsequent detection or recovery standards.

[0101] “Change monitoring information” may refer to state summaries, counters, hashes, samples, flows, relationship existence, metadata, or lightweight model outputs obtained at a lower cost than observations that reconstruct the entire acceptance standard twin.

[0102] “Raw change candidate” may refer to the fact itself that an IP address, port, domain, certificate, account, session, traffic volume, configuration hash, service relationship, policy, or other observation differs from the approval criteria.

[0103] “Semantic change” may refer to changes among the original change candidates that are determined to be worthy of further investigation or standard updates in terms of business, policy, normal cycle, scheduled change, data class, service dependency, risk, or operational impact.

[0104] The “Semantic Change Score” may refer to a numerical value or grade calculated by increasing at least one of novelty, policy relevance, operational impact, causal diffusion range, data sensitivity, and observation reliability, and decreasing consistency with scheduled changes, consistency with normal cycles, or approval relationships. The calculation formula may be implemented using rules, statistical models, graph models, machine learning, or a combination thereof.

[0105] “Impact subgraph” may mean a subset of a network digital twin that includes at least some of the assets, identities, services, communication paths, data, policies, observers, and control means directly or indirectly related to the node or edge where the semantic change occurred.

[0106] “Situational hypothesis” may mean a machine-readable candidate judgment to explain the cause, nature, impact, or normality of an observed change or event. Situational hypotheses may include normal change, operational failure, configuration error, policy violation, internal misuse, external attack, account hijacking, or other classifications.

[0107] “Judgment propositions” may refer to individual units of fact or inference that constitute a situational hypothesis. A single natural language explanation can be broken down into multiple judgment propositions, and each judgment proposition can be linked to supporting evidence, counter-evidence, unsatisfied evidence, confidence, and judgment version.

[0108] “Network Vertical Contract” is machine-readable contract information for connecting NetworkGuard to an external control plane as a single independent operational domain, and may include at least some of a local twin version, externally accessible semantic objects, relationships, and states, common semantic projection rules, semantic consumption specifications, observability, response capability, application policy, request authority, verification provider, recovery capability, data sovereignty policy, and contract version.

[0109] The “Upper AI Control Plane” may refer to an optional upper system capable of coordinating cross-domain semantic influence, global operational objectives, global operational invariants, or multi-domain executions by federating local twin and contract information from NetworkGuard and other operational domains. NetworkGuard can independently perform observation, judgment, defense, and verification closed loops even when not connected to the aforementioned Upper AI Control Plane.

[0110] “Evidence items” may refer to individual information requirements necessary to evaluate a situational hypothesis or a judgment proposition. For example, large external transmission volumes, approval status of the target domain, login accounts, file access history, communication paths, actual firewall rules, service response delays, or the number of new sessions after a response may be evidence items.

[0111] “Evidence completion conditions” may refer to conditions defined to enable a computer to evaluate whether one or more evidence items have been sufficiently satisfied. Evidence completion conditions may include at least one of the presence of essential evidence, a confidence or uncertainty threshold, consensus of multiple observers, temporal continuity, absence of falsification, verification of actual state, and agreement of observation application conditions.

[0112] “Unsatisfactory evidence” or “deficit of evidence” may refer to insufficient evidentiary items, causes of deficiency, expected information gains, or residual uncertainty after comparing the currently obtained evidence with the completion conditions.

[0113] “Observation fidelity” may refer to the degree to which identical or related network phenomena are represented with different amounts of information, levels of detail, temporal resolution, or levels of privacy exposure. Observation fidelity may be defined as at least two of the following levels: viability, brief counter, flow, DNS / TLS metadata, service-identity correlation, protocol deep analysis, restricted PCAP, payload, or endpoint evidence.

[0114] “Subsequent observation” may mean an observation in which at least one of the subject, observer, collection scope, protocol analysis level, time interval, retention period, or declassification level is set differently from the previous observation in order to reduce unsatisfactory evidence.

[0115] A “counterfactual twin branch” may refer to a virtual branch used to calculate expected state changes, risk reductions, or side effects by assuming that a specific response has been applied, without actually applying that response to the real network.

[0116] “Response candidate” may mean at least one of observation persistence, observation intensification, rate limiting, session limiting, destination blocking, account or token limiting, endpoint or segment isolation, bypass, failover, configuration recovery, cooperative external response, and authorization-validated external active response.

[0117] “Observability” may refer to the ability to verify the status, risks, actions, and revertability of the management network even after a response. Observability may include management channels, evidence collection channels, status reply channels, time synchronization, shutdown command paths, revert command paths, or minimal connections to core services.

[0118] A “response execution package” may mean a set of data and execution commands structured to execute a response candidate as an actual control means, including at least some of the target, execution function, preconditions, authority, policy, approval, expected effect, verification obligation, failure branch, validity period, and recovery means.

[0119] “Temporary response overlay” may refer to a temporary difference in settings that takes precedence during a response transaction without permanently overwriting the values ​​of the approval reference policy or default settings. A temporary response overlay may include a transaction identifier, reference policy version, priority, expiration time, coverage, and auto-revert conditions.

[0120] “Requested response status” may refer to a configuration or target state that the system has requested to be applied to the control means, “actual application status” may refer to an actual configuration confirmed by re-querying the control means or by an independent state provider, and “verified effect status” may refer to risk reduction, service maintenance, or other results confirmed by subsequent observations of the real network.

[0121] “Promotion” may mean that an observation candidate state is adopted as a new acceptance criterion twin version after satisfying defined conditions. “Regression” may mean removing the ad hoc response overlay and verifying the state after actually applying the currently valid acceptance criterion or the latest default policy.

[0122] “Selective invalidation” may mean determining a version change of an asset, relationship, policy, authority, function, or validation measure referenced by each action of a corresponding execution package, and changing only the affected actions and subsequent actions that depend on them to an unexecutable state.

[0123] “Partial replanning” may mean creating a patch response execution package that replaces or adds only the actions corresponding to failed, invalidated, or incomplete subgoals while preserving verified actions and evidence.

[0124] “Authority token” may refer to machine-verifiable data representing the authority to perform specific actions within a specific period and scope regarding specific targets, including those outside the management boundary. Authority tokens may represent ownership or management relationships, contractual delegation, provider API authority, official authorization, statutory authority, or controlled testing environments.

[0125] “Authority-verified external active response” may refer to a response to a target that may be located outside the management boundary that is executable only when the authorization token is valid and the target, action, duration, scope of influence, and jurisdiction policy match the permissible scope.

[0126] Authorization-verified external active response is not a term that naturally includes intrusion into an information and communications network, data corruption, persistent unauthorized access, or the inducement of service disruption by a third party without legitimate access rights; if authorization is not verified, actual execution may be blocked, and only simulated execution or recommendations may be provided.

[0127] 2. Overall System Configuration

[0128] Referring to FIG. 1, a system (100) according to one embodiment of the present invention may include an observation information integration unit (110), a version-type network digital twin management unit (120), a semantic change and impact subgraph calculation unit (130), an evidence deficit and adaptive observation planning unit (140), a corresponding branch simulation execution and execution package unit (150), an actual application and effect verification unit (160), a twin promotion / return and partial replanning unit (170), one or more network observers (210), one or more corresponding control means or control adapters (310), and an operator terminal (500).

[0129] The observation information integration unit (110) can create semantic observation objects by normalizing the time, asset identifier, session identifier, account identifier, service identifier, and evidence reference of data received from different observation sources. For observation sources with time errors, the time synchronization status and the allowable error range can be stored together.

[0130] The version-type network digital twin management unit (120) can maintain the current or past state of the real network as a graph using semantic observation objects and configuration management information, and can manage the approval standard twin, observation candidate twin branch and counterfactual correspondence branch with different identifiers and states.

[0131] The semantic change and impact subgraph output unit (130) can generate change candidates by comparing low-cost change monitoring information with an approval standard twin, and after determining whether there is a semantic change, select an impact subgraph including related assets, accounts, services, paths, data, and policies.

[0132] The evidence deficit and adaptive observation planning unit (140) manages one or more situational hypotheses and evidence completion conditions for an impact subgraph and can select observation targets and fidelity by generating unsatisfied evidence. In some embodiments, an artificial intelligence model proposes hypotheses and candidate evidence, and a decision rule or schema verifier can determine the observation capabilities and completion conditions that are actually supported.

[0133] The response branch simulation and execution package section (150) can generate at least two of the candidates for observation persistence, observation enhancement, internal defense, service recovery, cooperative external response, and authorization verification external active response, and calculate the expected state of each candidate in a separate branch.

[0134] The actual application and effect verification unit (160) can distinguish and store the request transmitted to the corresponding control means, the value converted by the adapter to apply to the actual device or service, the actual application value confirmed by re-querying, and the effect confirmed by a separate observation source.

[0135] The twin promotion / return and partial replanning unit (170) can promote a candidate branch to an approval standard based on the verification results of the change or response, return to the latest approval standard by removing the temporary response overlay, or generate a patch execution package by nullifying only the affected actions.

[0136] The network observer (210) may be at least one of a passive packet sensor, a flow collector, a log collector, an equipment telemetry interface, an endpoint agent, an identity system, a cloud audit interface, and an external information source. The same observer may support a normal low-cost mode and an event deep mode.

[0137] The response control means or control adapter (310) can be connected to at least one of a firewall, router, switch, NAC, SDN controller, proxy, DNS controller, IAM, EDR, cloud security service, application control plane and provider reporting or blocking API.

[0138] The operator terminal (500) can display an approval criterion twin, candidate branch, evidence satisfaction status, reliability by hypothesis, response candidate, expected impact, authorization verification status, actual application status, effect verification result, and return status. The operator can select approval, denial, modification, suspension, or return depending on the risk level and response type.

[0139] Each component can be implemented as a single server, local appliance, closed-network server, cloud service, or a combination thereof. Sensitive packets and identity information may be maintained on-site or at the edge, while only structured evidence and pseudonymized twin information may be provided to the central server.

[0140] 3. Collection of Heterogeneous Observation Data and Creation of Semantic Observation Objects

[0141] The observation information integration unit (110) can generate unique identifiers in packet or session units, and when different observers represent the same communication or activity, they can be combined into a single semantic observation object or group of linked objects using time, address, port, account, equipment, request identifier and service identifier.

[0142] Since IP addresses and user identities may not be fixed in a one-to-one correspondence, identity linkage reliability can be calculated using at least two of DHCP lease records, VPN sessions, wireless authentication, terminal certificates, EDR device identifiers, operating system logins, and cloud sessions.

[0143] Even in the case of encrypted communication, metadata such as DNS queries, TLS server names, certificates, JA3 or other fingerprints, connection times, transmission and reception volumes, directions, retransmissions, flow cycles, and target autonomous systems may be included in semantic observation objects. This can be extended to more detailed information only if decryption authority or endpoint audit data is available.

[0144] The observation information integration unit (110) can store the location, offset, time interval, hash, and preservation policy where the original data is stored as evidence reference information without storing the raw data for a long period. If the original data exists only in the circular buffer, the expected expiration time can be stored together so that the subsequent observation plan can determine the necessity of preservation.

[0145] A semantic observation object may include a subject, object, action, time, and measurement, such as, for example, “Asset A transmitted 680MB to Service B from 10:02 to 10:18.” The object may include a change relative to a reference, “Service first observed on the equipment,” and supporting Flow, DNS, and TLS evidence references.

[0146] When observation information conflicts with each other, the integration unit (110) can maintain each source, time, reliability, and conflict relationship without arbitrarily discarding one. For example, if DHCP identifies PC-23 but EDR identifies PC-31, the identity mismatch can be a separate evidence item.

[0147] Observers can register their capability information and current status with the system. Capability information may include supported protocols, maximum capture rate, retention buffer length, queryable historical time range, identifiable hierarchy, privacy class, estimated latency, and cost.

[0148] The current observation state may include at least one of connection status, last response time, active filter, active analysis module, sampling rate, packet loss rate, current buffer range, storage space, CPU or GPU load, and permission status.

[0149] The system can store the actual applied observation conditions along with the observation data. For example, if the requested packet filter differs from the actual applied filter, or if packet loss occurs due to sensor overload, the weight of the evidence can be lowered or it can be excluded from satisfying the evidence completion condition.

[0150] 4. Configuration of Versioned Network Digital Twin

[0151] Referring to FIG. 2, the network digital twin may include an asset / identity node (610), a service / data node (620), a policy / defense capability node (630), a relationship / dependency edge (640), and state metadata (650).

[0152] Asset nodes can represent physical servers, virtual machines, containers, user terminals, network equipment, IoT devices, or logical workloads. Identity nodes can represent users, service accounts, API keys, tokens, certificates, sessions, or roles.

[0153] Service nodes can represent web services, databases, repositories, message brokers, DNS, authentication services, SaaS, or external APIs. Data nodes can represent file families, datasets, database tables, secrets, or data classes.

[0154] Policy nodes can represent firewall rules, access policies, authorized SaaS lists, data export policies, business hours policies, deployment policies, privacy processing policies, or response authorization policies. Defense capability nodes can represent blocking, restricting, isolating, bypassing, token revocation, reverting, or reporting functions that can be performed on specific targets.

[0155] Relationship edges may include relationships such as communicating, calling, authenticating, reading data, writing data, owning, using, being distributed, depending on, being policy-applied, being controllable, or being backed by evidence.

[0156] Each state can be associated with a source, first observation time, last observation time, validity period, confidence level, state version, and acceptance status. If multiple sources exist in a single state, source-specific weights and composite confidence levels can be stored.

[0157] The twin management unit (120) can distinguish between observed facts and inferred relationships. For example, actual TCP connections can be stored in the observed state, and the determination that the connection is an ERP service dependency can be stored in the inferred state. The inferred state may include the model used, rules, input evidence, and creation time.

[0158] A tween version can be stored as a full snapshot or as a sequence of change deltas. Change deltas may include additions, deletions, attribute changes, relationship changes, approval status changes, and policy version changes.

[0159] The twin management unit (120) can reconstruct the state at a specific point in time and replay the approval criteria, candidate branch, observation conditions, and response overlay at the time of the event. Through this, the judgment at the time can be re-verified with a new model or policy.

[0160] A digital twin does not have to completely replicate the actual network and can selectively represent states and relationships necessary for observation and response purposes. In some embodiments, only the influential subgraphs may be maintained with high fidelity, while the remaining areas may be represented by summary nodes or aggregation relationships.

[0161] 5. Initial Intensive Observation and Creation of Approval Criteria Blueprint

[0162] Referring to FIG. 3, the system can collect candidates for assets, services, identities, communications, policies, and dependencies by operating multiple observers with relatively high fidelity during the initial intensive observation phase (710) after installation.

[0163] The initial intensive observation period may be terminated based on a fixed number of days, business cycle, batch job cycle, end-of-month processing, or user approval conditions. It can be configured to include at least one business and non-business time, regular backup, update, and normal failover during the period.

[0164] The collected candidate relationships can be compared with at least one of the configuration management database, asset list, approval service list, network settings, deployment records, organizational chart, business person approval, and test transactions.

[0165] The system does not immediately approve a relationship solely on the grounds that the same relationship has been repeatedly observed, but can verify policy compliance, ownership, service provider, data class, and observation reliability.

[0166] The approved status and relationship can be fixed in the approval standard twin version (730). The approval standard version may include the creation period, the observer used, the interval where omission is possible, the operator approval, and known exceptions.

[0167] After the initial intensive observation, the process can be switched to a low-cost change monitoring phase (740). Low-cost change monitoring may use asset viability, brief flow, DNS / TLS metadata, configuration hash, relationship existence, counter, or lightweight embedding.

[0168] Areas without change maintain a low observation level, and deep sample observation can be performed only at predetermined revalidation cycles. This enables the detection of sensor failures or silent changes while reducing resource usage during long-term operation.

[0169] Acceptance standard twins can be managed as versions rather than as an immutable single standard. When a normal change is verified, a new standard version is created, and past versions can be preserved for event recapsulation and rollback.

[0170] 6. Determination of Semantic Change and Prevention of Criteria Contamination

[0171] Referring to FIGS. 4 and 5, if a value different from the approval criteria is found in low-cost change monitoring, a raw change candidate (910) may be generated. The raw change candidate may include new assets, new communication relationships, traffic volume changes, certificate changes, policy changes, account behavior changes, or service delays.

[0172] The meaning change determination unit (130) can evaluate the consistency with the scheduled distribution or inspection, the normal cycle of the same day or time zone, the role of the service, the application policy, the data sensitivity, the time relationship with adjacent changes, and the reliability of the observer, without looking only at the absolute magnitude of the change.

[0173] For example, a 50GB backup occurring at 02:00 every day may have a low semantic volatility score as it corresponds to a normal cycle, despite being a large traffic change. On the other hand, a 500MB transmission to an external storage service, which is the first observed during business hours, may have a high semantic volatility score even though it is relatively small traffic.

[0174] The semantic change score can be calculated using the weighted sum, product, rule tree, Bayesian model, graph neural network, time series model, or a combination thereof for each element. The result can be expressed as a numerical value, a grade, or an indication of whether further investigation is required.

[0175] If a change in meaning is determined, the twin management unit (120) may generate a candidate twin branch (830) without directly changing the approval standard twin. The candidate branch may include a parent standard version, a change delta, an observation source, confidence level, creation time, and promotion condition.

[0176] The status of a candidate branch can have status values ​​such as Unidentified, Under Investigation, Normal Candidate, Faulty Candidate, Threatened Candidate, Awaiting Approval, Denied, or Isolated.

[0177] Even if candidate changes persist for an extended period, they may not be automatically included in the approval criteria if they do not meet the promotion requirements. This structure can reduce criteria contamination caused by slow attacks, backdoors, long-term account misuse, or misconfigurations.

[0178] Even if confirmed as a valid change, it can be promoted to a new approval standard version only after verifying at least one of the following: operational stabilization period, error rate, service health, policy compliance, and approval by the person in charge.

[0179] If a candidate change is determined to be a threat or an error, the candidate branch is not deleted but may be preserved as event evidence, and the reality network may revert to a previous or latest approval reference state or move to a separate safe state.

[0180] 7. Selection of Influence Subgraphs

[0181] The influence subgraph output unit (130) can select only relevant parts based on relationship type, direction, importance, policy scope, time proximity and maximum search depth, instead of extending all directly connected relationships from the starting node or edge where the semantic change occurred indefinitely.

[0182] For example, when new external communication is observed, the source asset, current login account, DNS resolution result, transit firewall, destination service, accessed file or data, related proxy, and core services provided by the asset may be included in the subgraph.

[0183] If a service delay occurs, the delayed service, the calling parent service, dependent databases, shared switch intervals, concurrently occurring bulk transmissions, and recent deployment changes can be included in the subgraph.

[0184] Subgraphs can distinguish between candidate cause directions and influence diffusion directions. Candidate cause directions explore parental dependencies that may exert influence prior to a change, while influence diffusion directions explore subordinate services and users that may be affected by the change.

[0185] The boundary of a subgraph may stop expanding if the expected information gain decreases or if personal information costs, computational costs, or the scope of the investigation exceeds a defined limit.

[0186] Subgraphs can be expanded or contracted based on additional evidence during the investigation. If a new identity or path is confirmed, a related node is added, and if a relationship is disproven by refutation, the corresponding path can be deactivated.

[0187] Improvement in observation levels and preservation of original evidence may be limited to sensors, filters, and time intervals corresponding to the influence subgraph, rather than the entire network.

[0188] 8. Situational Hypothesis, Evidence Completion Condition, and Adaptive Observation

[0189] Referring to FIGS. 6 and 7, the evidence condition management unit (140) can generate one or more situation hypotheses based on the impact subgraph and the type of change. For example, regarding an ERP delay event, “shared section congestion due to backup traffic,” “database processing delay,” and “external authentication API failure” can be generated as competing hypotheses.

[0190] Each hypothesis may include a judgment proposition and evidence items. The judgment propositions of the backup congestion hypothesis may include the existence of a shared path, increased backup traffic, simultaneous occurrence of delays, retransmission or queue congestion, and recovery after backup termination.

[0191] The evidence completion conditions may include essential evidence items, weights of optional evidence items, falsification conditions, confidence thresholds, and time relationships. If essential evidence is missing or the actual observation conditions differ from the request, it may not be determined as completed.

[0192] The system can maintain both supporting and counter-evidence simultaneously. For example, even if a large-volume external transfer exists, the confidence of a policy violation hypothesis can be lowered if the service is on the approval list and aligns with the deployment schedule.

[0193] Unsatisfied evidence can be structured not merely as a “need for further investigation,” but also including what evidence is lacking and why, from which observation sources it can be obtained, and what the expected information gains and costs are.

[0194] The adaptive observation planning unit (140) can generate candidates for obtaining unsatisfactory evidence using observer capability information and current status. The candidates may be DNS log lookup of a specific host, activation of a queue counter of a specific switch port, addition of a specific protocol parser, preservation of a circular buffer of a specific time window, or lookup of endpoint file access history.

[0195] The selection of candidate observation actions can be made by dividing the expected information gain by the costs of communication, storage, computation, latency, privacy, and business impact, or by multi-objective optimization of these values.

[0196] Even if evidence is insufficient, if the urgency of the risk is high, the system can perform low-impact defenses simultaneously with additional observation. For example, it can investigate file access and authorization status while limiting external transmission rates.

[0197] The system can define observation levels from L0 to L4 or higher. Each level may include provided data, retention period, estimated cost, privacy classification, and actionable observers.

[0198] Subsequent observation results can be linked to the same transaction or event identifier as the evidence item of the relevant hypothesis. In the event of actual sensor loss or application failure, the reliability of the evidence can be adjusted.

[0199] Once the conditions for evidence completion are met, unnecessary in-depth observations are immediately terminated, only the scope adopted as case evidence is preserved for the long term, and the remaining temporary originals may be deleted according to policy.

[0200] Termination conditions may include, in addition to the completion of evidence, the maximum investigation time, exhaustion of the resource budget, exceeding of the personal information budget, operator interruption, observer failure, or when further information gain is below a threshold.

[0201] 9. Situation Description Connecting Judgment Propositions and Evidence

[0202] The artificial intelligence model can receive semantic observation objects, influence subgraphs, hypotheses, evidence satisfaction states, and policy information as input to generate natural language situation descriptions, candidate causes, scope of impact, or follow-up actions.

[0203] The output of an artificial intelligence model is not stored as free sentences alone, but can be converted into a structured result including a judgment proposition identifier, proposition type, supporting evidence reference, counter-evidence reference, unfulfilled evidence reference, confidence level, and generative model version.

[0204] For example, “An external transmission larger than usual occurred on PC-23” can be a definitive proposition supported by Flow and reference statistics, while “A business file was exported” can be indicated as an indefinitive proposition because there is no file access data.

[0205] When generating situation descriptions, the system can reflect states such as confirmed, likely, possible, indefinite, and disproven in the sentence. Schemas or post-processing rules can be applied to prevent causal relationships without evidence from being described as facts.

[0206] When an operator selects a specific sentence, the packet segments, flows, logs, status versions, and observation conditions supporting that sentence can be displayed. If the original has been deleted, the deletion time and retention policy can be displayed.

[0207] If a model or policy is changed, the system can re-evaluate the judgment proposition using the same evidence and past twin states, and record the difference between the existing conclusion and the new conclusion, as well as the cause of the difference.

[0208] 10. Correspondence Candidate Generation and Counterfactual Twin Branching

[0209] Referring to FIG. 8, the corresponding branch simulation execution unit (150) can generate multiple counterfactual corresponding branches by duplicating the current candidate twin branch (1210) or applying a change delta.

[0210] Response candidates may include continued observation, additional observation, transmission speed limiting, connection creation rate limiting, blocking specific destinations, blocking specific protocols, temporary restriction of accounts or tokens, terminal isolation, segment isolation, traffic bypassing, switching to alternative services, reverting settings, reporting to external providers, or authorization-verified external active response.

[0211] Each response branch can calculate the communication relationships to be removed or restricted, service dependencies to be affected, management and evidence channels to be maintained, estimated throughput, estimated recovery time, and unresolved risks when the control is applied.

[0212] Simulation can be performed using deterministic network policy computation, graph reachability analysis, queue or traffic models, discrete event simulation, historical correspondences, machine learning models, or a combination thereof.

[0213] The utility of the response may include a reduction in expected risk and an increase in the acquisition of additional information, as well as a reduction in business interruption, loss of observability, exposure of personal information, delays in execution, return costs, and authority uncertainty.

[0214] In cases where the risk is urgent and evidence is incomplete, the system may prioritize rate limiting or partial isolation with a short validity period over strong, permanent containment. This response can serve the dual purpose of slowing the spread of risk while gathering additional evidence.

[0215] Conversely, a response in which key management channels or remote return paths are blocked may be excluded as a violation of safety conditions, even if the amount of risk reduction is high.

[0216] Response candidates can be classified as automatically executable, require operator approval, require multiple approvals, recommendation only, simulation only, or prohibited from execution.

[0217] The operator terminal (500) can display the expected risk reduction, service impact, observability, recovery possibility, authorization status, and uncertainty for each candidate by comparing them. If the operator modifies the parameters, the corresponding branch can be simulated again.

[0218] 11. Selecting Observability-Preserving Responses

[0219] Observability preservation conditions may include whether at least one management channel and at least one independent effect observation path are maintained even after a response. In critical systems, it may be required that the shutdown command path and the return command path exist in different failure domains.

[0220] For example, even if a terminal is moved to an isolated VLAN, the management server, time server, EDR status response, and limited evidence upload path can be allowed, while the general business network and the external internet can be blocked.

[0221] Even if external destinations are blocked, a path to check DNS logs, firewall counters, and the termination status of existing sessions can be maintained. In the event of account suspension, a separate administrator account or emergency recovery account can be maintained.

[0222] The system can identify the management, evidence, and return channels of the pre-response twin and calculate the reachability of each channel at the response branch. If one or more essential channels are lost, it can assign a safety failure indicator to the response candidate.

[0223] Even after the actual response, the status of essential channels can be checked periodically, and if observability decreases below a threshold, the response can be automatically mitigated or restored.

[0224] Observability may include authentication capability, key validity, service health, sufficient bandwidth, and the freshness of status replies, in addition to simple network connectivity.

[0225] 12. Response Execution Packages and Temporary Response Overlays

[0226] Referring to FIG. 9, the selected response candidate can be converted into a response execution package (1310). The response execution package can be used as a deterministic intermediate representation between the intention proposed by the AI ​​and the actual control function.

[0227] The response execution package may include a package identifier, an event identifier, a target identifier, a target state, an execution function identifier, preconditions, authorization conditions, policy conditions, approval levels, expected effects, verification obligations, failure branches, validity periods, automatic termination conditions, and a return function identifier.

[0228] Execution functions can be defined in a registered function dictionary and may include input schemas, supported targets, required permissions, expected change fields, validation providers, and return methods. If the AI ​​proposes a function that does not exist or is not supported, it may not be compiled into an executable state.

[0229] The response execution package can re-verify the target status, policy, permissions, and feature version immediately before execution. If preconditions or versions have changed, it can invalidate the corresponding action or require operator approval again.

[0230] The adapter conversion unit (1320) can convert a common execution package into a specific firewall rule, NAC policy, SDN flow rule, IAM token revocation, EDR isolation command, or cloud security API call.

[0231] The converted command can be applied as a temporary response overlay (1340). The overlay can be applied at a higher priority or a separate policy layer without deleting or overwriting the default policy.

[0232] Overlays can have a lease-based expiration time. Even if communication with the central server is lost, the control adapter or field executor can remove the overlay at the expiration time and return to a safe default state.

[0233] Since the default policy may change during the response, the overlay can record both the base version at the time of start and the current latest base version. When ending, the latest valid base can be applied instead of the past start version.

[0234] When multiple overlays are applied to the same target, they can be combined based on priority, compatibility, and conflict policies. If a conflict is not safely resolved, execution may be halted and approval required.

[0235] The execution receipt (1350) may include the time of command receipt, provider response, converted parameters, actual status inquiry result and error code.

[0236] 13. Three-stage verification of request status, actual application status, and effect

[0237] Referring to FIG. 10, the system can logically distinguish between a request response state (1410), an actual application state (1420), and a verified effect state (1430).

[0238] The request response status may include a goal and request parameters, for example, to move PC-23 to an isolated VLAN. The actual application status may include the results of verifying the actual VLAN and allow rules by re-querying the switch port, NAC session, or terminal network status.

[0239] The verified effectiveness status may include the results of verifying whether new external sessions have been interrupted, whether management channels are maintained, or whether unintended failures of normal services have occurred, using separate Flow sensors, firewall counters, service health, or endpoint status.

[0240] If the command reception is successful but the actual applied value differs, it can be determined as an application failure or partial application. If the actual application matches but the risk persists, it can be determined as an error in the response model or impact relationship.

[0241] The effectiveness verification provider can be logically distinguished from the execution provider whenever possible. Instead of confirming effectiveness solely based on the firewall's own success response, it can be verified through separate network sensors or service status.

[0242] Effectiveness verification can distinguish between immediate effects and effects after stabilization. Even if new sessions are interrupted immediately after the response, the response status can be re-evaluated if an alternative route appears or a service failure occurs after a certain period.

[0243] In the event of a verification failure, the system may perform at least one of retry, alternative control measures, response mitigation, additional observation, return, or operator alert.

[0244] Each validation result is linked to the corresponding execution edge of the tween and can be used as training data to calibrate a simulation model for similar situations in the future.

[0245] 14. Promotion from Candidate status and conditional return to the latest approval criteria

[0246] Referring to Fig. 11, even if a change in an observed candidate branch is determined to be a normal change, it is not immediately promoted to an approval standard, and at least one of a set stabilization period, service health, policy compliance, and operator approval can be additionally verified.

[0247] Once the promotion is complete, the change delta of the candidate branch is combined with the new approval standard version, and the parent, approver, basis for approval, evidence completion status, and effective date of that version can be recorded.

[0248] If a candidate change is determined to be a threat or an error, the candidate branch is preserved in the event history, and the approval criteria may be maintained. Changes to the real network may revert to a previous normal state, the latest approval policy, or a separately defined safe state.

[0249] If an administrator changes the default policy from v21 to v22 after the response begins, unconditionally reverting to v21 upon the response's conclusion may result in the loss of the latest changes. The system can re-query v22 based on the current approval criteria and apply the v22 values ​​by removing only the change fields from the overlay.

[0250] After returning, the status of the actual equipment or service can be queried again and compared with the latest approval criteria. If some fields do not match, the RETURN_PENDING or RETURN_FAILED state can be maintained, and a retry or alert can be triggered.

[0251] If the overlay automatically expires during a communication interruption, the field executor can save the actual return state locally and send a delayed reply to the central system after communication is restored.

[0252] The promotion or return process can also be managed as a separate transaction, and a three-step verification of request, actual application, and effect verification can be applied.

[0253] 15. Selective Invalidation and Partial Replanning

[0254] Referring to FIG. 12, each action of the corresponding execution package may have a set of influence dependencies consisting of a read state, a change state, a reference policy, necessary permissions, an execution function, a verification provider, and a return means.

[0255] Immediately before or during the execution of an action, the current version of an item in the influence dependency set can be compared to the version combined in the package. If a difference exists, it can be determined whether that difference affects the safety or validity of the action.

[0256] Unaffected behaviors and behaviors whose effectiveness has already been verified may be preserved. Only affected behaviors and subsequent unexecuted behaviors that depend on them may be selectively invalidated.

[0257] For example, if the evidence preservation action has been completed and the rate limit has been applied, but the policy is changed before the destination block, only the destination block and subsequent verification can be replanned while maintaining the evidence preservation and the verified rate limit.

[0258] The partial replanning unit (170) can generate a modified action plan by inputting unachieved sub-goals, actual application status, effect verification results, new policies, new authority and available alternative functions into an artificial intelligence model or planner.

[0259] The modification action plan can also be compiled into a patch execution package after undergoing the same schema, functions, permissions, policies, and validation checks as the existing execution package.

[0260] The patch execution package may include behaviors to be replaced, behaviors to be inserted, behaviors to be preserved, new verification obligations, and new version information, and may be configured so that verified behaviors among the preserved behaviors are not unnecessarily re-executed.

[0261] If a safety condition occurs that requires suspending the entire response, all temporary overlays can be removed and the system can return to a safe state, separate from selective invalidation.

[0262] 16. Identity and Privacy Protection

[0263] NetworkGuard is not intended for the primary purpose of personal surveillance and can use the status of assets, services, accounts, data flows, and business processes as the primary unit of observation.

[0264] On general operation screens, asset or role identifiers are displayed instead of the actual username, and the actual identity can be phased out only when there is an approved investigation purpose and authority.

[0265] Identity unlocking levels can be step-by-step, such as IP / MAC linkage, terminal identification, account identification, user identification, and detailed behavioral identification. Only the minimum steps required for evidence completion may be selected.

[0266] The cost of candidate observation behavior may include the level of privacy exposure. If the same evidence can be obtained as metadata, it may take precedence over the collection of the original payload.

[0267] Source packets or user-related logs may be associated with incident identifiers, access rights, retention periods, and deletion policies. History of viewing, exporting, de-identification, and response approvals may be recorded in the audit log.

[0268] When using external AI services, only pseudonymized semantic observation objects and the minimum necessary evidence can be provided instead of sensitive originals, and external transmission can be prevented by using closed networks or local models.

[0269] 17. Authorization-Verification Type External Active Response

[0270] Referring to FIG. 13, a response candidate (1710) for a target outside the management boundary may have an external response state distinct from the internal defense. The system may manage the actual identity of the external target and the reliability related to the attacker separately.

[0271] The mere fact that an external address or domain was used in an attack does not constitute execution authority over a target. Since the target may be a stolen third-party asset or an intermediary, the determination of the attacker and the determination of response authority may have different conditions for completion of evidence.

[0272] The authority verification unit (1720) can verify at least one of ownership or control rights over the target asset, explicit contractual delegation, formal control authority of the target service provider, approval of a law enforcement agency or public institution, statutory authority, cyber training ground, honeynet, or controlled test environment.

[0273] Authorization tokens may include digital signatures, certificates, provider tokens, contract identifiers, authorization document hashes, case numbers, scopes, permitted acts, prohibited acts, validity periods, maximum durations, maximum scope of influence, and jurisdiction policies.

[0274] The system can mechanically verify whether the signature, issuer trust, validity period, target identifier, behavior code, and execution scope of the authorization token match the corresponding execution package.

[0275] Even if the authority is confirmed, the safety and policy verification unit (1730) can examine the possibility of third-party influence, the reliability of the target, the preservation of management, evidence, termination, and return channels, the maximum scope of influence, and prohibited acts.

[0276] If the authorization or safety conditions are not met, the execution gate (1740) may grant the EXECUTION_DENIED status. If the authorization is present but the external executor is not implemented in the product or is disabled by policy, the SIMULATION_ONLY or RECOMMENDATION_ONLY status may be granted.

[0277] Even in embodiments where execution is permitted, external responses may not exceed the targets, actions, durations, and scopes specified in the authorization token. The executor enforces expiration times and automatic termination, and can verify actual application and effects through independent observers.

[0278] Examples of external responses may include the isolation of external cloud assets owned by the managing entity, the suspension of malicious instances via the official API of the contracted hosting provider, authorized DNS sinkholes, provider token revocation, responses within the training ground, or publicly approved restrictive actions.

[0279] Cooperative external response can be performed by delivering evidence packages and blocking requests to hosting providers, ISPs, domain registrars, SaaS providers, or public response agencies without directly controlling external systems.

[0280] The evidence package may include an event identifier, attack-related confidence, time range, target identifier, supporting evidence hash, requested action, and authorization basis. The results of receipt or processing by the counterpart provider may also be distinguished by request, actual application, and effect status.

[0281] An authorization verification-type external active response is an optional embodiment of the present invention, and the initial product may provide only simulation and recommendation interfaces without an external implementer. In such an implementation, the authorization token data structure, execution gate, simulated execution branch, and execution blocking state may be used in the same way.

[0282] The present invention does not require, as a basic embodiment, intrusion into an information and communications network by a third party without legitimate access rights, data corruption, unauthorized persistent access, or causing disruption. Actual actions against external targets may be performed only within the scope of applicable laws, contracts, and public approvals.

[0283] 18. Combination of Artificial Intelligence Models and Deterministic Control

[0284] The artificial intelligence model can be used for at least one of change semantic classification, situational hypothesis generation, evidence candidate generation, natural language explanation, correspondence candidate generation, or simulation parameter estimation.

[0285] The inputs to the artificial intelligence model may include semantic observation objects, relevant parts of the acceptance criterion twin, candidate branch deltas, influence subgraphs, policies, observer capabilities, evidence satisfaction states, and past event results.

[0286] The model's output can be situational hypotheses, evidence items, observation candidates, or correspondence candidates that follow a defined schema. Outputs that fail to pass the schema or do not correspond to actual registered observers or control functions may not be passed to the execution layer.

[0287] The model can be implemented as supervised learning, unsupervised learning, self-supervised learning, graph learning, time series models, large-scale language models, rule-based inference, or a combination thereof.

[0288] The deterministic component can examine authority, policies, target identification, function existence, parameter range, verification obligations, validity periods, and recovery methods. Therefore, even if the AI ​​proposes a response, it may not be actually executed if it fails to pass the deterministic check.

[0289] Model training data can include normal business cycles, normal changes, failures, security incidents, states before and after response, and operator feedback. Reference contamination can be reduced by applying approval standard promotion conditions even before candidate states are incorporated into the normal training data.

[0290] Model versions, prompt or rule versions, input evidence identifiers, and output structures can be stored in the case history. Using this, the same case can be re-evaluated with a different model and differences compared.

[0291] 19. Example A - Large-capacity external transmission

[0292] Referring to Fig. 14, at the normal L1 observation level, the fact that PC-23 (1810) has transmitted 5GB to a new external service can be observed in Flow, DNS, and TLS metadata.

[0293] In the approval criteria twin, there exists a relationship where the asset communicates with approved code repositories and video conferencing services during business hours, but there may not be a relationship with new external services.

[0294] The semantic change determination unit can calculate a high semantic change score by considering novelty, high-volume transmission, external direction, absence of an approval list, and the data access role of the relevant asset.

[0295] The twin management unit can generate candidate branch B7 (1830) without incorporating new communication relationships into the criteria. Situation hypotheses may include authorized business transmission, user error, policy violation, and account or terminal hijacking.

[0296] The evidence completion conditions may include whether the target service is approved, the actual login account, the history of accessing related files, whether the transmission has ended, and approval of changes by the user or person in charge.

[0297] If files and authorization status are insufficient in the current evidence, the system can select AD or VPN sessions, SaaS audit logs, endpoint file access events, and restricted packet circular buffer retention as subsequent observations.

[0298] If the urgency of the risk is high, a low-impact response that limits transmission speed to 80 percent during investigation and a full containment candidate can be simulated together. The speed limit can reduce data export speeds while maintaining evidence collection and user verification channels.

[0299] If confirmed as normal operation and an approved transmission, the candidate relationship can be promoted to a new approval standard version after operator approval and stabilization verification. If identified as a policy violation or threat, destination blocking, session termination, account token restriction, or endpoint isolation may be applied as an approval-based execution package.

[0300] After the response, the system can re-check whether the actual restriction rules have been applied to the firewall or proxy, and verify from a separate Flow sensor whether the transmission volume has decreased and whether management channels and internal communication necessary for business operations are maintained.

[0301] 20. Example B - ERP Response Delay and Backup Traffic

[0302] If the response time of the ERP service exceeds the approval criteria and a large volume of transfers occurs between the NAS and the backup server at the same time, the system can configure a failure hypothesis.

[0303] Hypothesis H1 could be congestion in the shared switch segment, H2 could be database processing delay, and H3 could be external authentication service delay. Different evidence completion conditions can be set for each hypothesis.

[0304] If a shared path is likely based solely on low-cost observations but queue congestion and retransmissions are not confirmed, the system can elevate only the corresponding switch interface queue counter and ERP segment TCP retransmission analysis to L3.

[0305] Simulation candidates may include limiting backup traffic rates, increasing ERP traffic QoS priority, interrupting backup schedules, or database failover.

[0306] Digital twins can predict how much backup completion time increases while reducing ERP path congestion. Database failover can be excluded as it offers low risk reduction and may have a significant impact on business operations.

[0307] After applying approved restriction responses as a temporary overlay, the actual effect can be verified by independently observing ERP response time, queue occupancy, and backup throughput.

[0308] If the effects do not match expectations, the confidence level of H1 can be lowered, and additional observations for H2 or H3 can be selected. If the already applied constraints are safe and verified, they can be maintained, and only the cause analysis of underachievement can be partially replanned.

[0309] 21. Example C - Use of Abnormal Time Zone Accounts and Cross-observation

[0310] If an administrator account is used on a new terminal or in a new network location during non-business hours, the relationships between the account, terminal, VPN, DHCP, and certificate in the identity graph may differ from the approval criteria.

[0311] The system can generate hypotheses regarding account hijacking, authorized urgent operations, automated account misuse, and log identification errors.

[0312] The evidence completion conditions may include the work approval ticket, terminal ownership, multi-factor authentication result, session geographic information, the target of change, and the actual work effect.

[0313] If necessary, limited requests regarding the occupancy of seats or facilities during the relevant time period may be made to separate physical observation systems, such as VisionGuard. Physical observation may provide only minimal evidence, such as presence or authorized entry, rather than full personal identification.

[0314] If there is a high probability of account hijacking, simulated actions such as requiring token re-authentication, restricting sessions, and granting additional approval for critical functions can be executed. Complete account suspension may be a lower priority for phased responses in cases where the impact on business operations is significant.

[0315] After the actual response, session termination, new authentication attempts, impact on business services, and the administrator's recovery path can be verified.

[0316] 22. Example D - Authorization Verification Type External Active Response

[0317] If a managing entity directly owns specific accounts and instances of an external cloud provider but the assets generate attack traffic from addresses outside the management network, the system can generate response candidates outside the management boundary.

[0318] The authorization token may include a cloud account management token, an asset identifier, an allowed action such as instance isolation, a prohibited action such as data deletion, a validity period of 10 minutes, and a digital signature.

[0319] The system compares the target instance identifier with the scope of the authorization token and can evaluate the impact of isolation on customer service and evidence collection channels in the counterfactual branch.

[0320] If permissions are valid and product policies allow it, instances can be isolated via the official cloud API. If external executors are disabled, as in the initial product, it can terminate in the SIMULATION_ONLY state while providing the same mock execution and permission verification results.

[0321] If an external entity is owned by a third party and lacks an authorization token, actual execution may be denied. The system may only generate evidence packages and recommendations to be delivered to hosting providers or public response agencies.

[0322] If it is uncertain whether the target address is an actual attacker asset, external execution can be blocked until both the source-related evidence completion condition and the privilege-related evidence completion condition are satisfied.

[0323] 23. Selective Linkage with Higher AI Control Plane

[0324] Referring to Fig. 15, NetworkGuard operates as an independent system that is not dependent on the upper artificial intelligence control plane, and can optionally be coupled with other operational domains using Network Vertical Contract.

[0325] The Network Vertical Contract may include at least some of, for example, networkDomainId, localTwinVersion, exportedSemanticTypes, semanticMappings, semanticConsumptionSpec, observationCapabilities, responseCapabilities, policyRequirements, authorityRequirements, verificationProviders, recoveryCapabilities, dataResidencyPolicy, createdAt, validUntil, and contractVersion.

[0326] exportedSemanticTypes can represent common semantic fields that can be exposed to the upper control plane, such as service reachability, service identity, communication path, data movement, management channel, risk status, actual application status, or verified response effect, and semanticConsumptionSpec can represent semantic fields and relationship types consumed by NetworkGuard's judgment, policy, response, and verification from other domains.

[0327] The upper AI control plane may provide NetworkGuard with at least some of global operational goals, global operational invariants, semantic deltas generated in other domains, cross-domain influence subgraphs, additional observation requests, execution requests, allowed response ranges, or authorization information.

[0328] Even when receiving a higher-level request, NetworkGuard independently checks the current existence and version of the target object, the functions registered in the Network Vertical Contract, the requested permissions, the local network policy, the verification provider, the recovery means, and the observability retention conditions, and can convert disallowed requests to a denied, modified, simulation-only, or operator-approved state.

[0329] NetworkGuard can return at least some of the requested network state, the state actually applied to the control means, local network effects, domain goal state, side effects on other services, evidence references, local twin versions, and contract versions to the upper AI control plane.

[0330] The upper control plane can validate global goals or global operational invariants by combining responses from NetworkGuard with results from Commerce, VisionGuard, or other domains. However, the global success determination of the upper control plane may not replace the verification of requests, actual implementations, and effects within NetworkGuard.

[0331] If the connection to the upper control plane is disconnected or unavailable, NetworkGuard independently performs observation, advisory, acknowledgment-based defense, and return based on local policies and the current acknowledgment-based network twin, and can return a delayed semantic delta and proof of action after the connection is restored.

[0332] 24. Implementation Examples and Variations

[0333] The observation information integration unit can be implemented using a combination of Apache Kafka or other message brokers, time-series databases, search engines, graph databases, and object repositories. However, it is not limited to specific products or storage technologies.

[0334] A network digital twin can be implemented as an attribute graph, an RDF graph, a relational table, an event sourcing structure, a version control repository, or a combination thereof.

[0335] Semantic change determination and evidence satisfaction calculation can be performed on a central server, while some lightweight change monitoring and packet filtering can be performed on sensors or edge nodes.

[0336] The original packet can be maintained in a field circular buffer without being transmitted to the central system. The central system sends a retention instruction containing an event identifier and a time interval, and the field sensor can extract only the necessary interval and retain it along with the hash.

[0337] The response execution package and observation instructions may include mutual authentication, encryption, digital signatures, replay prevention information, and audit identifiers.

[0338] The system can be configured with multiple servers for high availability, and in the event of a central server failure, the field adapter can independently perform the expiration and safe return of the existing overlay.

[0339] Operators can use policies to classify automation levels into Observation Only, Recommendation Only, Approval Execution, Restricted Execution, and Emergency Automated Defense. Each level may include permitted functions, targets, maximum duration, and approval requirements.

[0340] The same structure can be applied to operational incidents as well as security incidents. For example, changes in dependencies after deployment, backup congestion, DNS errors, authentication service failures, and external API performance degradation can be investigated as candidate branches and evidence completion conditions.

[0341] The present invention can be repeatedly applied to single appliances of small and medium-sized enterprises, distributed sensors of large enterprises, industrial control networks, cloud-native environments, remote work networks, data centers, and managed security services as software or a combination of hardware and software.

[0342] Each embodiment of the present invention is not mutually exclusive, and unless otherwise specified, the configuration of one embodiment may be combined with another embodiment. The order of each step may be changed or performed in parallel to maintain causality and safety conditions. Explanation of the symbols

[0343] 100: Network Digital Twin-based Adaptive Observation and Verified Defense Control System 110: Observation Information Integration Division 120: Versioned Network Digital Twin Management Department 130: Meaning Change and Impact Subgraph Output Section 140: Evidence Deficits and Adaptive Observation Planning Section 150: Corresponding Branch Simulation and Execution Package Section 160: Actual Application and Effect Verification Department 170: Twin Promotion / Return and Partial Replanning Department 210: Network Observer 310: Corresponding control means or control adapter 500: Operator Terminal 610: Asset and Identity Node 620: Service and Data Nodes 630: Policy & Defense Capability Node 640: Relationship and Dependency Edges 650: Status metadata 710: Initial intensive observation 720: Verification of Assets, Services, Policies, and Dependencies 730: Approval Criteria Twin 740: Low-cost change monitoring 750: Maintain default observation level 760: Evaluation of Semantic Change 810: Approval Criteria Twin Version 820: Candidates for observation change 830: Candidate Twin Branch 840: Promotion Condition Judgment Department 850: Quarantine, Return, and Continued Investigation Department 910: Candidate for primitive change 920: Semantic Change Evaluation Department 930: Range of Influence Calculation Section 940: Influence subgraph 1010: Conditions for Completion of Evidence 1020: Completion / Termination Judgment Unit 1110: Contingency Hypothesis 1120, 1130, 1140: Judgment propositions 1150: Supporting Evidence 1160: Counter-evidence 1170: Insufficient evidence 1210: Current candidate twin 1220: Correspondence Utility Evaluation Department 1310: Response execution package 1320: Adapter converter 1330: Managed Controls and Basic Policies 1340: Temporary response overlay 1350: Execution Receipt / Status Reply 1410: Request response status 1420: Actual application status 1430: Verified Effectiveness Status 1510, 1520, 1530: Approval Criteria and Current Default Policy Version 1540: Candidate status promotion section 1550: Latest Approval Criteria Return Section 1610 to 1670: Response Actions and Selective Nullification / Partial Replanning Configuration 1710: External Response Candidate 1720: Authorization Token Verification Department 1730: Safety and Policy Verification Department 1740: External Execution Gate 1750: Execution denied status 1760: Simulation-only state 1770: Execution within allowed range 1810 to 1870: Configuration of a high-capacity external transmission embodiment

Claims

Claim 1 Memory for storing program instructions; one or more processors for executing said program instructions; an observation information integration unit for receiving heterogeneous network observation information from a plurality of network observers; a version-type twin management unit for managing an approval standard network digital twin in which at least some of assets, identities, services, data flows, policies, and dependencies are represented as nodes or edges based on said heterogeneous network observation information, and at least one of an information source, observation time, validity period, reliability, and state version is associated with each state; a semantic change determination unit for calculating raw change candidates by comparing change monitoring information having a lower observation cost than the observation reconstructing the entire state of said approval standard network digital twin with said approval standard network digital twin, and determining whether there is a semantic change based on at least one of scheduled change information, normal cycle information, policy relevance, business impact, dependency impact range, and observation reliability; and a candidate branch management unit for generating an observation candidate twin branch including a reference version identifier of said approval standard network digital twin and a change delta of said raw change candidate, without directly merging the raw change candidate determined to be a semantic change into said approval standard network digital twin. An evidence condition management unit that selects an impact subgraph including at least some of the assets, identities, services, communication paths, data, or policies related to the above semantic change, sets an evidence completion condition including one or more situational hypotheses regarding the above impact subgraph and a satisfaction determination formula for each evidence item required for the above situational hypothesis, and calculates unsatisfied evidence by comparing currently secured evidence with the evidence completion condition; and an adaptive observation planning unit that performs a subsequent observation in which at least one of the observation target, network observer, protocol analysis level, observation time interval, and original packet preservation range is changed according to the unsatisfied evidence, and links the results of the subsequent observation to the observation candidate twin branch and the evidence item.A response branch simulation execution unit that generates a plurality of response candidates corresponding to the above-mentioned situational hypothesis, and selects a response candidate by calculating at least one of risk reduction, service impact, loss of observability, return cost, and authorization satisfaction in a counterfactual twin branch corresponding to each of the plurality of response candidates; a response execution package unit configured to generate the selected response candidate into a response execution package including at least some of a target, execution function, precondition, authorization, policy, approval condition, verification condition, validity period, and return condition, and to apply it to a managed control means as a temporary response overlay that does not directly overwrite the stored approval standard policy; and an actual application / effect verification unit that distinguishes and acquires the requested response state, the response state actually applied to the managed control means, and the response effect confirmed by subsequent observation of the real network. A network digital twin-based adaptive observation and verification defense control system comprising a twin promotion / return management unit that, depending on the evidence completion condition and the verification result of the corresponding effect, promotes the change delta of the observation candidate twin branch to a new approval standard twin version, maintains, modifies, or removes the temporary response overlay to return to the latest approval standard state, or performs partial replanning for failed or incomplete actions while preserving verified actions, wherein the observation information integration unit, the version-type twin management unit, the semantic change determination unit, the candidate branch management unit, the evidence condition management unit, the adaptive observation planning unit, the corresponding branch simulation execution unit, the corresponding execution package unit, the actual application / effect verification unit, and the twin promotion / return management unit are each implemented by one or more processors executing the program instructions stored in the memory. Claim 2 A network digital twin-based adaptive observation and verification defense control system, wherein, in claim 1, the nodes, edges, or states of the approval standard network digital twin further include a state type and a privacy grade that distinguish between an observed state and an inferred state, and at least one of the inferred states is calculated by one or more trained artificial intelligence models receiving at least one of the heterogeneous network observation information, the influence subgraph, or currently secured evidence as input, and the inferred state is linked to the identifier and version of the artificial intelligence model used and the input evidence identifier. Claim 3 A network digital twin-based adaptive observation and verification defense control system, wherein, in claim 1, the version-type twin management unit generates the approval standard network digital twin by comparing information acquired from a plurality of network observers during an initial intensive observation period with at least one of an asset list, an approval service list, configuration information, a distribution record, and a change schedule, and thereafter, utilizes the change monitoring information including at least one of a flow summary, a state counter, a configuration hash, the existence of a relationship, and metadata. Claim 4 A network digital twin-based adaptive observation and verification defense control system, wherein, in claim 1, the semantic change determination unit determines whether there is a semantic change based on a semantic change score in which at least one of novelty, policy relevance, data sensitivity, business impact, dependency diffusion range, and observation reliability is increased, and at least one of scheduled change consistency and normal cycle consistency is decreased. Claim 5 A network digital twin-based adaptive observation and verification defense control system, wherein, in paragraph 1, the twin promotion / return management unit promotes the change delta to a new approval standard twin version only when the observation candidate twin branch matches the scheduled change and satisfies at least one of policy compliance, stabilization period, service health, the evidence completion condition, and operator approval. Claim 6 A network digital twin-based adaptive observation and verification defense control system, characterized in that, in claim 1, the influence subgraph is selected along at least one of service dependency, communication path, identity linkage, policy coverage, data movement relationship, and controllability at the node or edge where the semantic change occurred, and the subsequent observation is limited to a network observer or filter corresponding to the influence subgraph. Claim 7 A network digital twin-based adaptive observation and verification defense control system, wherein, in claim 1, the adaptive observation planning unit calculates the expected information gain or expected uncertainty reduction amount for each of a plurality of candidate observation actions and at least one cost among communication volume, storage volume, analysis computation volume, delay, personal information exposure, and business impact, and selectively switches between at least two observation levels among viability, flow / metadata, service / identity / dependency analysis, protocol deep analysis, and restricted original packets while the evidence completion condition is not satisfied. Claim 8 A network digital twin-based adaptive observation and verification defense control system, wherein, in claim 1, the plurality of response candidates includes at least two of observation persistence, observation intensification, rate limiting, session limiting, destination blocking, account or token limiting, terminal or network segment isolation, traffic bypassing, service failover, and configuration restoration, and the response branch simulation execution unit calculates network reachability or service dependency relationships that change according to each response candidate in the counterfactual twin branch. Claim 9 A network digital twin-based adaptive observation and verification defense control system, wherein, in claim 1, the observability includes at least one of a management channel, an evidence collection channel, a termination command path, a return command path, a time synchronization channel, a status reply channel, and a minimum connection of a core service, and the response branch simulation execution unit excludes response candidates for which essential observability is not maintained from the selection or requires additional approval. Claim 10 A network digital twin-based adaptive observation and verification defense control system, wherein, in claim 1, the temporary response overlay includes at least one of a transaction identifier, a reference policy identifier, a reference policy version, a priority, a scope, an expiration time, and an automatic return condition, and if the default policy version is changed after the response starts, the system retrieves and returns the latest changed approval reference policy instead of the policy at the time of the response start. Claim 11 A network digital twin-based adaptive observation and verification type defense control system, wherein, in claim 1, the actual application and effect verification unit distinguishes from each other the request response parameter, the execution parameter converted by the control adapter, and the actual application parameter re-queried from the managed control means, and verifies the response effect from a network observer or service status provider that is logically distinct from the provider that received the execution command. Claim 12 A network digital twin-based adaptive observation and verification defense control system, wherein, in the first paragraph, the twin promotion and return management unit selectively invalidates only the affected action and the subsequent unexecuted action dependent thereon when at least one version of the assets, relationships, policies, authority, execution functions, verification providers, and return means referenced by each action of the response execution package is changed, and generates a patch response execution package corresponding to the unachieved sub-goals while preserving the verified action and already secured evidence. Claim 13 A network digital twin-based adaptive observation and verification defense control system, characterized in that, in claim 1, the system pseudonyms the actual user identity as an asset or role identifier, incrementally changes the identity release level according to situational risk, investigation purpose, access rights, and unsatisfied evidence, and stores the identity release and inquiry history in the audit log. Claim 14 A network digital twin-based adaptive observation and verification defense control system, characterized in that, in claim 1, the system further includes a control plane linkage unit for communicating with an upper artificial intelligence control plane, wherein the control plane linkage unit is implemented by the one or more processors executing the program instructions stored in the memory, wherein the control plane linkage unit provides a Network Vertical Contract to the upper artificial intelligence control plane that includes at least some of a local twin version, externally accessible common semantic objects, relationships, and states, semantic projection rules, semantic consumption specifications, observation capability, response capability, policy and authority requirements, verification source, and recovery capability, wherein the control plane linkage unit receives at least some of a global operational goal, global operational invariant condition, cross-domain semantic delta, impact subgraph, additional observation request, execution request, or allowable response range from the upper artificial intelligence control plane, and replies to the upper artificial intelligence control plane at least some of the request response status, actual application status, response effect, side effect, evidence reference, local twin version, and contract version obtained by the actual application and effect verification unit, wherein the adaptive observation and verification defense control are performed independently even when not connected to the upper artificial intelligence control plane. Claim 15 A network digital twin-based adaptive observation and verification defense control system, wherein, in paragraph 1, the plurality of response candidates further include external active response candidates for targets outside the management boundary, and the response execution package unit verifies at least one of the issuer of an authorization token indicating ownership or management relationship of the target, contractual delegation, formal control authority of a service provider, public approval, statutory authority or control test environment, target scope, permitted acts, prohibited acts, validity period, and electronic signature, and if the authorization token is not verified, the scope does not match, or the external executer is deactivated, the external active response candidate is not actually executed but is processed in a state of execution refusal, simulation-only, or recommendation-only. Claim 16 A network digital twin-based adaptive observation and verification defense control method performed by one or more processors executing program instructions stored in memory, comprising: a step in which the one or more processors receive heterogeneous network observation information from a plurality of network observers; a step in which the one or more processors generate an acceptance standard network digital twin based on the heterogeneous network observation information, including at least some of assets, identities, services, data flows, policies, and dependencies, and at least one of information source, observation time, validity period, reliability, and state version; a step in which the one or more processors calculate raw change candidates and determine whether the raw change candidates have semantic changes by comparing change monitoring information having a lower observation cost than the observation that reconstructs the entire state of the acceptance standard network digital twin with the acceptance standard network digital twin; a step in which the one or more processors generate an observation candidate twin branch without directly merging the raw change candidates determined to have semantic changes into the acceptance standard network digital twin; and a step in which the one or more processors select an impact subgraph related to the semantic change, set a situational hypothesis, evidence item, and evidence completion condition regarding the impact subgraph, and calculate unsatisfied evidence by comparing currently secured evidence with the evidence completion condition. A step in which one or more processors perform a subsequent observation in which at least one of the observation target, network observer, protocol analysis level, observation time interval, and original packet retention range is changed according to the unsatisfied evidence, thereby updating the observation candidate twin branch and the situation hypothesis; a step in which one or more processors simulate each of a plurality of response candidates in a counterfactual twin branch to calculate at least one of risk reduction, service impact, loss of observability, return cost, and authorization satisfaction, and select a response candidate based on the calculated result;A network digital twin-based adaptive observation and verification defense control method characterized by comprising: a step in which one or more processors generate the selected response candidate into a response execution package including at least some of authority, policy, approval condition, verification condition, validity period, and return condition, and apply it to a managed control means as a temporary response overlay; a step in which one or more processors verify by distinguishing from each other a requested response state, a response state actually applied to the managed control means, and a response effect observed in a real network; and a step in which one or more processors, depending on the verification results of the evidence completion condition and the response effect, promote the observation candidate twin branch to a new approval standard twin version, restore the latest approval standard state by maintaining, modifying, or removing the temporary response overlay, or perform partial replanning for failed or incomplete actions while preserving verified actions. Claim 17 In claim 16, the step of determining whether the meaning has changed is characterized by the one or more processors maintaining raw change candidates that match scheduled change information and normal cycle information in a low-cost change monitoring state, and generating the observed candidate twin branch and the influence subgraph only for raw change candidates whose policy relevance, data sensitivity, business impact, or dependency diffusion range is greater than or equal to a threshold value, in a network digital twin-based adaptive observation and verification defense control method. Claim 18 A network digital twin-based adaptive observation and verification defense control method, wherein the step of performing the subsequent observation is characterized in that one or more processors calculate an expected information gain and at least one cost among communication volume, storage volume, computation volume, delay, and personal information exposure for a plurality of candidate observation behaviors that reduce the unsatisfied evidence, and change at least one of a packet filter, protocol parser, sampling rate, circular buffer request interval, original packet retention period, log lookup range, and identity release level according to the selected candidate observation behavior. Claim 19 A network digital twin-based adaptive observation and verification defense control method, wherein, in claim 16, the step of simulating the plurality of response candidates comprises one or more processors calculating the reachability of at least one of a response post-management channel, an evidence collection channel, a termination command path, and a return command path, and the verification step comprises one or more processors confirming the actual risk reduction and the reachability with an observer logically distinct from the execution provider of the response execution package. Claim 20 A network digital twin-based adaptive observation and verification defense control method, characterized in that, in the case where the selected response candidate is an active response to a target outside the management boundary, the one or more processors verify an authorization token representing ownership, management rights, contractual delegation, service provider authority, public approval, statutory authority, or control test environment for the target, and if the authorization token is not verified, or if the permitted act, target scope, or validity period does not match the response execution package, or if the external implementer is deactivated, the one or more processors do not actually execute the active response but only generate a simulated execution result or a response recommendation. Claim 21 In claim 16, the method further comprises the steps of: one or more processors providing a Network Vertical Contract to an upper AI control plane; one or more processors receiving at least some of a global operational goal, a global operational invariant condition, a cross-domain semantic delta, an influence subgraph, an additional observation request, an execution request, or an allowable response range from the upper AI control plane; one or more processors determining, for a request corresponding to the received information, whether local network policies and permissions are satisfied, whether observability preservation conditions are satisfied, whether a verification provider exists, and whether a return means exists; and one or more processors replying to the upper AI control plane at least some of a request response status, an actual application status, a response effect, a side effect, an evidence reference, a local twin version, and a contract version, wherein the one or more processors independently perform the adaptive observation and verification defense control method even when not connected to the upper AI control plane. Claim 22 A non-transient computer-readable recording medium having a program recorded thereon for executing the method of any one of paragraphs 16 through 21 on a computer.

Images