Method for Generating Security Zone and Conduit Diagrams Based on Analysis of Ship Network Topology, and Computing Device for Performing Same

Abstract

A method for generating security zone and conduit diagrams based on ship network topology analysis and a computing device for performing the same are disclosed. According to the disclosed embodiment, logical connection relationships between assets are automatically inferred based on a ship asset list and network connection data, and based on this, security zones and conduits within the ship are automatically identified to automatically generate diagrams.

Description

Technology Field

[0001] An embodiment of the present invention relates to a method for generating security zone and conduit diagrams based on ship network topology analysis and a computing device for performing the same. Background Technology

[0003] On ships, various Computer Based Systems (CBS), including navigation systems, engine control systems, cargo management systems, communication systems, safety systems, and crew and administration systems, are interconnected and operated via networks. Furthermore, as the digitalization and networking of ships accelerate, the connectivity structure between onboard Information Technology (IT) and Operational Technology (OT) assets is becoming increasingly complex. Consequently, the importance of technologies capable of clearly identifying the connectivity relationships of onboard assets, appropriately separating networks based on functional and physical characteristics, and managing communication paths that meet security requirements is steadily growing. Onboard Computer Based Systems (CBS) can be managed according to a classification system systematically defined in IACS (International Association of Classification Societies) Recommendation No. 190, "Inventory of Computer Based Systems." IACS Rec. 190 classifies onboard computer-based systems by function and categorizes them into three grades—Essential, Important, and Other—based on the importance of each system to ship safety and operation.

[0004] While this CBS classification system serves as core input information for security zone classification, the conventional lack of a systematic mapping method between CBS classification and security zone classification has resulted in manual classification relying on the experience and judgment of personnel. Consequently, it is difficult to ensure consistency in classification results, and there are issues where different classification outcomes are derived depending on the classification entity (ship type, classification society, inspector, etc.).

[0005] In addition, IACS (International Association of Classification Societies) UR (Unified Requirement) E26 requires the separation of security zones and the identification of conduits for onboard computer-based systems, and stipulates that this be documented in the form of network diagrams, etc.

[0006] Traditionally, ship network diagrams have been created manually using general-purpose tools such as Visio and AutoCAD. However, this method fails to synchronize in real-time with asset lists, network connection information, and field inspection results. Consequently, relevant diagrams are not updated in a timely manner even when events such as asset additions or removals, software or firmware changes, VLAN (Virtual Local Area Network) reconfigurations, or firewall policy changes occur. As a result, discrepancies are prone to occur between the actual ship network structure and the documented diagrams, making it difficult to accurately assess the current status during inspection responses or compliance verification processes.

[0007] Furthermore, since ship networks are closely linked not only to logical connections but also to physical compartment structures, it is difficult for inspectors or shipping company representatives to intuitively understand the relationship between security zones and actual locations within the vessel using only simple planar network diagrams. In particular, there is a technical requirement to visualize assets and security zones together based on physical compartments such as the bridge, engine room, cargo area, and accommodation, and to enable hierarchical verification through full vessel, compartment, and individual system views as needed. Prior art literature

[0009] Korean Registered Patent Publication No. 10-2767294 (February 13, 2025) The problem to be solved

[0010] The present invention is intended to provide a method for generating security zone and conduit diagrams based on ship network topology analysis and a computing device for performing the same. means of solving the problem

[0012] A method according to one embodiment of the present invention is performed on a computing device having one or more processors and a memory for storing one or more programs executed by said one or more processors, and comprises the steps of: acquiring asset-related information regarding a Computer Based Systems (CBS) on a ship; generating a topology graph including connection relationships between assets on the ship based on said asset-related information; generating zone classification result information by classifying security zones and conduits according to a pre-established standard on the ship based on said asset-related information and said topology graph; and generating a diagram that visually represents the network security structure of the ship based on said topology graph and said zone classification result information.

[0013] The above topology graph includes nodes and edges, and the step of generating the above topology graph may include the step of setting each asset within the vessel as a node; and the step of generating connection relationships between assets as edges based on the asset-related information.

[0014] The step of generating the topology graph above may include: grouping each asset within the vessel by VLAN (Virtual Local Area Network) identifier and generating Layer-2 edges between assets belonging to the same VLAN; identifying an asset that belongs to multiple VLANs or is connected to multiple network segments as a gateway asset and generating Layer-3 edges between assets belonging to different VLANs or subnets through the gateway asset; and comparing the asset-specific protocol list in the asset-related information and generating protocol-based edges when an intersection of protocol lists exists for a pair of assets within the same security zone.

[0015] The step of generating the above topology graph may include the step of acquiring SNMP (Simple Network Management Protocol) data collected by a Tester; and the step of generating a physical edge between a switch port and an asset based on the SNMP data.

[0016] The above method may further include the step of calculating a reliability score for each edge that has already been created based on one or more of the following: VLAN evidence based on whether it belongs to the same VLAN, protocol evidence based on the intersection of protocol lists between assets or client-server relationships, Address Resolution Protocol (ARP) evidence based on address resolution information between assets, and switch evidence based on switch port connection mapping information.

[0017] The above method may further include the step of classifying the edge as an inferred connection if the calculated confidence score is less than a preset threshold value, and classifying it as a confirmed connection if the calculated confidence score is greater than or equal to the threshold value.

[0018] The step of generating the above-mentioned zone classification result information may include: automatically classifying the security zones of each asset based on one or more of the CBS function classification, system type, VLAN identifier, physical location, and security level objective of each asset; and identifying the communication paths between the security zones as conduits.

[0019] The step of generating the zone classification result information may further include: identifying the CBS importance of assets included in each security zone as one of Essential, Important, and Other; and setting a value corresponding to the highest importance among the identified CBS importances as the security level target of the security zone.

[0020] The step of generating the above diagram may include: loading a basic ship template corresponding to a ship type; generating a basic layout structure of the diagram based on location and ratio information of each compartment included in the basic ship template; marking each security zone as a color-coded area on the compartment of the ship based on the zone classification result information; and visualizing identified conduits between different security zones as connecting lines.

[0021] The step of generating the above diagram includes: a step of generating a ship compartment-based view by placing each asset on a ship drawing so as to correspond to the physical location information and physical compartment of the asset; and a step of generating a hierarchy-based view by classifying each asset into a plurality of layers and arranging them in a vertical direction, and the method may further include a step of selectively providing the ship compartment-based view and the hierarchy-based view or providing them in parallel.

[0022] The step of generating the above hierarchy-based view may include: classifying the hierarchy to which an asset belongs based on one or more of the CBS function classification, system type, communication target, security zone affiliation, and network connection relationship of each asset; and displaying connections between assets within the same hierarchy in a horizontal direction, and connections between different hierarchies in a vertical or diagonal direction.

[0023] The step of classifying the above layers may include: a step of setting a candidate layer range for each CBS function classification of each asset based on a pre-set layer determination rule table; and, if the candidate layer range includes multiple levels, a step of analyzing the system type, communication target, network connection relationship, and functional role of the asset to finally determine a detailed layer within the candidate layer range.

[0024] The above method may further include the step of obtaining security-related policy information including one or more of a firewall policy, a network switch policy, and a policy capable of determining whether inter-zone communication is allowed, which are collected from a tester or a field collection device; and the step of verifying the security policy by comparing the security-related policy information with design-defined security zone and conduit information based on the zone classification result information.

[0025] The step of verifying the security policy may include: generating a list of expected traffic flows for each conduit defined by design, including a departure security zone, a destination security zone, a communication direction to be allowed, a relevant protocol, and port conditions; and classifying the expected traffic flows as matching items or violation items depending on whether a corresponding allowance policy exists within the security-related policy information for each of the expected traffic flows.

[0026] The step of verifying the above security policy may further include: a step of aggregating the number of matches and violations, respectively, between the security zones and conduits defined by design and the security-related policies; and a step of calculating a consistency score by dividing the number of matches by the sum of the number of matches and the number of violations.

[0027] The above method may further include the steps of: detecting changes to assets within the vessel; saving the state before and after the change of the assets within the vessel in the form of snapshots, respectively, and generating difference information between the state before and after the change; and visualizing the difference information in the diagram.

[0028] The above method may further include the steps of: detecting a change in an asset within the vessel and identifying the asset where the change occurred as a reference asset; setting an influence range including an asset directly connected to the reference asset, an adjacent asset belonging to the same network as the reference asset, an asset passing through the reference asset or having a communication relationship with the reference asset, and a security zone to which the reference asset belongs and a security zone adjacent to the security zone; and performing topology graph regeneration, reclassification of security zones and conduits, and diagram update for the influence range.

[0029] A computing device according to one disclosed embodiment comprises: a processor; and a memory for storing one or more programs executed by the processor, wherein the processor performs the operation of acquiring asset-related information regarding a Computer Based Systems (CBS) on board a ship; the operation of generating a topology graph including connection relationships between assets on board the ship based on the asset-related information; the operation of generating zone classification result information by classifying security zones and conduits according to a preset standard on board the ship based on the asset-related information and the topology graph; and the operation of generating a diagram that visually represents the network security structure of the ship based on the topology graph and the zone classification result information. Effects of the invention

[0031] According to the disclosed embodiment, the actual connection structure of a ship network can be mechanically reconstructed by integrating asset information, VLAN information, protocol information, SNMP-based physical connection information, and security-related policy information collected from different sources. Consequently, compared to conventional methods that rely on a single document or manual input to identify the network structure, the inference accuracy and up-to-dateness of the ship network topology can be improved. In particular, the present invention generates a topology graph by multi-layeredly combining Layer-2 connections based on the same VLAN, Layer-3 connections based on gateway assets, protocol-based connections, and physical connections based on switch port mapping. By calculating a reliability score that synthesizes multiple pieces of evidence for each connection, the connection relationships between assets within the ship network can be determined more precisely.

[0032] Furthermore, based on inferred network topology and security zone-conduit information, it is possible to provide both a Purdue model-based hierarchical view and a ship compartment-based physical layout view, thereby enabling an intuitive simultaneous understanding of the logical and physical layout relationships of information assets within the vessel. Consequently, inspectors, classification society auditors, shipping company representatives, and operators can more easily understand the security structure of the ship network and efficiently verify the security zone separation status and the adequacy of communication paths.

[0033] Furthermore, by cross-referencing security-related policy information collected from the actual field with design-defined security zones and conduits, communication paths violating policies, missing permission rules, and unnecessarily permitted rules can be identified, thereby enabling automatic verification of the consistency between design information and field configurations. Consequently, unauthorized communication paths or potential security vulnerabilities can be detected early, and compliance with ship cybersecurity regulations can be determined more quickly and accurately.

[0034] Furthermore, when assets are added, removed, or attributes are modified, the diagram is automatically updated to reflect these changes, and the differences before and after the changes can be visually compared, allowing for the efficient management of the vessel network's change history. As a result, changes in the actual operating environment are promptly reflected in the documentation to maintain up-to-date status, and accurate security zone-conduit information can be continuously provided even after network reconfiguration or maintenance. Brief explanation of the drawing

[0036] FIG. 1 is a block diagram showing the configuration of a device for generating a security zone and conduit diagram based on ship network topology analysis according to one embodiment of the present invention. FIG. 2 is a flowchart illustrating a method for generating a security zone and conduit diagram of a ship according to one embodiment of the present invention. FIG. 3 is a flowchart illustrating a method for generating a topology graph in one embodiment of the present invention. FIG. 4 is a flowchart illustrating the classification process of security zones and conduits according to one embodiment of the present invention. FIG. 5 is a flowchart illustrating the process of generating a diagram according to one embodiment of the present invention. FIG. 6 is a block diagram illustrating a computing environment including a computing device suitable for use in exemplary embodiments. Specific details for implementing the invention

[0037] Hereinafter, specific embodiments of the present invention will be described with reference to the drawings. The following detailed description is provided to facilitate a comprehensive understanding of the methods, apparatuses, and / or systems described herein. However, this is merely illustrative and the present invention is not limited thereto.

[0038] In describing the embodiments of the present invention, detailed descriptions of known technologies related to the present invention are omitted if it is determined that such detailed descriptions may unnecessarily obscure the essence of the present invention. Furthermore, the terms described below are defined in consideration of their functions within the present invention, and these may vary depending on the intentions or practices of the user or operator. Therefore, such definitions should be based on the content throughout this specification. Terms used in the detailed description are intended merely to describe the embodiments of the present invention and should not be limiting in any way. Unless explicitly stated otherwise, expressions in the singular form include the meaning of the plural form. In this description, expressions such as "include" or "comprise" are intended to refer to certain characteristics, numbers, steps, actions, elements, parts thereof, or combinations thereof, and should not be interpreted to exclude the existence or possibility of one or more other characteristics, numbers, steps, actions, elements, parts thereof, or combinations thereof other than those described.

[0039] Additionally, terms such as "first," "second," etc., may be used to describe various components, but said components should not be limited by said terms. These terms may be used for the purpose of distinguishing one component from another. For example, without departing from the scope of the present invention, the first component may be named the second component, and similarly, the second component may be named the first component.

[0041] The present invention relates to a technology that is not merely for displaying ship network information, but for reconstructing the actual network structure based on heterogeneous network information of assets within the ship, automatically deriving security zones and conduits based on the reconstructed structure, and furthermore, automatically verifying consistency with security-related policies.

[0042] According to an embodiment of the present invention, by combining VLAN-based connections, protocol-based connections, SNMP-based physical connections, and reliability evaluation based on multiple pieces of evidence in the network topology inference step, the actual ship network structure can be reflected more accurately than a simple document-based or manual-based method.

[0043] Furthermore, the present invention can automatically detect the difference between the design structure of a ship network and the actual security control status by automatically defining security zones and conduits based on a reconstructed network topology, generating expected traffic flows for each conduit, and comparing them with on-site security-related policies. Accordingly, the present invention can be implemented not merely as a simple information visualization technology for a ship network, but as a technology that technically analyzes and verifies the security separation structure and policy enforcement status of the ship network.

[0045] FIG. 1 is a block diagram showing the configuration of a device for generating a security zone and conduit diagram based on ship network topology analysis according to one embodiment of the present invention.

[0046] Referring to FIG. 1, the diagram generation device (100) may include a data acquisition module (102), a topology inference module (104), a zone classification module (106), a diagram generation module (108), a security policy verification module (110), and a change synchronization module (112).

[0047] The data acquisition module (102) can acquire asset-related information regarding the onboard computer-based systems (CBS). In one embodiment, the onboard computer-based systems may include a navigation communication system, a fire detection and extinguishing system, a propulsion system, a steering system, a power generation and distribution system, a watertight integrity and flood detection system, a lighting system, a safety system, etc.

[0048] Specifically, according to IACS Rec. 190, onboard CBSs are classified according to the following functional classification system. Navigation Systems include the Electronic Chart Display and Information System (ECDIS), radar, Automatic Identification System (AIS), GPS receiver, gyrocompass, speed log, etc., and are essential systems for the safe navigation of the vessel. Propulsion and Machinery Control Systems include main engine control, auxiliary engine control, Power Management System (PMS), ballast control system, and propulsion motor drives. Cargo Management Systems include cargo monitoring, tank level gauges, remote valve control, and cargo refrigeration systems, and their configuration may vary depending on the vessel type. Safety Systems include fire detection and extinguishing systems, gas detection systems, and Emergency Shutdown Systems (ESD). Communication Systems include the Global Maritime Distress and Safety System (GMDSS), Very Small Aperture Terminal (VSAT), satellite communication (SatCom), and onboard telephone systems. Crew Welfare and Administrative Systems include crew internet access, work computers, onboard networks, and CCTV.

[0049] Furthermore, onboard CBSs are classified into three grades—Essential, Important, and Other—based on the importance of each system to ship safety and operation. Essential CBSs are systems whose failure to function directly affects the safe operation of the ship, such as navigation systems, propulsion control systems, steering systems, and safety systems. Important CBSs are systems whose failure to function affects operational efficiency or commercial operations but does not pose an immediate safety threat, such as cargo management systems, engine monitoring systems, and VSAT communications. Other CBSs are systems that do not have a direct impact on ship safety or operation, such as crew welfare systems and administrative computers.

[0050] Here, the CBS classification system can be used as key input information for the security zone classification described below. That is, the security zone to which the asset belongs is primarily determined according to the functional classification of each CBS, and the Security Level Target (SL-T) of the security zone can be set according to the CBS importance grade.

[0051] The data acquisition module (102) can acquire asset list data created during the design phase, network asset data collected by field diagnostic equipment, and manual input data from the manager. At this time, the data acquisition module (102) can record the data source as one of the design, field diagnosis, and manual input. This allows the difference between the design information and the actual operating environment to be reflected in the subsequent processing phase.

[0052] In one embodiment, asset-related information for each asset may include one or more of an asset unique identifier (asset_id), asset name (asset_name), CBS classification code (cbs_id), CBS classification (cbs_category), system type (system_type), manufacturer name (manufacturer), model number (model_number), software version (software_version), firmware version (firmware_version), IP address (ip_address), MAC (Media Access Control) address (mac_address), VLAN (Virtual Local Area Network) identifier (vlan_id), security zone information (security_zone), conduit identifier (conduit_id), network interface type (network_interface), protocol list (protocol_list), physical location (physical_location), installation date, last scan date (last_scan_date), data source (data_source), and CPE string (cpe_string).

[0053] The data acquisition module (102) can standardize the acquired asset-related information so that it can be processed in a subsequent step. For example, the data acquisition module (102) can normalize IP addresses into IPv4 or IPv6 format, standardize MAC address notation into a predetermined format, and convert the protocol list to fit a predefined protocol naming system. In addition, the data acquisition module (102) can normalize network interface types into standard classification values ​​such as Ethernet and Serial, and store CBS classification and system types as code values ​​that can be referenced in a rule table.

[0054] The topology inference module (104) can generate a topology graph containing connection relationships between assets within the vessel based on asset-related information from the onboard computer-based system (CBS). Here, the topology graph consists of nodes and edges. Nodes represent each asset within the vessel. Edges represent connection relationships between assets (logical connection relationships or physical connection relationships).

[0055] The topology inference module (104) can infer the possibility of connectivity between assets step by step by comprehensively referencing asset-specific network interfaces, IP addresses, MAC addresses, VLAN identifiers, protocol lists, physical locations, and data source information from asset-related information. By referencing design phase data and field diagnostic data together, the topology inference module (104) can reflect both the design connectivity and the connectivity observed in the actual operating environment.

[0056] Specifically, the topology inference module (104) can perform Layer-2 adjacency detection as a first step. In the Layer-2 adjacency detection step, the topology inference module (104) can group assets by VLAN identifier (vlan_id) and create Layer-2 edges between assets belonging to the same VLAN. At this time, one or more of the connection type (connection_type), VLAN identifier, and basis for connection creation may be assigned as attribute values ​​to the edges created. The topology inference module (104) may not uniformly confirm pairs of assets belonging to the same VLAN as the same connection, but may first register them as candidate connections so that additional evidence can be collected in a subsequent step. Accordingly, while primarily identifying groups of assets belonging to the same network segment, the actual communication status can be refined in a subsequent inference step.

[0057] Additionally, the topology inference module (104) can perform Layer-3 routing inference as a second step. In the Layer-3 routing inference step, the topology inference module (104) can identify assets that belong to multiple VLANs or are connected to multiple network segments simultaneously as gateway assets. The topology inference module (104) can create Layer-3 edges between assets belonging to different VLANs or different subnets through the gateway assets. The topology inference module (104) can designate the gateway assets as routers or firewall nodes by referring to the equipment type, function, or configuration information of the assets. Accordingly, it is possible to model connection paths or relay points between zones that are difficult to identify based solely on adjacency within the same segment, and to calculate paths crossing zone boundaries more accurately in the subsequent security zone classification and conduit identification steps.

[0058] Additionally, the topology inference module (104) can perform protocol-based connection detection as a third step. In the protocol-based connection detection step, the topology inference module (104) can compare the asset-specific protocol list (protocol_list) and generate a protocol-based edge if there is an intersection of the protocol lists for a pair of assets within the same security zone. At this time, the topology inference module (104) can set the direction of the edge according to the relationship between ports. For example, if the first asset uses a specific ship communication protocol on the transmitting side and the second asset uses the same protocol on the receiving side, the topology inference module (104) can determine that there is a possibility of communication between the two assets. Additionally, if the first asset has a client port and the second asset has a server port, the topology inference module (104) can set the direction of the edge from the client asset to the server asset. By performing protocol-level inference in this way, it is possible to more specifically reflect actual service relationships or traffic flow directions that are difficult to identify based solely on the fact that they exist in the same VLAN.

[0059] Additionally, the topology inference module (104) can perform a physical topology overlay as a fourth step. In the physical topology overlay step, the topology inference module (104) can map the physical connection relationships between the switch ports and the assets using SNMP (Simple Network Management Protocol) data collected by the Tester (e.g., dot1dTpFdbPort of BRIDGE-MIB, dot1qTpFdbPort of Q-BRIDGE-MIB, and STP-MIB information). Accordingly, the topology inference module (104) can generate physical edges between the assets and the switch ports and further identify inter-switch paths or redundancy paths. In particular, by identifying the RSTP (Rapid Spanning Tree Protocol) topology based on STP-MIB, not only normal paths but also standby redundancy paths or bypassable physical paths can be identified. Such physical overlays can reinforce the results of logical connection inference, enabling subsequently displayed diagrams to have higher consistency with the actual field network structure.

[0060] Additionally, the topology inference module (104) may perform reliability scoring as a fifth step. In the reliability scoring step, the topology inference module (104) may perform weighted sum-based reliability scoring to quantitatively evaluate the reliability of each edge. For each edge created, the topology inference module (104) may calculate VLAN evidence based on whether they belong to the same VLAN, protocol evidence based on the intersection of protocol lists between assets or client-server relationships, Address Resolution Protocol (ARP) evidence based on address resolution information between assets, and switch evidence based on switch port connection mapping information, respectively, and calculate a reliability score (confidence_score) by summing the calculated multiple evidence values ​​with a predetermined weight. At this time, the weight may be set, for example, to 0.4 for VLAN evidence, 0.3 for protocol evidence, 0.2 for ARP evidence, and 0.1 for switch evidence, but is not limited thereto and can be changed according to the system environment.

[0061] Here, VLAN evidence may be a value indicating that there is a possibility of Layer-2 proximity between assets belonging to the same VLAN. Protocol evidence may be a value indicating that there is a possibility of actual communication when corresponding protocols are used or when one asset has a client port and another asset has a server port. ARP evidence may be a value indicating whether there is a trace of address resolution between assets. Switch evidence may be a value indicating whether a physical connection relationship is confirmed through SNMP-based switch port mapping results. Accordingly, the topology inference module (104) does not determine the connection relationship based on a single basis, but can evaluate the connection certainty of each edge by comprehensively reflecting multiple different evidences.

[0062] The topology inference module (104) can classify the edge as an inferred connection if the calculated confidence score is less than a preset threshold value, and as a confirmed connection if the calculated confidence score is greater than or equal to the threshold value. For example, if the confidence score is less than 0.5, it can be displayed as a dotted line, and if it is 0.5 or greater, it can be displayed as a solid line. Accordingly, the user can determine not only whether a connection exists but also the basis of inference and the confidence level of the connection.

[0063] In one embodiment, the topology inference module (104) may store connection relationships between assets in the form of topology edge records. The topology edge records may include an edge identifier (edge_id), a source asset identifier (source_asset_id), a target asset identifier (target_asset_id), a connection type (connection_type), a VLAN identifier, a protocol list, a confidence score (confidence_score), a line style (line_style), and whether the connection crosses a zone boundary (crosses_zone_boundary). In this case, the line style (crosses_zone_boundary) may be used as basic information for the zone classification module (106) to determine whether a specific connection is a connection within the same zone or a candidate conduit connecting different zones. Additionally, the line style (line_style) may be used as representation information for the diagram generation module (108) to visualize the connection as a solid line or a dotted line.

[0064] In this way, by combining attribute information of the asset list, VLAN-based segment information, protocol-based communication information, and SNMP-based physical connection information in a multi-layered manner, the connection relationships between network assets within the vessel can be inferred step-by-step, and the results can be generated in the form of a topology graph.

[0065] The zone classification module (106) can classify security zones and conduits according to a pre-established standard based on asset-related information and topology graphs. Here, the standard may refer to the IEC 62443-3-2 standard (industrial cybersecurity standard). The zone classification module (106) can automatically classify the security zones of each asset by comprehensively considering the asset's CBS function classification, system type, VLAN identifier, physical location, and security level objectives, and can identify communication paths between security zones as conduits. Accordingly, assets within the vessel can be systematically grouped in terms of functional homogeneity, security requirement levels, and physical placement, and a basic security structure used in subsequent procedures can be automatically generated. Specifically, the zone classification module (106) can assign security zones by comparing the CBS function classification and system type of each asset against a pre-defined Zone Rule Table. In one embodiment, the zone classification module (106) may assign operational technology (OT) assets of navigation functions to the navigation zone (Zone-NAV), operational technology assets of propulsion or engine functions to the engine zone (Zone-ENG), operational technology assets of cargo management functions to the cargo zone (Zone-CARGO), and operational technology assets of safety systems functions to the safety zone (Zone-SAFETY).

[0066] In addition, the zone classification module (106) may assign IT assets with communication functions to the communication zone (Zone-COMM), IT assets with crew welfare functions to the crew zone (Zone-CREW), IT assets with administrative functions to the administration zone (Zone-ADMIN), and convergent assets with bridge network functions to the mission zone (Zone-BRIDGE). In this way, through primary zone assignment based on the CBS function and system type of each asset, assets with the same business purpose or operational purpose can be grouped into the same security zone first.

[0067] The zone classification module (106) can divide assets belonging to the same security zone into different sub-zones if they belong to different VLANs. For example, the zone classification module (106) can subdivide the ECDIS-related asset group and the Radar-related asset group into separate sub-zones, such as Zone-NAV-ECDIS and Zone-NAV-RADAR, respectively, even if they belong to different VLANs within the same navigation zone (Zone-NAV). Additionally, the zone classification module (106) can separate sub-zones by security level target even if assets within the same security zone have different security level targets (SL-T).

[0068] The zone classification module (106) can detect each edge crossing a zone boundary on a topology graph and generate a conduit representing a communication path between different security zones based on the edge. In this case, if one or more edges crossing a zone boundary represent a communication relationship between the same starting zone and ending zone, the zone classification module (106) can integrate and manage them into a single logical conduit.

[0069] The zone classification module (106) can set the security level of each conduit to the minimum value among the security level targets of both security zones. Additionally, the zone classification module (106) can identify relay or protection equipment, such as firewalls, routers, data diodes, or gateways present on the communication path, as protection assets and link them to the corresponding conduit. Accordingly, the conduit can be defined not as a simple connecting line, but as a communication path between zones that requires a specific security level and is controlled by protection assets.

[0070] In one embodiment, the zone classification module (106) may be configured to automatically assign a Security Level Target to each security zone. The Security Level Target may be set based on the importance of the asset's CBS, functional homogeneity, physical location, and characteristics of other connected zones. For example, a security zone containing essential CBS assets may have a relatively high Security Level Target, while a zone centered on crew convenience functions or administrative functions may have a lower Security Level Target. Additionally, even if assets belong to the same functional group, if they are physically distributed across different zones or have contact with an external network, different Security Level Targets may be assigned according to their characteristics.

[0071] The zone classification module (106) can automatically set the security level target (security_level_target) for each security zone by referring to the CBS classification (cbs_category), CBS function classification, system type (system_type), and security zone assignment result included in each asset record. At this time, the security level target can be expressed as an integer value according to IEC 62443. Specifically, the zone classification module (106) can identify the CBS importance of the assets included in the security zone as Essential, Important, or Other, and set a value corresponding to the relatively higher importance among the identified CBS importances as the default security level target for the security zone. For example, the zone classification module (106) can set a security zone containing one or more essential CBS assets as SL-T 3, a security zone centered on operational technology (OT) assets that do not contain essential CBS assets but perform navigation or engine functions as SL-T 2, and a security zone centered on information technology (IT) assets that perform crew welfare or administrative functions as SL-T 1.

[0072] In addition, when assets of different CBS importance levels are mixed within the same security zone, the zone classification module (106) can secure the minimum security level required for the entire security zone by prioritizing the application of a security level target corresponding to the highest CBS importance level among the assets included in the security zone. Furthermore, the zone classification module (106) can maintain or adjust the basic security level target set as above according to the functional homogeneity of the assets, their physical location, and the characteristics of other connected zones.

[0073] The zone classification module (106) can determine the appropriateness of the zone classification result based on at least one compliance rule. For example, the zone classification module (106) can verify whether all essential assets (essential CBS assets) belong to a security zone above a pre-set security level target, whether one or more protective assets exist in all conduits, and whether a direct path from the crew zone (Zone-CREW) to the safety zone (Zone-SAFETY) does not exist without conduits or protective assets.

[0074] Additionally, the zone classification module (106) may further verify the zone classification results based on rules prohibiting direct connections between specific zones, rules restricting specific types of management protocols, or rules restricting the range of zones where external access is allowed, as needed. If a violation is confirmed as a result of verification, the zone classification module (106) may generate a compliance warning list of the violation and provide it to the user.

[0075] In one embodiment, the zone classification module (106) may store the zone classification results in the form of a security zone data structure and a conduit data structure. Here, the security zone data structure may include a zone identifier (zone_id), a zone name (zone_name), a security level target (security_level_target), a number of assets (asset_count), an array of asset identifiers (asset_ids), an array of VLAN identifiers (vlan_ids), a physical compartment (physical_compartment), a color code (color_code), a list of external conduits (conduits_out), and a compliance status (compliance_status).

[0076] Additionally, each conduit record may include a conduit identifier, a source zone identifier, a destination zone identifier, an applied security level, a protected asset identifier, and a compliance verification result. This structured data can be used in the diagram generation module (108) for rendering color overlays and conduit connection lines by security zone, and can be used as reference information for comparing expected communication flows with actual firewall rules in the security policy verification module (110).

[0077] The diagram generation module (108) can automatically generate a diagram that visually represents the security structure of a ship network based on topology graphs and zone classification result information (including security zone information and conduit information). The diagram generation module (108) can display the connection relationships between assets within the ship, the classification of security zones, the existence of conduits between zones, and the protection status of each conduit on a single screen or multiple linked screens, thereby enabling the user to intuitively understand the logical structure and physical layout structure of the ship network. The diagram generation module (108) can display the generated diagram in conjunction with the security policy verification results described later, thereby enabling it to function as a user interface for checking the security structure beyond simple visualization functions.

[0078] The diagram generation module (108) can generate a ship's exterior or a basic layout. Specifically, the diagram generation module (108) can load a basic ship template (e.g., an SVG template) corresponding to a ship type (vessel_type) and generate a basic layout structure of the diagram based on the location and ratio information of major compartments included in the basic ship template, such as a bridge, engine room, cargo area, and accommodation. At this time, the basic ship template can be stored separately by ship type, such as a bulk carrier, container ship, tanker, and LNG carrier, and the diagram generation module (108) can call a basic ship template corresponding to the selected ship type to automatically arrange the ship's exterior and compartment boundaries. Accordingly, the user can verify the placement of security areas and assets while reflecting the actual compartment structure of the ship.

[0079] The diagram generation module (108) can display each security zone as a color-coded area on the corresponding ship compartment by referring to the zone identifier, zone name, physical compartment, security level, and color code information of each security zone provided from the zone classification result information. For example, the diagram generation module (108) can display the navigation zone in a blue color scheme, the engine zone in a red color scheme, the cargo zone in a green color scheme, the communication zone in a yellow color scheme, the safety zone in a purple color scheme, and the crew or administrative zone in a gray color scheme. In this way, by visually differentiating the functionally separated security zones, the user can easily identify which security zone each asset belongs to and which physical compartment it corresponds to.

[0080] The diagram generation module (108) can arrange assets included within each security zone in the form of icon nodes. Here, the icon nodes may be distinguished according to equipment categories. For example, ECDIS (Electronic Chart Display Information System), Radar, GPS (Global Positioning System), engine controller, PLC (Programmable Logic Controller), switch, and firewall may be distinguished and displayed by different icon shapes or symbols. The diagram generation module (108) can automatically place icon nodes corresponding to assets in appropriate locations within the ship compartments using the physical location information of the assets and the security zone information to which they belong. At this time, at least one of the asset name, IP address, VLAN identifier, system type, security level, or warning status may be displayed together as additional information on the icon node corresponding to the asset.

[0081] The diagram generation module (108) can perform conduit connection line rendering. The diagram generation module (108) can visualize identified conduits between different security zones as connection lines. At this time, the diagram generation module (108) can represent the linear style, color, directionality, and highlighting status of the connection lines differently depending on the attributes of the conduit.

[0082] For example, the diagram generation module (108) may display normal paths protected by firewalls or other protection assets as solid lines. The diagram generation module (108) may display unprotected paths where protection assets are not identified or have low reliability as dotted lines. The diagram generation module (108) may display paths where policy violations or consistency errors are detected as red dotted lines.

[0083] The diagram generation module (108) can represent the direction of travel of the conduit in the form of an arrow, or display icons or identifiers of protected assets associated with the conduit together on the connecting line. Accordingly, the user can immediately visually recognize whether a communication path exists between which security zones, whether the communication path is protected, or whether it is in a violation state.

[0084] The diagram generation module (108) may optionally provide a ship compartment-based view and a hierarchy-based view. The diagram generation module (108) may provide a ship compartment-based view in which assets and security zones are placed based on the physical compartments of the ship. Specifically, when the diagram generation module (108) generates a ship compartment-based view, it may place each asset on the ship drawing so that it corresponds to the physical location information (physical_location) and the physical compartment to which it belongs (physical_compartment).

[0085] The diagram generation module (108) can arrange multiple assets within the same section according to relative positional relationships by referring to at least one of the deck information, port / starboard information, bow / stern direction information, and section name included in the physical location information for each asset. The diagram generation module (108) can arrange assets belonging to the same physical section collectively within a single section area, and can visually distinguish and display them according to equipment category, security zone affiliation, or connection relationship.

[0086] The diagram generation module (108) can provide a hierarchy-based view that reconstructs and displays asset and network relationships in a hierarchical structure from Level 0 to Level 5 according to the Purdue model. When the diagram generation module (108) generates a hierarchy-based view, it can classify assets within the vessel into multiple layers corresponding to the Purdue model and arrange them vertically.

[0087] Here, a standard Purdue model consists of six layers, ranging from Level 0 (physical processes) to Level 5 (enterprise network / external connections), and has a vertical structure in which physical control transitions to information management and external communication functions as one moves from lower to upper layers. However, since this Purdue model was originally designed based on onshore industrial automation environments, it is difficult to accurately reflect system configurations unique to ships (e.g., navigation systems and propulsion control systems coexisting on the bridge in close physical proximity, or OT assets and IT assets sharing the same network segment). Accordingly, the disclosed embodiment proposes a method to systematically connect and map the ship CBS classification system defined in IACS Recommendation No. 190 with the hierarchical structure of the Purdue model.

[0088] Specifically, the diagram generation module (108) collects CBS function classification (cbs_category), system type (system_type), communication target (communication_peer), security zone identifier (security_zone), and network connection relationship (adjacency relation) on the topology graph as input values ​​for each asset, and can determine the Purdue layer of the asset by referring to a pre-stored layer determination rule table. At this time, the layer determination rule table may be a table that cross-maps the CBS function classification of IACS Recommendation No. 190 and the Purdue model referenced in the IEC 62443 series standards, and may include the main candidate layer range and representative asset type for each CBS function classification. Table 1 below is a table showing a layer determination rule table according to an embodiment of the present invention.

[0089] Purdue Level Hierarchy names CBS Function Classification System Type Representative Asset Example Level 0 physical process Promotion / Agency OT Main engine sensor, temperature / pressure transmitter, valve actuator, flow meter, tank level gauge Level 1 Basic control Propulsion / Engine, Cargo Management, Safety System OT PLC, RTU, ESD controller, ballast control unit, cargo valve controller Level 2 Monitoring and control Navigation, Propulsion / Engine, Cargo Management, Safety Systems OT ECDIS, Radar, AIS, Gyrocompass, PMS, Cargo Monitoring WS, Fire Detection Panel, HMI Terminal Level 3 Operations Management Navigation, Propulsion / Engine, Communication OT / IT VDR, Integrated Bridge System (IBS), Integrated Engine Room Control System (ICMS), Data Acquisition Server Level 4 corporate system Communications, Administration IT VSAT router, SatCom terminal, onboard mail server, VPN equipment Level 5 External Connection / DMZ Communications, Seafarer Welfare IT Satellite communication modem, Crew Internet gateway, Shore-to-Ship VPN endpoint

[0090] According to Table 1, Level 0 is the physical process layer, and in a ship environment, field devices such as sensors, valve actuators, temperature / pressure transmitters, flow meters, and tank level gauges that are directly connected to the ship's propulsion system and cargo system correspond to this.

[0091] Level 1 is the basic control layer, and in a marine environment, it includes PLCs (Programmable Logic Controllers), RTUs (Remote Terminal Units), and ESD controllers that directly control Level 0 field equipment in the ship's propulsion and cargo systems. Assets in this layer execute real-time control loops and typically use industrial protocols such as Modbus RTU, Modbus TCP, NMEA 0183, NMEA 2000, IEC 61162, and CANopen.

[0092] Level 2 is the monitoring and control layer, and includes Human-Machine Interface (HMI) terminals, monitoring workstations, and alarm management panels that monitor and control multiple Level 1 controllers. In a marine environment, it includes navigation equipment such as ECDIS, radar, and AIS, as well as Power Management Systems (PMS), Engine Alarm Systems (EAS), and fire detection panels.

[0093] Level 3 is the operational management layer, and it includes systems that collect and aggregate data from multiple Level 2 systems to support operational decision-making. In a marine environment, VDRs, Integrated Bridge Systems (IBS), and Integrated Engine Room Control Systems (ICMS) belong to this layer. Level 3 is the boundary layer where OT (Operational Technology) and IT (Information Technology) converge, and protective equipment such as firewalls or data diodes may be placed between Level 3 and Level 4.

[0094] Level 4 is the enterprise system layer, and in a ship environment, this includes VSAT routers, SatCom terminals, onboard mail servers, VPN equipment, etc., in communication and administrative systems.

[0095] Level 5 is the external connection layer, and in a ship environment, it includes satellite communication modems and crew internet access gateways in communication systems and crew welfare systems, and can perform the role of a DMZ (Demilitarized Zone).

[0096] The diagram generation module (108) can set the main candidate layer range for each CBS function classification based on the layer determination rule table. For example, assets of the Navigation function can be set as a candidate layer of Level 2 or Level 3, assets of the Propulsion / Engine function can be set as a candidate layer of Level 0 to Level 2, and assets of the Cargo function can be set as a candidate layer of Level 0 to Level 2. Additionally, assets of the Safety system function can be set as a candidate layer of Level 1 or Level 2, assets of the Communication function can be set as a candidate layer of Level 4 or Level 5, and assets of the Crew function can be set as a candidate layer of Level 5. Assets of the Administrative function can be set as a candidate layer of Level 4, and assets of the Bridge Network function can be set as a candidate layer of Level 2 or Level 3.

[0097] The diagram generation module (108) can set the security zone corresponding to the horizontal group of each asset and the candidate range of the vertical hierarchy that can be selected within the security zone through the hierarchy determination rule table. This can be shown in Table 2.

[0098] CBS Function Classification 1st security zone Main Purdue Level CBS Importance Basic SL-T Mapping Basis Navigation Zone-NAV 2~3 Essential SL-3 ECDIS·Radar(L2), VDR·IBS(L3) Propulsion Zone-ENG 0~2 Essential SL-3 Sensor (L0), PLC (L1), PMS (L2) Cargo Management Zone-CARGO 0~2 Important SL-2 Gauge (L0), Valve Controller (L1), WS (L2) Safety System (Safety) Zone-SAFETY 1~2 Essential SL-3 ESD controller (L1), detection panel (L2) Communication Zone-COMM 4~5 Important SL-2 VSAT (L4), Satellite Modem (L5) Crew Welfare Zone-CREW 5 Other SL-1 Internet Gateway (L5) Administration Zone-ADMIN 4 Other SL-1 Business PCs, mail servers (L4) Mission Network (Bridge) Zone-BRIDGE 2~3 Essential SL-3 OT / IT Convergence Assets (L2~L3)

[0099] At this time, if the candidate layer range is a single level, the diagram generation module (108) can determine the Purdue layer of the asset to be that single level. On the other hand, if the candidate layer range of each asset includes multiple levels, the diagram generation module (108) can determine the detailed layer within the candidate layer range by further analyzing the asset's system type, communication target, network connection relationship, and functional role.

[0100] Specifically, the diagram generation module (108), in generating a hierarchy-based view, can classify the asset into a horizontal group corresponding to one of the navigation zone (Zone-NAV), engine zone (Zone-ENG), cargo zone (Zone-CARGO), safety zone (Zone-SAFETY), communications zone (Zone-COMM), crew zone (Zone-CREW), administration zone (Zone-ADMIN), and bridge zone (Zone-BRIDGE) based on the CBS function classification of each asset. Here, the horizontal group can be used as a classification criterion reflecting the functional role and security zone affiliation of the asset, and assets belonging to the same CBS function classification can be placed first within the same security zone group.

[0101] The diagram generation module (108) can determine the Purdue Level corresponding to the vertical position of each asset by analyzing the system type and communication relationship for each asset included in the horizontal group. Specifically, the diagram generation module (108) can classify the asset as Level 0 if the asset is field equipment such as a sensor, actuator, or transmitter that is directly connected to a physical process. Additionally, the diagram generation module (108) can classify the asset as Level 1 if the asset is a PLC, RTU, controller, or similar basic control device that directly controls the field equipment.

[0102] Additionally, the diagram generation module (108) may classify the asset as Level 2 if the asset is a Human-Machine Interface (HMI), workstation, monitoring panel, or similar monitoring and control device that provides an interface for monitoring or controlling by an operator. The diagram generation module (108) may classify the asset as Level 3 if the asset is a server, integrated management device, or similar operational management device that collects, aggregates, or manages data from multiple subsystems or multiple control devices. The diagram generation module (108) may classify the asset as Level 4 or Level 5 if the asset performs functions such as interoperability with an external network of the vessel, remote communication, corporate business processing, or external access management.

[0103] At this time, the diagram generation module (108) may determine the Purdue Level by comprehensively considering the asset's system type, communication target, the level of the connected counterpart asset, and the security zone affiliation, rather than determining the hierarchy based only on a single attribute of each asset. For example, even if assets belong to the same institutional zone (Zone-ENG), a sensor directly connected to a physical process may be placed at Level 0, a controller controlling the sensor may be placed at Level 1, and a workstation monitoring the controller may be placed at Level 2. Additionally, an integrated control system that aggregates and manages data from multiple institutional devices may be placed at Level 3 even within the same institutional zone.

[0104] The diagram generation module (108) can determine the final layer according to a predefined priority rule when multiple detailed layer candidates within the candidate layer range are simultaneously satisfied. The diagram generation module (108) can determine the Purdue layer of the asset by first determining whether the asset performs a functional role corresponding to a lower layer, and only if the functional role corresponding to a lower layer is not confirmed, sequentially determining the functional role corresponding to an upper layer.

[0105] For example, the diagram generation module (108) may determine whether there is a direct connection with the field equipment as a first priority, determine whether there is an operator monitoring and control interface as a second priority, determine whether there is a data aggregation and management function for multiple subsystems as a third priority, and determine whether there is an external network or corporate business processing function as a fourth priority.

[0106] The diagram generation module (108) can assign different vertical positions from Level 0 to Level 5 to assets belonging to the same security zone, depending on differences in the functional role and communication structure of each asset, and accordingly, can simultaneously represent horizontal groups by security zone and a vertical hierarchical structure according to the Purdue model on a hierarchy-based view. Through this, the user can intuitively understand not only which security zone each asset belongs to, but also which role the asset performs within the ship network, such as physical control, basic control, surveillance control, operational management, or external linkage.

[0107] In this way, by systematically performing security zone allocation and Purdue model hierarchy placement from CBS function classification, consistency in hierarchy classification, which previously relied on manual work, can be ensured, and reproducible classification results based on the same rules can be derived even for multiple vessels with different ship types and equipment configurations. The diagram generation module (108) can display the connection relationship between upper-level assets and lower-level assets as inter-level connection lines. The diagram generation module (108) can display connections between assets within the same level in a horizontal direction, and connections between different levels in a vertical or diagonal direction.

[0108] The diagram generation module (108) can arrange each asset hierarchically by reflecting that as one moves from a lower layer to an upper layer, the nature of information aggregation and management is strengthened, and as one moves from an upper layer to a lower layer, functions closely related to actual equipment control are performed.

[0109] The diagram generation module (108) may provide a ship compartment-based view and a hierarchy-based view in parallel. In this case, the user can simultaneously check where each asset is physically located within the ship and which control layer or information layer it logically belongs to.

[0110] The diagram generation module (108) can provide a three-stage drill-down structure including a full ship view, a section unit view, and an individual system view, depending on user input. For example, the diagram generation module (108) can display the relationship between the overall ship structure and major security zones on the initial screen, enlarge and display the assets and sub-zone configurations within the section when a specific section is selected, and display the detailed assets and connection relationships belonging to the system in greater detail when a specific system is selected. Conversely, the user can return from the individual system view to the parent view to re-examine the relationship with the overall security structure. Through such drill-down functions, even complex ship networks can be explored step-by-step according to the user's level of interest.

[0111] The diagram generation module (108) can reflect the reliability score or security policy verification results as visual elements of the diagram. For example, the diagram generation module (108) can distinguish and display specific connection lines as solid or dotted lines according to the reliability score calculated by the topology inference module (104). However, it is not limited to this, and colors may also be distinguished and displayed according to the reliability score. The diagram generation module (108) can additionally display warning colors, warning icons, or warning messages on connection lines or zone boundaries according to the security policy verification results of the security policy verification module (110) described later.

[0112] Additionally, the diagram generation module (108) can visually highlight the corresponding area or conduit when the consistency score calculated by the security policy verification module (110) is less than a reference value, thereby clearly presenting to the user the priority review target. Accordingly, the diagram can be implemented as a dynamic visualization means that reflects both network reliability and security consistency status.

[0113] The diagram generation module (108) is linked with the change synchronization module (112) to automatically regenerate the latest diagram reflecting the changed data when asset information or security zone information changes. For example, if the VLAN identifier, security zone affiliation, or physical location of a specific asset changes, the diagram generation module (108) can recalculate the display location of the asset node, security zone color overlay, conduit connection lines, and related warning indicators to immediately reflect the state after the change. Additionally, the diagram generation module (108) can compare the snapshot before the change with the snapshot after the change to highlight newly added assets, deleted assets, moved assets, or changed conduits. This allows the user to quickly visually identify the history of changes in the network structure.

[0114] The security policy verification module (110) can compare security zone and conduit information defined in the design based on zone classification result information with security-related policy information collected in the actual field. The security policy verification module (110) can automatically verify the consistency between security zones and conduits defined in the design and security-related policies in the actual operating environment. Here, the security-related policy information may include firewall policies, network switch policies, and policies that determine whether communication between zones is allowed, which are collected from a tester or other field collection device.

[0115] The security policy verification module (110) can identify policy-violating communication paths, unnecessary allow rules, missing allow rules, or missing block rules by comparing security-related policy information collected from the actual field with security zones and conduits defined in the design. The security policy verification module (110) can output the results in the form of a consistency report or warning information.

[0116] Specifically, the security policy verification module (110) can parse security-related policy information. The security policy verification module (110) can extract a rule identifier, source IP or subnet, destination IP or subnet, port number, protocol, and action information from the security-related policy information. Here, the action information may include allow (ALLOW) or deny (DENY).

[0117] The security policy verification module (110) can identify expected traffic flow for each conduit defined by design. Specifically, the security policy verification module (110) can generate an expected traffic flow list for each conduit defined by design, including a departure security zone, a destination security zone, communication directions to be allowed, relevant protocols, and port conditions.

[0118] The security policy verification module (110) can search for each expected traffic flow to see if a corresponding allowance policy exists within the security-related policy information. If a corresponding allowance policy exists, the security policy verification module (110) classifies it as a match item (Match), and if no corresponding allowance policy exists, it can add it to the violation items as a missing allowance policy (MISSING_ALLOW_RULE). Accordingly, it can automatically check whether inter-zone communication that should be allowed by design is actually reflected in the field policy.

[0119] The security policy verification module (110) can identify an allowance policy among the security policies in the field that lacks a design basis. Specifically, for each policy item where the operation is allowed (ALLOW), the security policy verification module (110) can classify it as an unauthorized allowance policy (UNAUTHORIZED_ALLOW_RULE) and add it to the violation items if the policy item does not correspond to a conduit or expected traffic flow defined in the design. Since such an unauthorized allowance policy implies that communication not defined in the design is allowed in the actual environment, it can be used as information indicating a potential security vulnerability or an unauthorized communication path.

[0120] The security policy verification module (110) can perform special checks regarding security policies. For example, the security policy verification module (110) can verify whether a safety zone (Zone-SAFETY) is protected from non-essential zones by a default-deny policy. The security policy verification module (110) can verify whether there is no direct allowance policy from the crew zone (Zone-CREW) to the navigation zone (Zone-NAV) or organization zone (Zone-ENG). Additionally, the security policy verification module (110) can verify whether management protocols, such as SSH, HTTPS, and SNMP, are restricted to the administration zone (Zone-ADMIN). Through such special checks, beyond the existence of individual allowance rules, it is possible to verify whether the principle of security separation between zones is properly implemented by actual policies.

[0121] The security policy verification module (110) can calculate a consistency score to quantitatively verify the degree of consistency between the security zones and conduits defined in the design and the security-related policies of the actual operating environment. The security policy verification module (110) aggregates the number of matches and violations between the security zones and conduits defined in the design and the security-related policies of the actual operating environment, respectively, and calculates the consistency score as a percentage obtained by dividing the number of matches by the sum of the number of matches and the number of violations. In one embodiment, the security policy verification module (110) may determine that it is PASS if the consistency score is 95% or higher, CONDITIONAL if it is 80% or higher but less than 95%, and FAIL if it is less than 80%.

[0122] The security policy verification module (110) can generate verification results in the form of a consistency report. Here, the consistency report may include a list of matching items, a list of omitted allow policies, a list of unauthorized allow policies, a list of special inspection violations, and a consistency score. Additionally, for each violation item, the consistency report may display the corresponding source zone, destination zone, associated conduit identifier, associated port or protocol, and violation type. The consistency report may be provided to the diagram generation module (108) and used to highlight the violating conduit or violation path.

[0123] The security policy verification module (110) can re-perform consistency verification based on the changed data when asset information, security zone information, conduit information, or field policy information is changed. For example, if a new conduit is created, the security zone affiliation of a specific asset is changed, or security-related policy information collected at the site is updated, the security policy verification module (110) can regenerate the list of expected traffic flows and re-verify whether a corresponding policy exists. Accordingly, policy violation paths or excessively allowed paths that newly occur after the change can be quickly identified.

[0124] The change synchronization module (112) can detect changes occurring in assets or diagrams, etc., and reflect them in the relevant data structure and visualization results in order to maintain consistency among asset-related data, network topology information, security zone information, conduit information, and diagram display information. When an asset is added, deleted, its attributes are changed, or its affiliation with a security zone changes, the change synchronization module (112) can reduce discrepancies between the actual operating environment and the documented security structure by synchronizing the changes bidirectionally between the asset database and the diagram rendering results.

[0125] In one embodiment, the change synchronization module (112) can detect changes by receiving user input or update events from an external system. For example, the change synchronization module (112) can recognize the input as a change event when a user moves a specific asset to another security zone by dragging and dropping it on a diagram, or modifies an IP address, VLAN identifier, or other asset attributes. Additionally, the change synchronization module (112) can determine that the registration of a new asset, the deletion of an existing asset, a change in software version, a change in physical location, or an update of field diagnostic results are notified as changes to be synchronized.

[0126] The change synchronization module (112) can perform reverse synchronization to reflect the detected changes in the asset database. Synchronization is completed within 100ms via WebSocket and can be immediately reflected on other users' screens.

[0127] Specifically, the change synchronization module (112) can convert the results of user operations occurring on the diagram into changes to asset data records and update the asset database in a form including the changed field name, the value before the change, and the value after the change. For example, if a specific asset is moved from the first security zone to the second security zone, the change synchronization module (112) can change the security zone attribute value of the asset, and if the VLAN information of the specific asset is modified, it can change the VLAN identifier value. Accordingly, the results of visual editing performed on the diagram can be reflected in the actual underlying data rather than remaining in a simple display state.

[0128] The change synchronization module (112) can induce reprocessing of the corresponding module based on the changed asset-related data. For example, if at least one of the IP address, VLAN identifier, network interface, protocol list, or physical location is changed, the change synchronization module (112) can cause the topology inference module (104) to recalculate the connection relationships. Additionally, if the CBS function classification, system type, VLAN identifier, security level objective, or physical location is changed, the change synchronization module (112) can cause the zone classification module (106) to recalculate the security zone affiliation and conduit definitions. The change synchronization module (112) can transmit the recalculated results to the diagram generation module (108) to automatically regenerate the diagram in its latest state. In this way, the change synchronization module (112) can perform a linkage control function that ensures changes are reflected in the entire processing pipeline, rather than a simple data storage function.

[0129] In one embodiment, the change synchronization module (112) may perform partial recalculation on only the parts directly related to the changed assets, instead of performing collective reprocessing on all assets and the entire topology within the vessel when a change is detected. Specifically, the change synchronization module (112) may identify the asset where the change event occurred as a reference asset, and set the influence range to include edges directly connected to the reference asset, adjacent assets belonging to the same VLAN or subnet as the reference asset, gateway assets or protection assets passing through the reference asset or having a communication relationship with the reference asset, and the security zone to which the reference asset belongs and security zones adjacent to the security zone. The change synchronization module (112) can prevent unnecessary recalculation of the entire network by performing topology recalculation, zone reclassification, conduit re-identification, and diagram update only on the nodes, edges, security zones, and conduits included in the influence range.

[0130] For example, if an IP address, VLAN identifier, network interface, or protocol list is changed, the change synchronization module (112) may prioritize extracting only the changed asset node and the topology edge connected to the changed asset node, and recalculate Layer-2 adjacency, Layer-3 transit relationship, protocol-based connection, and physical switch port mapping information for the extracted edge. Additionally, the change synchronization module (112) may re-evaluate only the security zone containing the changed asset and the conduit crossing the security zone boundary based on the recalculation result. Accordingly, even if a change in the network attributes of a specific asset occurs, the entire vessel network graph is not regenerated, and connection relationships can be updated only for the local subgraph affected by the change. Since the topology inference module (104) is configured to store connection relationships between assets on an edge basis and the zone classification module (106) is configured to identify conduits from the edge crossing the zone boundary, such local recalculation can be implemented in combination with existing data structures.

[0131] The change synchronization module (112) may be configured to perform full recalculation only when the scope of the change impact extends beyond a preset standard. For example, in the event of a change affecting multiple gateway assets simultaneously, a change in the zone rule table itself, or a large-scale VLAN reconfiguration across multiple security zones, the entire topology graph and the entire zone-conduit structure may be recalculated. On the other hand, for modifications to the attributes of a single asset, asset movement within a single security zone, or changes to a limited number of edges, partial recalculation is applied first, thereby increasing the efficiency of change processing while maintaining the consistency of the latest diagram.

[0132] The change synchronization module (112) can save the state before the change and the state after the change in the form of snapshots, respectively, and generate difference information by comparing the two states. The difference information may include newly added assets, deleted assets, assets whose location has been moved, assets whose attributes have been changed, newly created conduits, removed conduits, or assets whose security zone affiliation has been changed. The change synchronization module (112) can provide the difference information to the diagram generation module (108) to visualize the changed parts using a highlight color, highlight outline, blinking indicator, or a separate change indicator icon. Accordingly, the user can intuitively grasp the structural differences before and after the change.

[0133] The change synchronization module (112) can generate and store an audit log to track the change history. In one embodiment, the audit log may include a timestamp, a user identifier (user_id), an asset identifier (asset_id), a field name, an old value, and a new value. By recording an audit log for each change event, the change synchronization module (112) can make it possible to track who changed which attribute of which asset and when.

[0134] The change synchronization module (112) can reflect the impact of the change results on the compliance status in conjunction. For example, if the security zone affiliation of a specific asset is changed or a specific conduit is newly created, the change synchronization module (112) can cause the security policy verification module (110) to perform consistency verification on the structure after the change again. Accordingly, policy violation paths, missing allow rules, or unauthorized allow rules that newly occurred after the change can be reflected on the latest diagram, and the user can also check the security impact resulting from the change.

[0135] In this specification, the term "module" may refer to a functional and structural combination of hardware for carrying out the technical concept of the present invention and software for driving said hardware. For example, the "module" may refer to a logical unit of a specific code and a hardware resource for executing said code, and does not necessarily refer to physically connected code or a single type of hardware.

[0137] FIG. 2 is a flowchart illustrating a method for generating a security zone and conduit diagram of a ship according to an embodiment of the present invention. Although the method is described in the illustrated flowchart in a plurality of steps, at least some of the steps may be performed in a different order, combined with other steps, omitted, divided into detailed steps, or performed with one or more steps not illustrated added.

[0138] Referring to FIG. 2, the diagram generating device (100) can obtain asset-related information regarding Computer Based Systems (CBS) on board the vessel (S 101).

[0139] Next, the diagram generating device (100) can generate a topology graph including connection relationships between assets within the vessel based on asset-related information (S 103). The topology graph may include nodes representing each asset within the vessel and edges representing connection relationships between assets within the vessel.

[0140] Next, the diagram generating device (100) can generate zone classification result information by classifying security zones and conduits according to pre-set standards within the vessel based on asset-related information and topology graphs (S 105).

[0141] Next, the diagram generating device (100) can generate a diagram that visually represents the network security structure of the vessel based on topology graphs and zone classification result information (S 107).

[0142] Next, the diagram generating device (100) can verify the security policy by comparing the security zone and conduit information defined in the design based on the zone classification result information with the security-related policy information collected at the actual site (S 109).

[0143] Next, the diagram generation device (100) can detect changes to assets within the vessel and reflect them in the relevant data structure and visualization results (S 111). For example, the diagram generation device (100) can reflect the changes in the generation of topology graphs, classification of security zones and conduits, generation of diagrams, etc.

[0145] FIG. 3 is a flowchart illustrating a method for generating a topology graph in one embodiment of the present invention.

[0146] Referring to FIG. 3, the diagram generating device (100) can set each asset within the vessel as a node (S 201).

[0147] Next, the diagram generation device (100) can group each asset within the vessel by VLAN identifier and generate Layer-2 edges between assets belonging to the same VLAN (S 203).

[0148] Next, the diagram generating device (100) identifies an asset that belongs to multiple VLANs or is connected to multiple network segments as a gateway asset, and can create a Layer-3 edge between assets belonging to different VLANs or subnets through the gateway asset (S 205).

[0149] Next, the diagram generating device (100) can generate a protocol-based edge if there is an intersection of the protocol lists for a pair of assets within the same security zone by comparing the asset-specific protocol lists in the asset-related information (S 207).

[0150] Next, the diagram generation device (100) can acquire SNMP (Simple Network Management Protocol) data collected by a Tester and generate a physical edge between the switch port and the asset based on the SNMP data (S 209).

[0151] Next, the diagram generating device (100) can calculate a reliability score based on one or more pieces of evidence that are pre-set for each edge that has been generated (S 211).

[0152] The diagram generating device (100) can calculate a reliability score for each edge that has been generated based on one or more of the following: VLAN evidence based on whether it belongs to the same VLAN, protocol evidence based on the intersection of protocol lists between assets or client-server relationships, Address Resolution Protocol (ARP) evidence based on address resolution information between assets, and switch evidence based on switch port connection mapping information.

[0153] Next, the diagram generating device (100) can classify each edge into an inferred connection or a confirmed connection according to the calculated reliability score (S 213).

[0155] FIG. 4 is a flowchart illustrating the classification process of security zones and conduits according to one embodiment of the present invention.

[0156] Referring to FIG. 4, the diagram generating device (100) can assign security zones by comparing the CBS function classification and system type of each asset with a predefined Zone Rule Table (S 301).

[0157] Next, the diagram generating device (100) can divide assets belonging to the same security zone into different sub-zones if they belong to different VLANs (S 303).

[0158] Next, the diagram generating device (100) can detect each edge crossing a zone boundary on a topology graph and generate a conduit representing a communication path between different security zones based on the edge (S 305).

[0159] Next, the diagram generating device (100) can set a security level target for each security zone and conduit (S 307).

[0160] Next, the diagram generating device (100) can determine the appropriateness of the zone classification result based on a pre-set compliance rule (S 309).

[0162] FIG. 5 is a flowchart illustrating the process of generating a diagram according to one embodiment of the present invention.

[0163] Referring to FIG. 5, the diagram generating device (100) can load a basic ship template corresponding to a ship type (S 401).

[0164] Next, the diagram generating device (100) can generate a basic layout structure of the diagram based on each section and ratio information included in the basic ship template (S 403).

[0165] Next, the diagram generating device (100) can display each security zone as a color-coded area on the corresponding ship compartment (S 405).

[0166] Next, the diagram generating device (100) can visualize the identified conduits between different security zones as connecting lines (S 407).

[0167] Next, the diagram generating device (100) can arrange assets included within each security zone in the form of icon nodes (S 409).

[0169] FIG. 6 is a block diagram illustrating a computing environment (10) including a computing device suitable for use in exemplary embodiments. In the illustrated embodiments, each component may have different functions and capabilities in addition to those described below, and may include additional components in addition to those described below.

[0170] The illustrated computing environment (10) includes a computing device (12). In one embodiment, the computing device (12) may be a device for generating security zone and conduit diagrams based on ship network topology analysis. The computing device (12) may be a diagram generation device (100).

[0171] The computing device (12) includes at least one processor (14), a computer-readable storage medium (16), and a communication bus (18). The processor (14) can cause the computing device (12) to operate according to the exemplary embodiment described above. For example, the processor (14) can execute one or more programs stored in the computer-readable storage medium (16). The one or more programs may include one or more computer-executable instructions, and the computer-executable instructions may be configured to cause the computing device (12) to perform operations according to the exemplary embodiment when executed by the processor (14).

[0172] A computer-readable storage medium (16) is configured to store computer-executable instructions or program code, program data and / or other suitable forms of information. A program (20) stored in the computer-readable storage medium (16) includes a set of instructions executable by a processor (14). In one embodiment, the computer-readable storage medium (16) may be memory (volatile memory such as random access memory, non-volatile memory, or a suitable combination thereof), one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, or other forms of storage media that are accessed by a computing device (12) and capable of storing desired information, or a suitable combination thereof.

[0173] The communication bus (18) interconnects various other components of the computing device (12), including the processor (14) and the computer-readable storage medium (16).

[0174] The computing device (12) may also include one or more input / output interfaces (22) and one or more network communication interfaces (26) that provide interfaces for one or more input / output devices (24). The input / output interfaces (22) and network communication interfaces (26) are connected to a communication bus (18). The input / output devices (24) may be connected to other components of the computing device (12) through the input / output interfaces (22). An exemplary input / output device (24) may include an input device such as a pointing device (such as a mouse or trackpad), a keyboard, a touch input device (such as a touchpad or touchscreen), a voice or sound input device, various types of sensor devices and / or imaging devices, and / or an output device such as a display device, a printer, a speaker and / or a network card. An exemplary input / output device (24) may be included inside the computing device (12) as a component constituting the computing device (12), or it may be connected to the computing device (12) as a separate device distinct from the computing device (12).

[0176] Although representative embodiments of the present invention have been described in detail above, those skilled in the art will understand that various modifications can be made to the above-described embodiments without departing from the scope of the present invention. Therefore, the scope of the present invention should not be limited to the described embodiments, but should be defined by the claims set forth below as well as equivalents thereof. Explanation of the symbols

[0178] 10: Computing Environment 12: Computing device 14 : Processor 16: Computer-readable storage media 18: Communication bus 20 : Program 22 : Input / Output Interface 24 : Input / Output Devices 26 : Network communication interface 100 : Diagram generation device 102: Data Acquisition Module 104: Topology Inference Module 106 : Zone Classification Module 108 : Diagram Generation Module 110: Security Policy Verification Module 112 : Change Synchronization Module

Claims

Claim 1 A method performed on a computing device having one or more processors and memory for storing one or more programs executed by said one or more processors, comprising: acquiring asset-related information regarding Computer Based Systems (CBS) on a ship; generating a topology graph including connection relationships between assets on the ship based on said asset-related information; generating zone classification result information by classifying security zones and conduits on the ship according to a pre-established standard based on said asset-related information and said topology graph; and generating a diagram that visually represents the network security structure of the ship based on said topology graph and said zone classification result information, wherein the step of generating the diagram comprises: loading a basic ship template corresponding to a ship type; generating a basic layout structure of the diagram based on location and ratio information of each compartment included in said basic ship template; marking each security zone as a color-coded area on the compartment of said ship based on said zone classification result information; and visualizing identified conduits between different security zones as connecting lines. Claim 2 A method according to claim 1, wherein the topology graph comprises nodes and edges, and the step of generating the topology graph comprises: setting each asset within the vessel as a node; and generating connection relationships between assets as edges based on asset-related information. Claim 3 A method according to claim 2, wherein the step of generating the topology graph comprises: grouping each asset within a vessel by a Virtual Local Area Network (VLAN) identifier and generating Layer-2 edges between assets belonging to the same VLAN; identifying an asset that is simultaneously affiliated with a plurality of VLANs or connected to a plurality of network segments as a gateway asset and generating Layer-3 edges between assets belonging to different VLANs or subnets via the gateway asset; and comparing the asset-specific protocol list in the asset-related information and generating protocol-based edges when an intersection of the protocol lists exists for a pair of assets within the same security zone. Claim 4 The method of claim 2, wherein the step of generating the topology graph comprises: acquiring Simple Network Management Protocol (SNMP) data collected by a Tester; and generating a physical edge between a switch port and an asset based on the SNMP data. Claim 5 The method of claim 2 further comprises the step of calculating a reliability score for each previously generated edge based on one or more of VLAN evidence based on whether it belongs to the same VLAN, protocol evidence based on the intersection of protocol lists between assets or client-server relationships, Address Resolution Protocol (ARP) evidence based on address resolution information between assets, and switch evidence based on switch port connection mapping information. Claim 6 The method of claim 5 further comprises the step of classifying the edge as an inferred connection when the calculated reliability score is less than a preset reference value, and classifying it as a confirmed connection when the calculated reliability score is greater than or equal to the reference value. Claim 7 The method of claim 1, wherein the step of generating zone classification result information comprises: automatically classifying security zones of each asset based on one or more of the CBS function classification, system type, VLAN identifier, physical location, and security level objective of each asset; and identifying communication paths between security zones as conduits. Claim 8 A method performed on a computing device having one or more processors and a memory for storing one or more programs executed by said one or more processors, comprising: acquiring asset-related information regarding Computer Based Systems (CBS) on a ship; generating a topology graph including connection relationships between assets on the ship based on said asset-related information; generating zone classification result information by classifying security zones and conduits according to a pre-established standard on the ship based on said asset-related information and said topology graph; and generating a diagram that visually represents the network security structure of the ship based on said topology graph and said zone classification result information, wherein the step of generating zone classification result information further comprises: identifying the CBS importance of assets included in each security zone as one of Essential, Important, and Other; and setting a value corresponding to the highest importance among said identified CBS importances as the security level target of said security zone. Claim 9 delete Claim 10 A method performed on a computing device having one or more processors and a memory for storing one or more programs executed by said one or more processors, comprising: acquiring asset-related information regarding Computer Based Systems (CBS) on a ship; generating a topology graph including connection relationships between assets on the ship based on said asset-related information; generating zone classification result information by classifying security zones and conduits according to a pre-established standard on the ship based on said asset-related information and said topology graph; and generating a diagram that visually represents the network security structure of the ship based on said topology graph and said zone classification result information, wherein the step of generating said diagram comprises: generating a ship compartment-based view by placing each asset on a ship drawing so as to correspond to the physical location information and physical compartment of the asset; and generating a hierarchy-based view by classifying each asset into a plurality of layers and arranging them in a vertical direction, and the method further comprises the step of selectively providing the ship compartment-based view and the hierarchy-based view or providing them in parallel. Claim 11 The method of claim 10, wherein the step of generating the layer-based view comprises: classifying the layer to which the asset belongs based on one or more of the CBS function classification, system type, communication target, security zone affiliation, and network connection relationship of each asset; and displaying connections between assets within the same layer in a horizontal direction, and connections between different layers in a vertical or diagonal direction. Claim 12 The method of claim 11, wherein the step of classifying the layer comprises: a step of setting a candidate layer range for each CBS function classification of each asset based on a pre-set layer determination rule table; and a step of finally determining a detailed layer within the candidate layer range by analyzing the system type, communication target, network connection relationship, and functional role of the asset when the candidate layer range includes a plurality of levels. Claim 13 The method of claim 1, wherein the method further comprises: a step of obtaining security-related policy information including one or more of a firewall policy, a network switch policy, and a policy capable of determining whether inter-zone communication is allowed, collected from a tester or a field collection device; and a step of verifying the security policy by comparing the security-related policy information with design-defined security zone and conduit information based on the zone classification result information. Claim 14 The method of claim 13, wherein the step of verifying the security policy comprises: generating a list of expected traffic flows including a departure security zone, a destination security zone, a communication direction to be allowed, a related protocol, and port conditions for each conduit defined by design; and classifying the expected traffic flows as a match or a violation depending on whether a corresponding allowance policy exists within the security-related policy information for each of the expected traffic flows. Claim 15 The method of claim 14, wherein the step of verifying the security policy further comprises: a step of aggregating the number of matches and the number of violations between the security zone and conduit defined by design and the security-related policy, respectively; and a step of calculating a consistency score by dividing the number of matches by the sum of the number of matches and the number of violations. Claim 16 The method of claim 1 further comprises the steps of: detecting a change to an asset within the vessel; saving a state before the change and a state after the change of the asset within the vessel in the form of snapshots, respectively, and generating difference information between the state before the change and the state after the change; and visualizing the difference information by reflecting it in a diagram. Claim 17 A method performed on a computing device having one or more processors and memory for storing one or more programs executed by said one or more processors, comprising: acquiring asset-related information regarding Computer Based Systems (CBS) on a ship; generating a topology graph including connection relationships between assets on the ship based on said asset-related information; generating zone classification result information by classifying security zones and conduits according to a pre-established standard on the ship based on said asset-related information and said topology graph; and generating a diagram visually representing the network security structure of the ship based on said topology graph and said zone classification result information, wherein the method comprises: detecting changes to said assets on the ship and identifying the asset where the change occurred as a reference asset; setting an influence range including assets directly connected to said reference asset, adjacent assets belonging to the same network as said reference asset, assets passing through said reference asset or having a communication relationship with said reference asset, and a security zone to which said reference asset belongs and a security zone adjacent to said security zone. A method further comprising the steps of regenerating a topology graph, reclassifying security zones and conduits, and updating a diagram for the above-mentioned influence range. Claim 18 A computing device comprising: a processor; and a memory for storing one or more programs executed by said processor, wherein the processor performs the operation of acquiring asset-related information regarding Computer Based Systems (CBS) on a ship; the operation of generating a topology graph including connection relationships between assets on the ship based on said asset-related information; the operation of generating zone classification result information by classifying security zones and conduits according to a pre-established standard on the ship based on said asset-related information and said topology graph; and the operation of generating a diagram that visually represents the network security structure of the ship based on said topology graph and said zone classification result information, wherein the operation of generating the diagram includes the operation of loading a basic ship template corresponding to a ship type; the operation of generating a basic layout structure of the diagram based on location and ratio information of each compartment included in said basic ship template; the operation of marking each security zone as a color-coded area on the compartment of said ship based on said zone classification result information; and the operation of visualizing identified conduits between different security zones as connecting lines. Claim 19 A computer program stored on a non-transitory computer-readable storage medium, wherein the computer program comprises one or more instructions, and when the instructions are executed by a computing device having one or more processors, the computing device is configured to perform the following steps: acquiring asset-related information regarding Computer Based Systems (CBS) on a ship; generating a topology graph including connection relationships between assets on the ship based on the asset-related information; generating zone classification result information by classifying security zones and conduits on the ship according to a pre-established standard based on the asset-related information and the topology graph; and generating a diagram that visually represents the network security structure of the ship based on the topology graph and the zone classification result information, wherein the step of generating the diagram comprises: loading a basic ship template corresponding to a ship type; generating a basic layout structure of the diagram based on location and ratio information of each compartment included in the basic ship template; and marking each security zone as a color-coded area on the compartment of the ship based on the zone classification result information. A computer program stored on a non-transient computer-readable storage medium, comprising the step of visualizing identified conduits between different security zones as connecting lines.

Images