WO2018169291A1 - 네트워크 보안 기능에 대한 등록 인터페이스 정보 모델 - Google Patents

네트워크 보안 기능에 대한 등록 인터페이스 정보 모델 Download PDF

Info

Publication number
WO2018169291A1
WO2018169291A1 PCT/KR2018/002954 KR2018002954W WO2018169291A1 WO 2018169291 A1 WO2018169291 A1 WO 2018169291A1 KR 2018002954 W KR2018002954 W KR 2018002954W WO 2018169291 A1 WO2018169291 A1 WO 2018169291A1
Authority
WO
WIPO (PCT)
Prior art keywords
nsf
management system
security
i2nsf
instance
Prior art date
Application number
PCT/KR2018/002954
Other languages
English (en)
French (fr)
Inventor
정재훈
현상원
우상욱
여윤석
Original Assignee
성균관대학교 산학협력단
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 성균관대학교 산학협력단 filed Critical 성균관대학교 산학협력단
Publication of WO2018169291A1 publication Critical patent/WO2018169291A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols

Definitions

  • the present invention relates to a registration interface information model, and more particularly, to an information model and security management service for a registration interface of network security functions (NSF) in I2NSF (Interface to Network Security Functions).
  • NSF network security functions
  • the Internet is essentially a number of networks with different levels of hierarchy interconnected.
  • the Internet operates in accordance with Transmission Control Protocol / Internet Protocol (TCP / IP) published by the Internet Engineering Task Force (IETF), which can be found in Request For Comments (RFC) 703 and RFC 791 issued by the IETF. .
  • TCP / IP Transmission Control Protocol / Internet Protocol
  • RFC Request For Comments
  • An object of the present invention is to propose an information model required for a registration interface between a security controller and a developer management system to support NSF registration and instantiation.
  • An aspect of the present invention is a security management system for managing a network security function (NSF) through a registration interface, the method performed by a security controller (Security Controller), the security management system Transmitting an instantiation request message for the NSF required by the developer to a developer's management system; And receiving a registration message from the developer management system indicating a registration of an NSF instance for the required NSF in response to the request message.
  • NSF network security function
  • the security management system further comprises the step of recognizing capability information (Capability Information) or signature (signature) of the NSF, the instantiation request message may include the capability information or the signature.
  • capability information Capability Information
  • signature signature
  • said NSF instance may be created by a developer management system based on said instantiation request message.
  • the security management system further comprises the step of sending a de-instantiation request message for the unnecessary NSF to the developer management system, the NSF instance corresponding to the de-instantiation request message to the developer management system Can be deleted.
  • the registration message may include at least one of NSF capability information indicating security capability of the NSF instance or NSF access information used for network access to a new instance.
  • the NSF access information may include at least one of an Internet Protocol version 4 (IPv4) address, an Internet Protocol version 6 (IPv6) address, a port number, or a supported transport protocol. Can be.
  • IPv4 Internet Protocol version 4
  • IPv6 Internet Protocol version 6
  • the supported transport protocol is a Virtual Extensible LAN (VXLAN), a Generic Protocol Extension for VXLAN (VXLAN-GPE), Generic Route Encapsulation (GRE) or Ethernet ( Ethernet).
  • VXLAN Virtual Extensible LAN
  • VXLAN-GPE Generic Protocol Extension for VXLAN
  • GRE Generic Route Encapsulation
  • Ethernet Ethernet
  • the NSF capability information may include at least one of Network-Security Capabilities, Content-Security Capabilities, Attack Mitigation Capabilities, and Performance Capabilities. have.
  • the performance capability may include processing and bandwidth information.
  • said role-based access control list may include one or more role IDs used to identify a role of an entity, and said role ID may include one or more access types used to identify a particular type of access request.
  • a security controller for managing a network secure function (NSF) through a registration interface, comprising: a communication unit for wirelessly or wired communication with an external device; And a processor operatively connected to the communication unit, wherein the processor transmits an instantiation request message for an NSF required by the security management system to a developer's management system, and sends the request message to the developer message.
  • a registration message indicating registration of an NSF instance for the required NSF may be received from the developer management system.
  • the utilization of the existing I2NSF registration interface can be extended.
  • components of the I2NSF framework can exchange a set of NSF capabilities in a standardized manner.
  • FIG 1 illustrates an I2NSF (Interface to Network Security Functions) system according to an embodiment of the present invention.
  • I2NSF Interface to Network Security Functions
  • FIG 2 illustrates the architecture of an I2NSF system in accordance with another embodiment of the present invention.
  • FIG. 3 is a flowchart illustrating a method of registering an NSF instance through a registration interface according to an embodiment to which the present invention is applied.
  • FIG. 4 is a diagram illustrating an information model of a registration interface according to an embodiment of the present invention.
  • FIG. 5 is a diagram illustrating an instance management sub-model according to an embodiment of the present invention.
  • FIG. 6 is a diagram illustrating a Registration Sub-Model according to an embodiment of the present invention.
  • FIG. 7 is a diagram schematically illustrating NSF capability information according to an embodiment of the present invention.
  • FIG. 8 is a diagram schematically illustrating performance capability information according to an embodiment of the present invention.
  • FIGS. 9 and 10 are diagrams illustrating a role-based access control list (ACL) according to an embodiment of the present invention.
  • FIG. 11 illustrates a block diagram of a network device according to an embodiment of the present invention.
  • I2NSF Interface to Network Security Functions
  • the purpose of the I2NSF is to define a standardized interface for heterogeneous network security function (NSF) provided by a number of security solution vendors.
  • NSF network security function
  • FIG 1 illustrates an I2NSF (Interface to Network Security Functions) system according to an embodiment of the present invention.
  • I2NSF Interface to Network Security Functions
  • an I2NSF system includes an I2NSF user, a Network Operator Management System, a Developer's Management System, and / or at least one Network Security Function (NSF).
  • NSF Network Security Function
  • the I2NSF user communicates with the network operations management system via the I2NSF Consumer-Facing Interface.
  • the network operations management system communicates with the NSF (s) via an I2NSF NSF-Facing Interface.
  • the developer management system communicates with the network operations management system through the I2NSF Registration Interface.
  • each component (I2NSF component) and each interface (I2NSF interface) of the I2NSF system will be described.
  • An I2NSF user requests information (eg, information from NSF) from another I2NSF component (eg, network operations management system) and / or a security service (eg, network security) provided by another I2NSF component (eg, developer management system). Service) is an I2NSF component.
  • the I2NSF user may be an overlay network management system, an enterprise network administrator system, another network domain administrator, or the like. I2NSF users may be referred to as I2NSF clients.
  • the object performing the role assigned to this I2NSF user component may be referred to as an I2NSF consumer.
  • An example of an I2NSF consumer is the need to dynamically inform an underlay network to allow, rate-limit, or reject flow based on a particular field of a packet over a time span.
  • Video-conference network manager, enterprise network administrators and management systems that need to request provider networks to enforce specific I2NSF policies for specific flows,
  • An IoT management system may be included that sends a request to the underlay network to block flows that match a set of specific conditions.
  • I2NSF users can create and deploy high-level security policies. Specifically, the I2NSF user needs to use a network security service to protect network traffic from various malicious attacks. To request this security service, the I2NSF user can create a high level security policy for the security service he wants and notify the network operations management system.
  • the I2NSF user may be informed of security event (s) occurring in the underlying NSF (s) by the network operations management system.
  • security event s
  • I2NSF users can identify new attacks and update (or create) high level security policies to counter new attacks.
  • I2NSF users can define, manage, and monitor security policies.
  • a network operations management system is a component that acts as a collection and distribution point for providing security, monitoring, and other operations.
  • the network operations management system may correspond to a security controller or may be a component including a security controller.
  • Such a network operations management system may be managed by a network operator and may be referred to as an I2NSF management system.
  • the network operations management system may receive the high level security policy from the I2NSF user and then first determine the type of NSF (s) required to enforce the policy required by the I2NSF user. The network operations management system (or security controller) can then create a low-level security policy for each NSF (s) required. As a result, the network operations management system (or security controller) may set the generated low level security policy to each NSF (s).
  • the network operations management system (or security controller) monitors the NSF (s) running in the I2NSF system, and provides various information about each NSF (s) (e.g., network access information and workloads). ), Etc.) can be maintained.
  • network operations management systems (or security controllers) can dynamically manage pools of NSF instances through dynamic life-cycle management of NSF instances with the help of developer management systems. have.
  • NSF is a logical entity or software component that provides security related services.
  • NFC eg, a firewall
  • the developer management system is an I2NSF component that sends information (eg, NSF's information) to other I2NSF components (eg, network operations management system) and / or provides security services (eg, network security services).
  • the developer management system may be referred to as Vendor's Management System.
  • An object performing a role assigned to such a developer management system may be referred to as an I2NSF producer.
  • the developer management system may be managed by a third-party security vendor that provides NSF (s) to network operators. There may be multiple developer management system (s) from various security vendors.
  • I2NSF consumer-facing interface (simply, consumer-facing interface (CFI))
  • the CFI is an interface to the user's I2NSF system, located between the I2NSF user and the network operations management system. By designing this, the I2NSF system can hide the details of the underlying NSF (s) and provide only an abstract view of the NSF (s) to the user.
  • This CFI can be used to allow different users of a given I2NSF system to define, manage, and monitor security policies for specific flows in an administrative domain.
  • High-level security policies (or policy rules) created by I2NSF users can be conveyed to the network operations management system via this CFI.
  • security alerts by the NSF (s) may be communicated from the network operations management system to the I2NSF user via this CFI.
  • NFI is an interface located between the network operations management system (or security controller) and the NSF (s).
  • NFI The main purpose of NFI is to provide a standardized interface for controlling and managing NSF (s) from various security solution vendors by decoupled security management techniques from NSF (s).
  • NFI is independent of the details of the NSF (s) (eg, vendor, form factor, etc.).
  • This NFI may be used to specify and monitor a flow-based security policy enforced by one or more NSFs.
  • the network operations management system may deliver a flow-based security policy to each flow-based NSF via the NFI interface in order to enforce a high level security policy by the I2NSF user.
  • flow-based NSF is an NSF that examines network flow according to a set of policies to enhance security characteristics.
  • This flow-based security by flow-based NSF means that packets are examined in the order in which they are received, and there is no modification to the packets according to the inspection process.
  • Interfaces for flow-based NSF can be classified as follows:
  • NSF Operational and Administrative Interface group of interfaces used by the I2NSF management system to program the operational state of the NSF; This interface group also includes administrative control functions. I2NSF policy rules represent one way of changing this interface group in a consistent manner. Since applications and I2NSF components need to dynamically control the behavior of the traffic they send and receive, much of the I2NSF effort is concentrated in this group of interfaces.
  • Monitoring Interface group of interfaces used by the I2NSF management system to obtain monitoring information from one or more selected NSFs; Each interface in this interface group can be a query or report based interface. The difference between the two is that the query based interface is used by the I2NSF management system to obtain the information, while the report based interface is used by the NSF to provide the information.
  • the functionality of this interface group can also be defined by other protocols such as SYSLOG and DOTS.
  • the I2NSF management system may take one or more actions based on the receipt of the information. This should be specified by the I2NSF policy rule. This interface group does not change the operational state of the NSF.
  • NFI may be developed using a flow-based paradigm.
  • a common trait of flow-based NSF is to process packets based on the content (eg header / payload) and / or context (eg session state and authentication state) of the received packet. This feature is one of the requirements for defining the behavior of an I2NSF system.
  • the I2NSF management system does not need to use all the functions of a given NSF, nor need to use all available NSFs.
  • this abstraction allows NSF features to be treated as building blocks by the NSF system.
  • developers are free to use the security features defined by NSF, which are vendor and technology independent.
  • I2NSF Registration interface (simply, registration interface (RI))
  • RI is an interface located between the network operations management system and the developer management system. NSFs provided by different vendors may have different capabilities. Thus, in order to automate processes that take advantage of the different types of security capabilities offered by different vendors, it is necessary for vendors to have a dedicated interface for defining the functionality of their NSF. This dedicated interface may be referred to as an I2NSF Registration Interface (RI).
  • RI I2NSF Registration Interface
  • the NSF's capabilities can be preconfigured or dynamically retrieved through the I2NSF registration interface. If new features exposed to consumers are added to the NSF, the capabilities of those new features need to be registered in the I2NSF registry through this RI so that interested management and control entities know them. .
  • FIG. 2 illustrates the architecture of an I2NSF system in accordance with another embodiment of the present invention.
  • the I2NSF system of FIG. 2 illustrates the configuration of an I2NSF user and network operation management system more specifically than the I2NSF system of FIG. 1.
  • FIG. 2 descriptions overlapping with those described above in FIG. 1 will be omitted.
  • the I2NSF system includes an I2NSF user, a security management system, and an NSF instance layer.
  • the I2NSF user layer includes Application Logic, Policy Updater, and Event Collector as components.
  • the security management system layer includes a security controller and a developer management system.
  • the security controller of the security management system layer includes a security policy manager and an NSF capability manager as components.
  • the I2NSF user layer communicates with the security management system layer via a consumer-facing interface.
  • the policy updater and event collector of the I2NSF user layer communicate with the security controller of the security management system layer via a consumer-facing interface.
  • the security management system layer also communicates with the NFC instance layer via the NSF-direct interface.
  • the security controller of the security management system layer communicates with the NSF instance (s) of the NFC instance layer via an NSF-direct interface.
  • the developer management system of the security management system layer communicates with the security controller of the security management system layer through a registration interface.
  • the I2NSF user layer, the security controller component of the security management system layer, the developer management system component of the security management system layer, and the NSF instance layer of FIG. Corresponds to the component.
  • the consumer-facing interface, the NSF-facing interface and the registration interface of FIG. 2 correspond to the consumer-facing interface, the NSF-facing interface and the registration interface of FIG. 1.
  • the I2NSF user layer includes three components: Application Logic, Policy Updater, and Event Collector. Each role and operation are described as follows.
  • Application logic is the component that creates the high-level security policy.
  • the application logic receives an event from the event collector to update (or create) a high level policy and updates (or creates) a high level policy based on the collected event. After that, the high level policy is sent to the policy updater for distribution to the security controller.
  • the event collector receives the events sent by the security collector and sends them to the application logic. Based on this feedback, the application logic can update (or create) a high level security policy.
  • each is a logical component, and may be implemented as one or a plurality of components in the I2NSF system.
  • it may be implemented by a single I2NSF user component as shown in FIG.
  • the security controller of the security management system layer includes two components: a security policy manager and an NSF capability manager. Each role and operation are described as follows.
  • the security policy manager can receive high-level policies from the policy updater through CFI, and map these policies to multiple low-level policies. This low level policy relates to a given NSF capability registered with the NSF capability manager. In addition, the security policy manager may forward this policy to the NSF (s) via NFI.
  • the NSF capability manager can specify the capabilities of the NSF registered by the developer management system and share it with the security policy manager to create a low level policy associated with a given NSF capability. Each time a new NSF is registered, the NSF capability manager may request the developer management system to register the NSF's capabilities / capabilities in the management table of the NSF capability manager via the registration interface. The developer management system is another part of the security management system for registering new NSF capabilities as NSF capability managers.
  • each is a logical component, and may be implemented as one component in the I2NSF system.
  • the NSF instance layer includes NSFs. At this time, all NSFs are located in this NSF instance layer.
  • the security policy manager forwards the policy to the NSF (s) via the NFI.
  • NFC can detect, block or mitigate malicious network traffic based on the received low level security policy.
  • the capability information model shall support NSF instance creation, registration and deletion requests through the registration interface.
  • a procedure through the I2NSF registration interface for this function will be described.
  • specific information exchanged through the I2NSF registration interface will be described.
  • NSF instances generally exist in the I2NSF framework. Since these NSF instances can have different security functions, it is important to register the security functions of each NSF instance with the security controller after they are created. In addition, some security functions need to be instantiated if necessary. For example, if additional security features are needed to meet the new security requirements of I2NSF users, the security controller should be able to request the developer management system to instantiate an NSF with the necessary security features.
  • the present invention proposes a capability information model required for a registration interface between a security controller and a developer management system to support NSF registration and instantiation.
  • the present invention proposes a procedure based on a capability information model performed by a security controller and a developer management system through a registration interface.
  • the existing I2NSF registration interface was used only when registering a new NSF instance with the security controller.
  • the present invention proposes information that needs to be exchanged through a registration interface for the purpose of extending its utilization and functioning to support NSF instantiation / deinstantiation if necessary.
  • the NSF capability information ie, the capability of the NSF
  • the model should be clarified so that a component of the I2NSF framework should be able to exchange a set of capabilities in a standardized manner, so that NSF capability information for this is required.
  • NSF Network Security Function
  • OSI Open System Interconnection
  • NSF Network security service function
  • IPS intrusion Prevention System / IDS: Intrusion Detection System
  • DPI Deep Packet Inspection, Application Visibility and Control (AVC)
  • AVC Application Visibility and Control
  • DLP Data Loss Prevention
  • DDoS It may represent (or provide) services such as Distributed Denial of Service (mitigation) and Transport Layer Security (TLS) proxies.
  • Advanced Inspection / Action may indicate that a security function invokes another security function for further inspection based on the results of its own inspection. have.
  • the NSF capability information model indicates the security capability and performance capability of the NSF instance.
  • Each NSF instance has its own NSF capability information model that indicates the type of security services it can provide and its capabilities.
  • an NSF instance may be registered through a registration interface between the security controller and the developer management system.
  • FIG. 3 is a flowchart illustrating a method of registering an NSF instance through a registration interface according to an embodiment to which the present invention is applied.
  • the security controller transmits an instantiation request message to the developer management system (S301).
  • the security controller and the developer management system represent components of the I2NSF framework described above with reference to FIG. 2.
  • the developer management system Upon receiving the instantiation request message from the security controller, the developer management system can create the corresponding NSF instance. For example, prior to step S301, the security controller can recognize the signature of the particular NSF or the set of capabilities required in the current system (ie, NSF capability information). In addition, the security controller may transmit an instantiation request message including the recognized information to the developer management system. The developer management system may match the received information with the NSF based on the capability information model definition and create an NSF instance that matches the received information.
  • the security controller can send a deinstantiation request message to the developer management system.
  • the developer management system can remove the corresponding NSF instance.
  • the security controller can recognize the signature of a particular NSF or a set of capabilities (i.e., NSF capability information) that are unnecessary in the current system.
  • the security controller may send a deinstantiation request message containing the recognized information to the developer management system.
  • the developer management system may match the received information with the NSF based on the capability information model definition and remove the NSF instance that matches the received information.
  • the security controller receives a registration message for registration of the NSF instance from the developer management system (S302).
  • the security controller may add the NSF instance to the list of available NSF instances of the system after receiving the registration message.
  • the security controller in step S301 may receive a deletion message from the developer management system. In this case, the security controller may remove the corresponding NSF instance from the list of available NSF instances of the system.
  • the developer management system may register an NSF instance. Specifically, some NSFs may be required by default depending on the security requirements of the system. In this case, the developer management system can create this default NSF instance without requesting the security controller. After creating the NSF instances, the developer management system may notify the security controller of the NSF instance (or information related to the NSF instance) via the registration interface.
  • an NSF instance may be created that provides advanced checks / actions triggered by other NSFs through a registration interface.
  • the NSF can trigger other types of NSF for advanced security inspection of traffic.
  • the next NSF may be determined by the inspection result of the current NSF and the I2NSF user policy.
  • the security controller can request the developer management system through the registration interface to create the NSF instance.
  • an NSF instance may be created that is required to enforce security policy rules received from I2NSF users. That is, in the I2NSF framework, I2NSF users can determine the security services required for the system. If there is no NSF instance to enforce the security policy requested by the I2NSF user, the security controller may request the developer management system through the registration interface to create the required NSF instance.
  • NSF instances that are no longer needed can be deleted.
  • Various types of NSF instances can run in the I2NSF framework, and some types of NSF instances may no longer be needed depending on the dynamic changes in the security policy to be implemented in the system.
  • the security controller may request the developer management system to destroy the NSF instance via the registration interface.
  • FIG. 4 is a diagram illustrating an information model of a registration interface according to an embodiment of the present invention.
  • the information model of the registration interface may include an instance management submodel (or a submodel) and / or a registration submodel.
  • the instance management function and the registration function may use the NSF capability information model to achieve the purpose.
  • the NSF capability information model represents a capability object that describes and / or defines the inspection capabilities that an NSF instance can provide.
  • the NSF instance may be created / removed through the instance management submodel among the registration interface information model, and detailed information constituting the NSF capability information model may be defined in the registration submodel.
  • FIG. 5 is a diagram illustrating an instance management sub-model according to an embodiment of the present invention.
  • the security controller of the I2NSF framework may perform an instantiation request and / or a deinstantiation request for instance management of the NSF.
  • the security controller may transmit an instantiation request message to the developer control system if necessary.
  • the developer control system receiving the request from the security controller may generate a corresponding NSF instance based on the NSF capability information and transmit a response message including information related to the processing result to the security controller.
  • the security controller may transmit a de-instantiation request message to the developer control system if necessary.
  • the developer control system may remove the corresponding NSF instance based on the NSF access information and transmit a response message including information related to the processing result to the security controller.
  • FIG. 6 is a diagram illustrating a Registration Sub-Model according to an embodiment of the present invention.
  • the developer management system may send (or create) a registration message to the security controller to register a new NSF instance.
  • the registration message may include NSF capability information and NSF access information.
  • the NSF capability information indicates the inspection capability of the new NSF instance.
  • NSF access information represents information that enables network access to a new instance of another component. The detailed information model of the NSF capability information and the NSF access information will be described later in detail.
  • the I2NSF capability interface can control and monitor the newly registered NSF instance.
  • NSF access information represents information required for performing communication with the NSF.
  • the NSF access information is an Internet Protocol version 4 (IPv4) address, an Internet Protocol version 6 (IPv6) address, a port number and / or a supported transport protocol. It may include.
  • Transport protocols supported here include, for example, Virtual Extensible LAN (VXLAN), Generic Protocol Extension for VXLAN (VXLAN-GPE (Generic Protocol Extension)), Generic Route Encapsulation (GRE), Ethernet, and the like.
  • VXLAN Virtual Extensible LAN
  • VXLAN-GPE Generic Protocol Extension for VXLAN
  • GRE Generic Route Encapsulation
  • NSF access information represents the signature (or unique identifier) of an NSF instance within the overall system (or NSF instance list). NSF access information can be used to identify a particular NSF instance.
  • FIG. 7 is a diagram schematically illustrating NSF capability information according to an embodiment of the present invention.
  • NSF capability information indicating the security capability of an NSF instance may include capability objects of various NSF instances.
  • the NSF capability information may include network-security capabilities, content-security capabilities, attack mitigation capabilities, and performance capabilities. Can be.
  • Network security capabilities represent the ability to inspect and process network traffic using predefined security policies.
  • Content Security Capability Indicates the ability to analyze the traffic content delivered by the application layer.
  • Attack mitigation capabilities also represent the ability to detect and mitigate various types of network attacks.
  • FIG. 8 is a diagram schematically illustrating performance capability information according to an embodiment of the present invention.
  • the performance capability information may include a processing and / or bandwidth field (or information).
  • the performance information indicates the processing capability of the NSF.
  • Performance information may be used to determine whether the NSF is in a congestion state by comparing the workload currently in charge with the NSF.
  • performance information may be used to specify the available amount of each type of resource, such as the capacity available in the NSF.
  • the processing information indicates the available processing power of the NSF.
  • Bandwidth represents information about the amount of network available in two cases, outbound and inbound. The processing information and bandwidth information may be used for an instance (or instantiation) request of the NSF by the security controller.
  • the registration interface proposed in this specification can control the use and restriction of the generated instance, and can perform an appropriate request according to the status.
  • Role-based ACL Role-based Access Control List
  • Role-based ACL information may specify the access policy of the NSF to determine whether to allow or deny entity access to the NSF according to the role assigned to the entity.
  • Each NSF may be associated with a role-based ACL to determine whether to allow or deny an access request from an entity.
  • FIGS. 9 and 10 are diagrams illustrating a role-based access control list (ACL) according to an embodiment of the present invention.
  • a role-based ACL may include one or more role IDs.
  • the role ID represents information used to identify a role of an entity (eg, administrator, developer, etc.).
  • each role ID included in the role-based ACL may include access types classified as allow / deny.
  • a role-based ACL may consist of a set of access types that are allowed or denied on each role ID.
  • the access type may be used to identify a particular type of access request, such as NSF rule configuration, NSF rule update, and / or NSF monitoring.
  • the information model of the registration interface proposed in this specification may be based on the I2NSF framework without an architecture change.
  • this document can share the security considerations of the I2NSF framework specified in the IETF draft document (eg rfc8329.txt) described above to achieve secure communication between components in the proposed architecture.
  • the network device may correspond to the aforementioned I2NSF system (or security management system) or may be a device included in the I2NSF system.
  • I2NSF system or security management system
  • devices included in the I2NSF system may include the above-described I2NSF, security controller, developer management system, NSF, and the like.
  • the network device 1100 includes a processor 1110, a memory 1120, and a communication module 1130.
  • the processor 1110 implements the functions, processes, and / or methods proposed in FIGS. 1 to 10.
  • the memory 1120 is connected to the processor 1110 and stores various information for driving the processor 1110.
  • the communication module 1130 is connected to the processor 1110 and transmits and / or receives a wired / wireless signal.
  • the memory 1120 may be inside or outside the processor 1110 and may be connected to the processor 1110 by various well-known means.
  • each component or feature is to be considered optional unless stated otherwise.
  • Each component or feature may be embodied in a form that is not combined with other components or features. It is also possible to combine some of the components and / or features to form an embodiment of the invention.
  • the order of the operations described in the embodiments of the present invention may be changed. Some components or features of one embodiment may be included in another embodiment or may be replaced with corresponding components or features of another embodiment. It is obvious that the claims may be combined to form an embodiment by combining claims that do not have an explicit citation relationship in the claims or as new claims by post-application correction.
  • Embodiments according to the present invention may be implemented by various means, for example, hardware, firmware, software, or a combination thereof.
  • an embodiment of the present invention may include one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), FPGAs ( field programmable gate arrays), processors, controllers, microcontrollers, microprocessors, and the like.
  • ASICs application specific integrated circuits
  • DSPs digital signal processors
  • DSPDs digital signal processing devices
  • PLDs programmable logic devices
  • FPGAs field programmable gate arrays
  • processors controllers, microcontrollers, microprocessors, and the like.
  • an embodiment of the present invention is implemented in the form of a module, a procedure, a function, etc. for performing the functions or operations described above, so that Can be recorded.
  • the recording medium may include a program command, a data file, a data structure, etc. alone or in combination.
  • Program instructions recorded on the recording medium may be those specially designed and constructed for the present invention, or they may be of the kind well-known and available to those having skill in the computer software arts.
  • the recording medium may be magnetic media such as hard disks, floppy disks and magnetic tapes, optical disks such as Compact Disk Read Only Memory (CD-ROM), digital video disks (DVD), Magnetic-Optical Media, such as a Disk, and hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, Flash Memory, and the like.
  • program instructions may include high-level language code that can be executed by a computer using an interpreter as well as machine code such as produced by a compiler.
  • Such hardware devices may be configured to operate as one or more software modules to perform the operations of the present invention, and vice versa.
  • the device or the terminal according to the present invention may be driven by a command that causes one or more processors to perform the functions and processes described above.
  • such instructions may include interpreted instructions, such as script instructions such as JavaScript or ECMAScript instructions, or executable instructions or other instructions stored on a computer readable medium.
  • the device according to the present invention may be implemented in a distributed manner over a network, such as a server farm, or may be implemented in a single computer device.
  • a computer program (also known as a program, software, software application, script or code) mounted on an apparatus according to the invention and executing a method according to the invention comprises a compiled or interpreted language or a priori or procedural language. It can be written in any form of programming language, and can be deployed in any form, including stand-alone programs or modules, components, subroutines, or other units suitable for use in a computer environment. Computer programs do not necessarily correspond to files in the file system.
  • a program may be in a single file provided to the requested program, in multiple interactive files (eg, a file that stores one or more modules, subprograms, or parts of code), or part of a file that holds other programs or data. (Eg, one or more scripts stored in a markup language document).
  • the computer program may be deployed to run on a single computer or on multiple computers located at one site or distributed across multiple sites and interconnected by a communication network.

Abstract

본 발명에서는 등록 인터페이스(Registration Interface)를 통해 네트워크 보안 기능(NSF: Network Secure Function)을 관리하는 보안 관리 시스템이 개시된다. 구체적으로, 보안 제어기(Security Controller)에 의해 수행되는 방법은, 상기 보안 관리 시스템에서 필요한 NSF에 대한 인스턴스화(instantiation) 요청 메시지를 개발자 관리 시스템(Developer's Management System)으로 전송하는 단계; 및 상기 요청 메시지에 대한 응답으로 상기 필요한 NSF에 대한 NSF 인스턴스의 등록을 지시하는 등록 메시지를 상기 개발자 관리 시스템으로부터 수신하는 단계를 포함할 수 있다.

Description

네트워크 보안 기능에 대한 등록 인터페이스 정보 모델
본 발명은 등록 인터페이스 정보 모델에 관한 것으로서, 보다 상세하게 I2NSF(Interface to Network Security Functions)에서 네트워크 보안 능력(Network Security Functions: NSF)의 등록 인터페이스를 위한 정보 모델과 보안 관리 서비스를 위한 것이다.
네트워크를 전세계에 연결하면 지리적 거리에 관계없이 신속하게 정보에 액세스 할 수 있다. 인터넷은 본질적으로 서로 다른 레벨들의 계층 구조가 서로 연결된 수많은 네트워크이다.
인터넷은 IETF (Internet Engineering Task Force)에서 공표 한 TCP/IP (전송 제어 프로토콜/인터넷 프로토콜)에 따라 운영되며, TCP/IP는 RFC (Request For Comments) 703 및 IETF에서 발행 한 RFC 791에서 찾을 수 있다.
본 발명의 목적은, NSF 등록 및 인스턴스화를 지원하기 위하여 보안 제어기와 개발자 관리 시스템간 등록 인터페이스에 필요한 정보 모델을 제안한다.
또한, 본 발명의 목적은, 등록 인터페이스를 통해 보안 제어기와 개발자 관리 시스템에 의해 수행되는 정보 모델에 기반한 절차를 제안한다.
본 발명에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
본 발명의 일 양상은, 등록 인터페이스(Registration Interface)를 통해 네트워크 보안 기능(NSF: Network Secure Function)을 관리하는 보안 관리 시스템에서, 보안 제어기(Security Controller)에 의해 수행되는 방법은, 상기 보안 관리 시스템에서 필요한 NSF에 대한 인스턴스화(instantiation) 요청 메시지를 개발자 관리 시스템(Developer’s Management System)으로 전송하는 단계; 및 상기 요청 메시지에 대한 응답으로 상기 필요한 NSF에 대한 NSF 인스턴스의 등록을 지시하는 등록 메시지를 상기 개발자 관리 시스템으로부터 수신하는 단계를 포함할 수 있다.
바람직하게, 상기 보안 관리 시스템에서 필요한 NSF의 능력 정보(Capability Information) 또는 서명(signature)을 인식하는 단계를 더 포함하고, 상기 인스턴스화 요청 메시지는 상기 능력 정보 또는 상기 서명을 포함할 수 있다.
바람직하게, 상기 NSF 인스턴스는 상기 인스턴스화 요청 메시지에 기초하여 개발자 관리 시스템에 의해 생성될 수 있다.
바람직하게, 상기 보안 관리 시스템에서 불필요한 NSF에 대한 역인스턴스화(de-instantiation) 요청 메시지를 개발자 관리 시스템으로 전송하는 단계를 더 포함하고, 상기 역인스턴스화 요청 메시지에 대응되는 NSF 인스턴스가 상기 개발자 관리 시스템에 의해 삭제될 수 있다.
바람직하게, 상기 등록 메시지는 NSF 인스턴스의 보안 능력을 나타내는 NSF 능력 정보(Capability Information) 또는 새로운 인스턴스에 대한 네트워크 접근을 위해 이용되는 NSF 접근 정보(Access Information) 중 적어도 하나를 포함할 수 있다.
바람직하게, 상기 NSF 접근 정보는 IPv4(Internet Protocol version 4) 주소(address), IPv6(Internet Protocol version 6) 주소, 포트 번호(port number) 또는 지원되는 전송 프로토콜(transport protocol) 중 적어도 하나를 포함할 수 있다.
바람직하게, 상기 지원되는 전송 프로토콜은 가상 확장(Virtual Extensible) LAN(VXLAN), VXLAN를 위한 일반 프로토콜 확장(VXLAN-GPE(Generic Protocol Extension)), 일반 경로 캡슐화(GRE: Generic Route Encapsulation) 또는 이더넷(Ethernet) 중 적어도 하나를 포함할 수 있다.
바람직하게, 상기 NSF 능력 정보는 네트워크 보안 능력(Network-Security Capabilities), 컨텐츠 보안 능력(Content-Security Capabilities), 공격 완화 능력(Attack Mitigation Capabilities), 수행 능력(performance capabilities) 중 적어도 하나를 포함할 수 있다.
바람직하게, 상기 수행 능력은 처리(Processing) 및 대역폭(Bandwidth) 정보를 포함할 수 있다.
바람직하게, 상기 역할 기반 접근 제어 리스트는 엔티티의 역할 식별에 이용되는 하나 이상의 역할 ID를 포함하고, 상기 역할 ID는 특정 유형의 접근 요청을 식별하는데 사용되는 하나 이상의 접근 유형을 포함할 수 있다.
본 발명의 다른 일 양상은 등록 인터페이스(Registration Interface)를 통해 네트워크 보안 기능(NSF: Network Secure Function)을 관리하는 보안 제어기(Security Controller)에 있어서, 외부 장치와 무선 또는 유선으로 통신하기 위한 통신부; 및 상기 통신부와 기능적으로 연결되는 프로세서를 포함하되, 상기 프로세서는, 상기 보안 관리 시스템에서 필요한 NSF에 대한 인스턴스화(instantiation) 요청 메시지를 개발자 관리 시스템(Developer’s Management System)으로 전송하고, 및 상기 요청 메시지에 대한 응답으로 상기 필요한 NSF에 대한 NSF 인스턴스의 등록을 지시하는 등록 메시지를 상기 개발자 관리 시스템으로부터 수신할 수 있다.
본 발명의 실시예에 따르면, 기존의 I2NSF 등록 인터페이스의 활용도를 확장할 수 있다.
또한, 본 발명의 실시예에 따르면, NSF 능력 정보(capability information)모델을 정의함으로써 I2NSF 프레임 워크의 구성 요소들이 NSF 능력(Capability)들의 세트를 표준화된 방식으로 교환할 수 있다.
본 발명에서 얻을 수 있는 효과는 이상에서 언급한 효과로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
본 발명에 관한 이해를 돕기 위해 상세한 설명의 일부로 포함되는, 첨부 도면은 본 발명에 대한 실시예를 제공하고, 상세한 설명과 함께 본 발명의 기술적 특징을 설명한다.
도 1은 본 발명의 일 실시예에 따른 I2NSF(Interface to Network Security Functions) 시스템을 예시한다.
도 2는 본 발명의 다른 실시예에 따른 I2NSF 시스템의 아키텍처를 예시한다.
도 3은 본 발명이 적용되는 실시예로서, 등록 인터페이스를 통해 NSF 인스턴스를 등록하는 방법을 나타내는 흐름도이다.
도 4는 본 발명의 일 실시예에 따른 등록 인터페이스의 정보 모델을 예시하는 도면이다.
도 5는 본 발명의 일 실시예에 따른 인스턴스 관리 서브 모델(Instance Management Sub-Model)을 예시하는 도면이다.
도 6은 본 발명의 일 실시예에 따른 등록 서브 모델(Registration Sub-Model)을 예시하는 도면이다.
도 7은 본 발명의 일 실시예에 따른, NSF 능력 정보(Capability Information)를 개략적으로 나타내는 도면이다.
도 8은 본 발명의 일 실시예에 따른, 수행 능력(Performance Capabilities) 정보를 개략적으로 나타내는 도면이다.
도 9 및 도 10은 본 발명의 일 실시예에 따른 역할 기반 ACL(Role-based Access Control List)을 예시하는 도면이다.
도 11는 본 발명의 일 실시예에 따른 네트워크 장치의 블록 구성도를 예시한다.
이하, 본 발명에 따른 바람직한 실시 형태를 첨부된 도면을 참조하여 상세하게 설명한다. 첨부된 도면과 함께 이하에 개시될 상세한 설명은 본 발명의 예시적인 실시형태를 설명하고자 하는 것이며, 본 발명이 실시될 수 있는 유일한 실시형태를 나타내고자 하는 것이 아니다. 이하의 상세한 설명은 본 발명의 완전한 이해를 제공하기 위해서 구체적 세부사항을 포함한다. 그러나, 당업자는 본 발명이 이러한 구체적 세부사항 없이도 실시될 수 있음을 안다.
몇몇 경우, 본 발명의 개념이 모호해지는 것을 피하기 위하여 공지의 구조 및 장치는 생략되거나, 각 구조 및 장치의 핵심기능을 중심으로 한 블록도 형식으로 도시될 수 있다.
아울러, 본 발명에서 사용되는 용어는 가능한 한 현재 널리 사용되는 일반적인 용어를 선택하였으나, 특정한 경우는 출원인이 임의로 선정한 용어를 사용하여 설명한다. 그러한 경우에는 해당 부분의 상세 설명에서 그 의미를 명확히 기재하므로, 본 발명의 설명에서 사용된 용어의 명칭만으로 단순 해석되어서는 안 될 것이며 그 해당 용어의 의미까지 파악하여 해석되어야 함을 밝혀두고자 한다.
이하의 설명에서 사용되는 특정 용어들은 본 발명의 이해를 돕기 위해서 제공된 것이며, 이러한 특정 용어의 사용은 본 발명의 기술적 사상을 벗어나지 않는 범위에서 다른 형태로 변경될 수 있다.
명세서 전체에서, 어떤 부분이 다른 부분과 "연결"되어 있다고 할 때, 이는 "직접적으로 연결"되어 있는 경우뿐 아니라, 그 중간에 다른 소자를 사이에 두고 "전기적으로 연결"되어 있는 경우도 포함한다.
본 명세서 전체에서, 어떤 부재가 다른 부재 “상에” 위치하고 있다고 할 때, 이는 어떤 부재가 다른 부재에 접해 있는 경우뿐 아니라 두 부재 사이에 또 다른 부재가 존재하는 경우도 포함한다.
본 명세서 전체에서, 어떤 부분이 어떤 구성요소를 "포함" 한다고 할 때, 이는 특별히 반대되는 기재가 없는 한 다른 구성요소를 제외하는 것이 아니라 다른 구성 요소를 더 포함할 수 있는 것을 의미한다. 본원 명세서 전체에서 사용되는 정도의 용어 "~(하는) 단계" 또는 "~의 단계"는 "~ 를 위한 단계"를 의미하지 않는다.
최근에는, NFV-based security function을 위한 기본 표준 인터페이스가 I2NSF(Interface to Network Security Functions) 워킹 그룹에 의해 개발되고 있다. 이는 인터넷 엔지니어링 태스크 포스(IETF: Internet Engineering Task Force)로 불리는 국제 인터넷 표준 기구의 일부이다.
I2NSF의 목적은 다수의 보안 솔루션 벤더(security solution vendor)들에 의해 제공되는 이종의(heterogeneous) 네트워크 보안 기능(들)(NSF: network security function)을 위한 표준화된 인터페이스를 정의하기 위함이다.
I2NSF 아키텍처(architecture)에서, NSF(들)의 관리에 대하여 상세히 고려할 필요 없이(NSF의 관리는 결국 보안 정책의 시행(enforce)을 요구한다), 사용자는 사용자의 네트워크 시스템 내 네트워크 자원을 보호하기 위한 보호 정책을 정의할 수 있다. 또한, 다수의 vendor들로부터 NSF(들)로의 표준화된 인터페이스는 이종의 NSF(들)에 대한 태스크(task)의 설정 및 관리를 단순화할 수 있다.
도 1은 본 발명의 일 실시예에 따른 I2NSF(Interface to Network Security Functions) 시스템을 예시한다.
도 1을 참조하면, I2NSF 시스템은 I2NSF 사용자(user), 네트워크 운영 관리 시스템(Network Operator Management System), 개발자 관리 시스템(Developer’s Management System) 및/또는 적어도 하나의 NSF(Network Security Function)을 포함한다.
I2NSF 사용자는 I2NSF 소비자-직면 인터페이스(I2NSF Consumer-Facing Interface)를 통해 네트워크 운영 관리 시스템과 통신한다. 네트워크 운영 관리 시스템은 I2NSF NSF-직면 인터페이스(I2NSF NSF-Facing Interface)를 통해 NSF(들)과 통신한다. 개발자 관리 시스템은 I2NSF 등록 인터페이스(I2NSF Registration Interface)를 통해 네트워크 운영 관리 시스템과 통신한다. 이하에서는 I2NSF 시스템의 각 컴포넌트(I2NSF 컴포넌트) 및 각 인터페이스(I2NSF 인터페이스)에 설명한다.
I2NSF 사용자
I2NSF 사용자는 다른 I2NSF 컴포넌트(예컨대, 네트워크 운영 관리 시스템)에서 정보(예컨대, NSF의 정보)를 요청하거나 및/또는 다른 I2NSF 컴포넌트(예컨대, 개발자 관리 시스템)에 의해 제공되는 보안 서비스(예컨대, 네트워크 보안 서비스)를 사용하는 I2NSF 컴포넌트이다. 예를 들면, I2NSF 사용자는 오버레이 네트워크 관리 시스템, 기업 네트워크 관리자 시스템, 다른 네트워크 도메인 관리자 등일 수 있다. I2NSF 사용자는 I2NSF 클라이언트로 지칭될 수 있다.
이러한 I2NSF 사용자 컴포넌트에 할당된 역할을 수행하는 대상은 I2NSF 소비자로 지칭될 수 있다. I2NSF 소비자의 예로는, 일정 기간(time span) 동안 패킷의 특정 필드에 기초하여 흐름을 허용, 속도-제한(rate-limit), 또는 거부하기 위해 언더레이 네트워크(underlay network)에 동적으로 알릴 필요가 있는 화상 회의 네트워크 관리자(video-conference network manager), 특정 흐름에 대한 특정 I2NSF 정책을 시행(enforce)하기 위해 제공자 네트워크를 요청할 필요가 있는 기업 네트워크 관리자(Enterprise network administrators) 및 관리 시스템(management systems), 특정 조건의 세트와 일치하는 흐름을 차단하기 위해 언더레이 네트워크에 요청을 전송하는 IoT 관리 시스템(IoT management system)이 포함될 수 있다.
I2NSF 사용자는 고수준(high-level) 보안 정책(security policy)을 생성 및 배포할 수 있다. 구체적으로 설명하면, I2NSF 사용자는 다양한 악의적인(malicious) 공격으로부터 네트워크 트래픽(traffic)을 보호하기 위하여 네트워크 보안 서비스(network security service)를 이용할 필요가 있다. 이 보안 서비스를 요청하기 위하여, I2NSF 사용자는 자신이 원하는 보안 서비스에 대한 고수준 보안 정책을 생성하고 네트워크 운영 관리 시스템에게 이를 알릴 수 있다.
한편, 고수준 보안 정책을 준비하는 과정에서, I2NSF 사용자는 각 NSF(들)를 위한 보안 서비스 또는 보안 정책 규칙 구성(security policy rule configuration)을 실현하기 위하여 요구되는 NSF(들)의 타입에 대하여 고려하지 않을 수 있다.
또한, I2NSF 사용자는 네트워크 운영 관리 시스템에 의해 기본적인(underlying) NSF(들) 내에서 발생되는 보안 이벤트(들)(security event)를 통지 받을 수 있다. 이들의 보안 이벤트(들)을 분석함으로써, I2NSF 사용자는 새로운 공격을 식별하고, 새로운 공격에 대처하기 위한 고수준 보안 정책을 업데이트(또는 생성)할 수 있다. 이와 같이, I2NSF 사용자는 보안 정책을 정의, 관리 및 모니터링할 수 있다.
네트워크 운영 관리 시스템
네트워크 운영 관리 시스템은 보안 제공, 모니터링 및 기타 동작을 위한 수집(collection) 및 배포(distribution) 지점(point)의 역할을 수행하는 컴포넌트이다. 예를 들면, 네트워크 운영 관리 시스템은 보안 제어기(Security Controller)에 해당하거나, 또는 보안 제어기를 포함하는 컴포넌트일 수 있다. 이러한 네트워크 운영 관리 시스템은 네트워크 운영자에 의해 관리될 수 있고, I2NSF 관리 시스템으로 지칭될 수도 있다.
네트워크 운영 관리 시스템(또는 보안 제어기)의 주요한 역할 중 하나는 I2NSF 사용자로부터의 고수준 보안 정책(또는 정책 규칙)을 특정 NSF(들)을 위한 저수준(low-level) 보안 정책 규칙으로 번역(translate)하는 것이다. 네트워크 운영 관리 시스템(또는 보안 제어기)은 고수준 보안 정책을 I2NSF 사용자로부터 수신한 후, 우선 I2NSF 사용자에 의해 요구되는 정책을 시행하기 위하여 요구되는 NSF(들)의 타입을 결정할 수 있다. 그리고, 네트워크 운영 관리 시스템(또는 보안 제어기)은 요구되는 각 NSF(들)을 위한 저수준(low-level) 보안 정책을 생성할 수 있다. 결국, 네트워크 운영 관리 시스템(또는 보안 제어기)는 생성된 저수준 보안 정책을 각 NSF(들)에게 설정할 수 있다.
또한, 네트워크 운영 관리 시스템(또는 보안 제어기)은 I2NSF 시스템 내 구동 중인 NSF(들)을 모니터링하고, 각 NSF(들)에 대한 다양한 정보(예를 들어, 네트워크 액세스(access) 정보 및 작업로드(workload) 상태 등)를 유지할 수 있다. 또한, 네트워크 운영 관리 시스템(또는 보안 제어기)은 개발자 관리 시스템의 도움을 받아 NSF 인스턴스의 동적인 수명시간(life-cycle) 관리를 통해 NSF 인스턴스(instance)의 풀(pool)을 동적으로 관리할 수 있다.
NSF
NSF는 보안 관련 서비스를 제공하는 논리적 엔티티(logical entity) 또는 소프트웨어 컴포넌트이다. 예를 들면, NFC(예컨대, 방화벽)는 저수준 보안정책을 수신하고, 이에 기초하여 악의적인 네트워크 트래픽을 감지하고, 이를 차단하거나 완화할 수 있다. 이를 통해, 네트워크 통신 스트림의 무결성(integrity) 및 기밀성(confidentiality)이 보장될 수 있다.
개발자 관리 시스템
개발자 관리 시스템은 다른 I2NSF 컴포넌트(예컨대, 네트워크 운영 관리 시스템)으로 정보(예컨대, NSF의 정보)를 보내거나, 및/또는 보안 서비스(예컨대, 네트워크 보안 서비스)를 제공하는 I2NSF 컴포넌트이다. 개발자 관리 시스템은 벤더 관리 시스템(Vendor's Management System)으로 지칭될 수도 있다. 이러한 개발자 관리 시스템에 할당된 역할을 수행하는 대상은 I2NSF 생산자(producer)로 지칭될 수 있다.
개발자 관리 시스템은 네트워크 운영자에게 NSF(들)을 제공하는 제3자(third-party) 보안 벤더에 의해 관리될 수 있다. 다양한 보안 벤더의 다수의 개발자 관리 시스템(들)이 존재할 수 있다.
I2NSF 소비자-직면 인터페이스(간단히, 소비자-직면 인터페이스(CFI))
CFI는 I2NSF 사용자와 네트워크 운영 관리 시스템 사이에 위치하는, 사용자의 I2NSF 시스템으로의 인터페이스이다. 이렇게 설계됨으로써, I2NSF 시스템은 하위(underlying) NSF(들)의 상세한 내용을 숨기고, 사용자에게 NSF(들)의 추상적인 시각(abstract view)만을 제공할 수 있다.
이 CFI는 주어진 I2NSF 시스템의 상이한 사용자가 관리 도메인 내의 특정 흐름(flow)에 대한 보안 정책을 정의, 관리 및 모니터링할 수 있게 하기 위해 사용될 수 있다. I2NSF 사용자에 의해 생성된 고수준 보안 정책(또는 정책 규칙)은 이 CFI를 통해 네트워크 운영 관리 시스템으로 전달될 수 있다. 또한, NSF(들)에 의한 보안 경보(alert)는 이 CFI를 통해 네트워크 운영 관리 시스템으로부터 I2NSF 사용자로 전달될 수 있다.
I2NSF NSF-직면 인터페이스(간단히, NSF-직면 인터페이스( NFI ))
NFI는 네트워크 운영 관리 시스템(또는 보안 제어기)과 NSF(들) 사이에 위치하는 인터페이스이다.
NFI의 주요한 목적은 NSF(들)로부터 보안 관리 기법을 분리(decouple)함으로써 다양한 보안 솔루션 벤더들의 NSF(들)을 제어하고 관리하기 위한 표준화된 인터페이스를 제공하기 위함이다. NFI는 NSF(들)의 상세한 내용(예를 들어, 벤더, 유형 인자(form factor) 등)과 독립된다. 따라서, 보안 정책 규칙을 NSF에게 설정할 때, 네트워크 운영 관리 시스템은 벤더 특정한 차이 및/또는 NSF의 폼 팩터(form factor)를 고려할 필요가 없다. 이 NFI는 하나 이상의 NSF에 의해 시행되는 흐름-기반(flow-based) 보안 정책을 지정하고 모니터링하기 위해 사용될 수 있다. 예를 들면, 네트워크 운영 관리 시스템은 I2NSF 사용자에 의한 고수준 보안 정책을 시행하기 위하여 흐름-기반(flow-based) 보안 정책을 NFI 인터페이스를 통해, 각 흐름-기반 NSF에게 전달할 수 있다. 여기서, 흐름-기반 NSF는 보안 특성을 강화하기 위해 정책의 세트에 따라 네트워크 흐름을 검사하는 NSF이다. 이러한 흐름-기반 NSF에 의한 흐름-기반 보안은 수신된 순서대로 패킷들이 검사되고, 검사 프로세스에 따라 패킷에 대한 수정이 없는 것을 의미한다. 흐름-기반 NSF에 대한 인터페이스는 다음과 같이 분류될 수 있다:
- NSF 운영 및 관리 인터페이스(NSF Operational and Administrative Interface): NSF의 운영 상태를 프로그래밍하기 위해 I2NSF 관리 시스템에 의해 사용되는 인터페이스 그룹; 이 인터페이스 그룹은 또한 관리 제어 기능을 포함한다. I2NSF 정책 규칙은 일관된 방식으로 이 인터페이스 그룹을 변경하는 한가지 방법을 나타낸다. 어플리케이션 및 I2NSF 컴포넌트가 그들이 송신 및 수신하는 트래픽의 동작을 동적으로 제어할 필요가 있기 때문에, I2NSF 노력(effort)의 대부분이 이 인터페이스 그룹에 집중된다.
- 모니터링 인터페이스(Monitoring Interface): 하나 이상의 선택된 NSF로부터의 모니터링 정보를 획득하기 위해 I2NSF 관리 시스템에 의해 사용되는 인터페이스 그룹; 이 인터페이스 그룹의 각 인터페이스는 쿼리 또는 리포트 기반 인터페이스일 수 있다. 둘 사이의 차이점은 쿼리 기반 인터페이스는 정보를 획득하기 위해 I2NSF 관리 시스템에 의해 사용되고, 이에 반하여 리포트 기반 인터페이스는 정보를 제공하기 위해 NSF에 의해 사용된다는 것이다. 이 인터페이스 그룹의 기능은 또한 SYSLOG 및 DOTS와 같은 다른 프로토콜에 의해 정의될 수 있다. I2NSF 관리 시스템은 정보의 수신에 기초하여 하나 이상의 동작(action)을 취할 수 있다. 이는 I2NSF 정책 규칙에 의해 지정되어야 한다. 이 인터페이스 그룹은 NSF의 운영 상태를 변경하지 않는다.
이와 같이, NFI는 흐름-기반 패러다임을 사용하여 개발될 수 있다. 흐름-기반 NSF의 공동 특성(common trait)은 수신된 패킷의 컨텐츠(예컨대, 헤더/페이로드) 및/또는 컨텍스트(예컨대, 세션 상태 및 인증 상태)에 기초하여 패킷을 처리하는 것이다. 이 특징은 I2NSF 시스템의 동작을 정의하기 위한 요구사항(requirement) 중 하나이다.
한편, I2NSF 관리 시스템은 주어진 NSF의 모든 기능들을 사용할 필요가 없으며, 모든 사용 가능한 NSF들을 사용할 필요도 없다. 따라서, 이 추상화(abstraction)는 NSF 특징(feature)을 NSF 시스템에 의해 빌딩 블록(building block)으로 취급될 수 있게 해준다. 그러므로, 개발자는 벤더 및 기술에 독립적인 NSF에 의해 정의되는 보안 기능을 자유롭게 사용할 수 있게 된다.
I2NSF 등록 인터페이스(간단히, 등록 인터페이스(RI))
RI는 네트워크 운영 관리 시스템 및 개발자 관리 시스템 사이에 위치하는 인터페이스이다. 상이한 벤더에 의해 제공되는 NSF는 상이한 능력(capability)을 가질 수 있다. 따라서, 상이한 벤더에 의해 제공되는 여러 유형의 보안 능력을 이용하는 프로세스를 자동화하기 위해, 벤더가 그들의 NSF의 기능을 정의하기 위한 전용 인터페이스를 가질 필요가 있다. 이러한 전용 인터페이스는 I2NSF 등록 인터페이스(RI)로 지칭될 수 있다.
NSF의 능력은 미리 구성되거나 또는 I2NSF 등록 인터페이스를 통해 동적으로 검색될 수 있다. 만일 소비자에게 노출되는 새로운 기능이 NSF에 추가된다면, 관심 있는(interested) 관리 및 제어 엔티티가 그것들을 알 수 있도록, 그 새로운 기능의 능력이 이 RI를 통해 I2NSF 레지스트리(registry)에 등록될 필요가 있다.
도 2는 본 발명의 다른 실시예에 따른 I2NSF 시스템의 아키텍처를 예시한다. 도 2의 I2NSF 시스템은 도 1의 I2NSF 시스템에 비하여 I2NSF 사용자 및 네트워크 운영 관리 시스템의 구성을 더 구체적으로 나타낸다. 도 2에서는 도 1에서 상술한 설명과 중복된 설명은 생략한다.
도 2를 참조하면, I2NSF 시스템은 I2NSF 사용자, 보안 관리 시스템(Security Management System), 및 NSF 인스턴스(instances) 계층을 포함한다. I2NSF 사용자 계층은 어플리케이션 로직(Application Logic), 정책 업데이터(Policy Updater), 및 이벤트 수집기(Event Collector)을 컴포넌트로서 포함한다. 보안 관리 시스템 계층은 보안 제어기 및 개발자 관리 시스템을 포함한다. 보안 관리 시스템 계층의 보안 제어기는 보안 정책 관리자(Security policy manager) 및 NSF 기능 관리자(NSF capability manager)를 컴포넌트로서 포함한다.
I2NSF 사용자 계층은 소비자-직면 인터페이스를 통해 보안 관리 시스템 계층과 통신한다. 예를 들면, I2NSF 사용자 계층의 정책 업데이터 및 이벤트 수집기는 소비자-직면 인터페이스를 통해 보안 관리 시스템 계층의 보안 제어기와 통신한다. 또한, 보안 관리 시스템 계층은 NSF-직면 인터페이스를 통해 NFC 인스턴스 계층과 통신한다. 예를 들면, 보안 관리 시스템 계층의 보안 제어기는 NSF-직면 인터페이스를 통해 NFC 인스턴스 계층의 NSF 인스턴스(들)과 통신한다. 또한, 보안 관리 시스템 계층의 개발자 관리 시스템은 등록 인터페이스를 통해 보안 관리 시스템 계층의 보안 제어기와 통신한다.
도 2의 I2NSF 사용자 계층, 보안 관리 시스템 계층의 보안 제어기 컴포넌트, 보안 관리 시스템 계층의 개발자 관리 시스템 컴포넌트 및 NSF 인스턴스 계층은 각각 도 1의 I2NSF 사용자 컴포넌트, 네트워크 운영 관리 시스템 컴포넌트, 개발자 관리 시스템 컴포넌트 및 NSF 컴포넌트에 대응된다. 또한, 도 2의 소비자-직면 인터페이스, NSF-직면 인터페이스 및 등록 인터페이스는 도 1의 소비자-직면 인터페이스, NSF-직면 인터페이스 및 등록 인터페이스에 대응된다. 이하에서는, 각 계층에 포함된 새로 정의된 컴포넌트들에 대하여 설명한다.
I2NSF 사용자
상술한 것처럼, I2NSF 사용자 계층은 다음 3 개의 컴포넌트를 포함한다: 어플리케이션 로직(Application Logic), 정책 업데이터(Policy Updater), 및 이벤트 수집기(Event Collector). 각각의 역할 및 동작을 설명하면 다음과 같다.
어플리케이션 로직은 고수준 보안 정책을 생성하는 컴포넌트이다. 이를 위해, 어플리케이션 로직은 이벤트 수집기로부터 고수준 정책을 업데이트(또는 생성)하기 위한 이벤트를 수신하고, 수집된 이벤트에 기초하여 고수준 정책을 업데이트(또는 생성)한다. 그 이후에, 고수준 정책은 보안 제어기로 배포하기 위해 정책 업데이터로 보내진다. 고수준 정책을 업데이트(또는 생성)하기 위해, 이벤트 수집기는 보안 수집기에 의해 보내진 이벤트를 수신하고, 그들을 어플리케이션 로직으로 보낸다. 이 피드백에 기초하여, 어플리케이션 로직은 고수준 보안 정책을 업데이트(또는 생성)할 수 있다.
도 2에서는, 어플리케이션 로직, 정책 업데이터 및 이벤트 수집기를 각각 별도의 구성으로 도시하고 있으나, 본 발명의 이에 한정되지 않는다. 다시 말해, 각각은 논리적인 컴포넌트로서, I2NSF 시스템에서 하나 또는 복수의 컴포넌트로 구현될 수도 있다. 예를 들면, 도 1과 같이 단일의 I2NSF 사용자 컴포넌트에 의해 구현될 수 있다.
보안 관리 시스템
상술한 것처럼, 보안 관리 시스템 계층의 보안 제어기는 다음 2개의 컴포넌트를 포함한다: 보안 정책 관리자(Security policy manager) 및 NSF 능력 관리자(NSF capability manager). 각각의 역할 및 동작을 설명하면 다음과 같다.
보안 정책 관리자는 CFI를 통해 정책 업데이터로부터 고수준 정책을 수신하고, 이 정책을 여러 저수준 정책으로 맵핑할 수 있다. 이 저수준 정책은 NSF 능력 관리자에 등록된 주어진 NSF 능력과 관련된다. 또한, 보안 정책 관리자는 이 정책을 NFI를 통해 NSF(들)로 전달할 수 있다.
NSF 능력 관리자는 주어진 NSF 능력과 관련된 저수준 정책을 생성하기 위해, 개발자 관리 시스템에 의해 등록된 NSF의 능력을 지정하고, 그것을 보안 정책 관리자와 공유할 수 있다. 새로운 NSF가 등록될 때마다, NSF 능력 관리자는 등록 인터페이스를 통해 NSF 능력 관리자의 관리 테이블에 NSF의 기능/능력을 등록하도록 개발자 관리 시스템에 요청할 수 있다. 개발자 관리 시스템은 새로운 NSF의 능력을 NSF 능력 관리자로 등록하기 위한 보안 관리 시스템의 다른 부분에 해당한다.
도 2에서는, 보안 정책 관리자 및 NSF 능력 관리자를 각각 별도의 구성으로 도시하고 있으나, 본 발명의 이에 한정되지 않는다. 다시 말해, 각각은 논리적인 컴포넌트로서, I2NSF 시스템에서 하나의 컴포넌트로 구현될 수도 있다.
NSF 인스턴스 (NSF Instances)
도 2에 도시된 것처럼, NSF 인스턴스 계층은 NSF들을 포함한다. 이때, 모든 NSF들은 이 NSF 인스턴스 계층에 위치된다. 한편, 고수준 정책을 저수준 정책에 맵핑한 후에, 보안 정책 관리자는 NFI를 통해 정책을 NSF(들)로 전달한다. 이 경우, NFC는 수신된 저수준 보안 정책에 기초하여 악의적인 네트워크 트래픽을 감지하고, 이를 차단하거나 완화할 수 있다.
능력 정보 모델(Capability Information Model)
이하에서는, 보안 제어기(Security Controller)와 개발자 관리 시스템(Developer’s Management System)간 I2NSF 등록 인터페이스에 대한 능력 정보 모델을 설명한다. 능력 정보 모델은 등록 인터페이스를 통해 NSF 인스턴스(instance) 생성, 등록 및 삭제 요청을 지원해야 한다. 본 명세서에서는 이러한 기능을 위한 I2NSF 등록 인터페이스를 통한 절차를 설명한다. 또한, I2NSF 등록 인터페이스를 통해 교환하는 구체적인 정보를 설명한다.
다수의 가상 NSF 인스턴스는 일반적으로 I2NSF 프레임 워크에 존재한다. 이러한 NSF 인스턴스는 서로 다른 보안 기능을 가질 수 있기 때문에, 각각의 NSF 인스턴스의 보안 기능을 생성된 이후 보안 제어기에 등록하는 것이 중요하다. 또한, 필요시 일부 보안 기능의 NSF를 인스턴스화 해야 한다. 예를 들어, I2NSF 사용자가 요구하는 새로운 보안 요구 사항을 충족하기 위해 추가 보안 기능이 필요한 경우, 보안 제어기는 필요한 보안 기능이 있는 NSF를 인스턴스화 하도록 개발자 관리 시스템에 요청할 수 있어야 한다.
본 발명에서는, NSF 등록 및 인스턴스화를 지원하기 위하여 보안 제어기와 개발자 관리 시스템간 등록 인터페이스에 필요한 능력 정보 모델을 제안한다.
또한, 본 발명에서는, 등록 인터페이스를 통해 보안 제어기와 개발자 관리 시스템에 의해 수행되는 능력 정보 모델에 기반한 절차를 제안한다.
기존의 I2NSF 등록 인터페이스는 보안 제어기에 새로운 NSF 인스턴스를 등록하는 경우에 한하여 사용되었다. 반면에, 본 발명에서는 필요한 경우 NSF 인스턴스화(instantiation)/역인스턴스화(deinstantiation)를 지원하기 위해 그 활용도를 확장하고 기능을 위하여 등록 인터페이스를 통해 교환되어야 하는 정보를 제안한다. 또한, 본 발명에서는, 등록 인터페이스의 경우 NSF 능력 정보(즉, NSF의 능력)을 명확히하여 I2NSF 프레임 워크의 구성 요소가 능력들의 세트를 표준화된 방식으로 교환할 수 있어야 하기 때문에, 이를 위한 NSF 능력 정보 모델을 정의한다.
본 명세서에서, NSF(Network Security Function)는 수신된 패킷의 특정 처리를 담당하는 기능을 말한다. NSF는 프로토콜 스택의 다양한 계층(예를 들어, 네트워크 계층 또는 다른 개방형 시스템간 상호 접속(OSI: Open System Interconnection) 계층)에서 작동할 수 있다.
또한, 본 명세서에서, NSF(또는 네트워크 보안 서비스 기능)은, 예를 들어, 방화벽, 침입 방지 시스템/침입 탐지 시스템(IPS: Intrusion Prevention System/IDS: Intrusion Detection System), 딥 패킷 검사(DPI: Deep Packet Inspection), 어플리케이션 가시성 및 제어(AVC: Application Visibility and Control), 네트워크 바이러스 및 맬웨어 검사(malware scanning), 샌드 박스(sandbox), 데이터 손실 방지(DLP: Data Loss Prevention)), 디도스(DDoS: Distributed Denial of Service) 완화(mitigation) 및 전송 계층 보안(TLS: Transport Layer Security) 프록시(proxy)와 같은 서비스를 나타낼(또는 제공할) 수 있다.
또한, 본 명세서에서, 고급 검사/조치(Advanced Inspection/Action)는 NSF 직면 인터페이스에 대한 I2NSF 정보 모델과 마찬가지로, 보안 기능이 자체 검사 결과에 기반하여 추가 검사를 위해 다른 보안 기능을 호출함을 나타낼 수 있다.
또한, 본 명세서에서, NSF 능력 정보 모델은 NSF 인스턴스의 보안 능력 및 수행 능력을 나타낸다. 각각의 NSF 인스턴스에는 제공할 수 있는 보안 서비스의 유형과 수행 능력을 나타내는 자체 NSF 능력 정보 모델을 가진다.
본 발명의 일 실시예에서, 보안 제어기와 개발자 관리 시스템간 등록 인터페이스를 통해 NSF 인스턴스를 등록할 수 있다.
도 3은 본 발명이 적용되는 실시예로서, 등록 인터페이스를 통해 NSF 인스턴스를 등록하는 방법을 나타내는 흐름도이다.
도 3을 참조하면, 보안 제어기는 인스턴스화 요청 메시지를 개발자 관리 시스템으로 전송한다(S301). 보안 제어기 및 개발자 관리 시스템은 앞서 도 2에서 설명한 I2NSF 프레임 워크의 구성 요소를 나타낸다.
보안 제어기로부터 인스턴스화 요청 메시치를 수신하면, 개발자 관리 시스템은 해당 NSF 인스턴스를 생성할 수 있다. 예를 들어, S301 단계에 앞서, 보안 제어기는 현재 시스템에서 필요한 능력들 세트(즉, NSF 능력 정보) 또는 특정 NSF의 서명을 인식할 수 있다. 그리고, 보안 제어기는 인식된 정보를 포함하는 인스턴스화 요청 메시지를 개발자 관리 시스템으로 전송할 수 있다. 개발자 관리 시스템은 수신된 정보를 능력 정보 모델 정의에 기반한 NSF와 일치시키고, 상기 수신된 정보와 일치하는 NSF 인스턴스를 생성할 수 있다.
또는, 보안 제어기는 역인스턴스화 요청 메시지를 개발자 관리 시스템으로 전송할 수 있다. 보안 제어기로부터 역인스턴스화 요청 메시지를 수신하면, 개발자 관리 시스템은 해당 NSF 인스턴스를 제거할 수 있다.
예를 들어, 예를 들어, S301 단계에 앞서, 보안 제어기는 현재 시스템에서 불필요한 능력들 세트(즉, NSF 능력 정보) 또는 특정 NSF의 서명을 인식할 수 있다. 보안 제어기는 인식된 정보를 포함하는 역인스턴스화 요청 메시지를 개발자 관리 시스템으로 전송할 수 있다. 개발자 관리 시스템은 수신된 정보를 능력 정보 모델 정의에 기반한 NSF와 일치시키고, 상기 수신된 정보와 일치하는 NSF 인스턴스를 제거할 수 있다.
보안 제어기는 NSF 인스턴스의 등록을 위한 등록 메시지를 개발자 관리 시스템으로부터 수신한다(S302). 이 경우, 보안 제어기는 등록 메시지를 수신한 후 해당 NSF 인스턴스를 시스템의 사용 가능한 NSF 인스턴스 목록에 추가할 수 있다.
만약 S301 단계에서 보안 제어기가 인스턴스화 요청 메시지가 아닌 역인스턴스화 요청 메시지를 전송한 경우, 보안 제어기는 개발자 관리 시스템으로부터 삭제 메시지를 수신할 수 있다. 이 경우, 보안 제어기는 해당 NSF 인스턴스를 시스템의 사용 가능한 NSF 인스턴스 목록에서 제거할 수 있다.
또한, 일 실시예에서, 개발자 관리 시스템은 NSF 인스턴스를 등록할 수 있다. 구체적으로, 시스템의 보안 요구 사항에 따라 일부 NSF가 기본적으로 요구될 수 있다. 이 경우, 개발자 관리 시스템은 보안 제어기의 요청 없이 이러한 기본 NSF 인스턴스를 생성할 수 있다. 개발자 관리 시스템은 NSF 인스턴스들을 생성한 후, 등록 인터페이스를 통해 보안 제어기에 NSF 인스턴스(또는 NSF 인스턴스에 관련된 정보)를 통지할 수 있다.
또한, 일 실시예에서, 등록 인터페이스를 통해 다른 NSF에 의해 트리거된 고급 검사/조치를 제공하는 NSF 인스턴스가 생성될 수 있다. 즉, I2NSF 프레임 워크에서 NSF는 트래픽(traffic)의 고급 보안 검사를 위하여 다른 유형의 NSF를 트리거할 수 있다. 이때, 다음 NSF는 현재 NSF의 검사 결과 및 I2NSF 사용자 정책에 의해 결정될 수 있다. 그러나, 만약 이전 NSF에 의해 트리거된 고급 검사/조치를 제공할 수 있는 NSF 인스턴스가 없는 경우, 보안 제어기는 등록 인터페이스를 통해 개발자 관리 시스템에 요청하여 NSF 인스턴스를 생성할 수 있다.
또한, 일 실시예에서, I2NSF 사용자로부터 수신된 보안 정책 규칙을 시행함에 있어서 필요한 NSF 인스턴스가 생성될 수 있다. 즉, I2NSF 프레임 워크에서 I2NSF 사용자는 시스템에 필요한 보안 서비스를 결정할 수 있다. 만약 I2NSF 사용자가 요청한 보안 정책을 시행할 NSF 인스턴스가 없는 경우, 보안 제어기는 등록 인터페이스를 통해 개발자 관리 시스템에 요청하여 필요한 NSF 인스턴스를 생성할 수 있다.
또한, 일 실시예에서, 더 이상 필요하지 않은 NSF 인스턴스는 삭제될 수 있다. 다양한 유형의 NSF 인스턴스가 I2NSF 프레임 워크에서 실행될 수 있고, 시스템에서 수행될 보안 정책의 동적 변경에 따라 일부 유형의 NSF 인스턴스가 더 이상 필요하지 않을 수 있다. 이 경우, 보안 제어기는 등록 인터페이스를 통해 NSF 인스턴스를 파기하도록 개발자 관리 시스템에 요청할 수 있다.
도 4는 본 발명의 일 실시예에 따른 등록 인터페이스의 정보 모델을 예시하는 도면이다.
도 4를 참조하면, 등록 인터페이스의 정보 모델은 인스턴스 관리 서브 모델(또는 하위 모델) 및/또는 등록 서브 모델을 포함할 수 있다. 인스턴스 관리 기능 및 등록 기능은 목적 달성을 위하여 NSF 능력 정보 모델이 사용될 수 있다. 여기서, NSF 능력 정보 모델은 NSF 인스턴스가 제공할 수 있는 검사 능력을 설명 및/또는 규정하는 능력 객체를 나타낸다.
즉, 등록 인터페이스 정보 모델 중에서 인스턴스 관리 서브 모델을 통해 NSF 인스턴스가 생성/제거될 수 있고, 등록 서브 모델에서 NSF 능력 정보 모델을 구성하는 세부 정보들이 정의될 수 있다.
NSF 인스턴스 관리 메커니즘(Instance Management Mechanism)
도 5는 본 발명의 일 실시예에 따른 인스턴스 관리 서브 모델(Instance Management Sub-Model)을 예시하는 도면이다.
도 5를 참조하면, I2NSF 프레임 워크의 보안 제어기는 NSF의 인스턴스 관리를 위해 인스턴스화 요청 및/또는 역인스턴스화(Deinstantiation) 요청을 수행할 수 있다.
도 5(a)를 참조하면, 보안 제어기는 필요한 경우 개발자 제어 시스템에 인스턴스화 요청 메시지를 전송할 수 있다. 보안 제어기로부터 요청을 수신한 개발자 제어 시스템은 NSF 능력 정보에 기반하여 해당 NSF 인스턴스를 생성하고 보안 제어기에 처리 결과에 관련된 정보를 포함하는 응답 메시지를 전송할 수 있다.
도 5(b)를 참조하면, 보안 제어기는 필요한 경우 개발자 제어 시스템에 역인스턴스화 요청 메시지를 전송할 수 있다. 보안 제어기로부터 요청을 수신한 개발자 제어 시스템은 NSF 접근 정보에 기반하여 해당 NSF 인스턴스를 제거하고 보안 제어기에 처리 결과에 관련된 정보를 포함하는 응답 메시지를 전송할 수 있다.
NSF 등록 메커니즘(Registration Mechanism)
도 6은 본 발명의 일 실시예에 따른 등록 서브 모델(Registration Sub-Model)을 예시하는 도면이다.
도 6을 참조하면, 개발자 관리 시스템은 새로운 NSF 인스턴스를 등록하기 위하여 보안 제어기에 등록 메시지를 전송(또는 생성)할 수 있다. 이때, 상기 등록 메시지는 NSF 능력 정보(Capability Information) 및 NSF 접근 정보(Access Information) 를 포함할 수 있다.
NSF 능력 정보는 새로운 NSF 인스턴스의 검사 능력을 나타낸다. 그리고, NSF 접근 정보는 다른 구성 요소의 새로운 인스턴스에 대한 네트워크 접근을 가능하게 하는 정보를 나타낸다. NSF 능력 정보와 NSF 접근 정보의 세부 정보 모델은 자세히 후술한다.
위와 같은 등록 프로세스 이후, I2NSF 능력 인터페이스(capability interface)는 새롭게 등록된 NSF 인스턴스를 제어하고 모니터링할 수 있다.
NSF 접근 정보(Access Information)
NSF 접근 정보는 NSF와 통신을 수행하기 위하여 요구되는 정보를 나타낸다. 본 발명의 일 실시예에서, NSF 접근 정보는 IPv4(Internet Protocol version 4) 주소(address), IPv6(Internet Protocol version 6) 주소, 포트 번호(port number) 및/또는 지원되는 전송 프로토콜(transport protocol)을 포함할 수 있다.
여기서 지원되는 전송 프로토콜은, 예를 들어, 가상 확장(Virtual Extensible) LAN(VXLAN), VXLAN를 위한 일반 프로토콜 확장(VXLAN-GPE(Generic Protocol Extension)), 일반 경로 캡슐화(GRE: Generic Route Encapsulation), 이더넷(Ethernet) 등을 포함할 수 있다.
NSF 접근 정보는 전반적인 시스템(또는 NSF 인스턴스 리스트) 내에서 NSF 인스턴스의 서명(또는 고유 식별자)를 나타낸다. NSF 접근 정보는 특정 NSF 인스턴스를 식별하는 데 사용될 수 있다.
NSF 능력 정보(Capability Information)
도 7은 본 발명의 일 실시예에 따른, NSF 능력 정보(Capability Information)를 개략적으로 나타내는 도면이다.
도 7을 참조하면, NSF 인스턴스의 보안 능력을 나타내는 NSF 능력 정보는 다양한 NSF 인스턴스의 능력 객체 (capability object)들을 포함할 수 있다.
구체적으로, NSF 능력 정보(또는 능력 객체)는 네트워크 보안 능력(Network-Security Capabilities), 컨텐츠 보안 능력(Content-Security Capabilities), 공격 완화 능력(Attack Mitigation Capabilities), 수행 능력(performance capabilities)을 포함할 수 있다.
네트워크 보안 능력은 미리 정의된 보안 정책을 사용하여 네트워크 트래픽을 검사하고 처리하는 능력을 나타낸다. 컨텐츠 보안 능력 어플리케이션(application) 레이어에서 전달되는 트래픽 내용을 분석하는 능력을 나타낸다. 또한, 공격 완화 능력은 다양한 유형의 네트워크 공격을 탐지하고 완화하는 능력을 나타낸다.
수행 능력과 역할 기반 ACL은 이하에서 상세히 설명한다.
수행 능력(Performance Capabilities)
도 8은 본 발명의 일 실시예에 따른, 수행 능력(Performance Capabilities) 정보를 개략적으로 나타내는 도면이다.
도 8을 참조하면, 수행 능력 정보는 처리(Processing) 및/또는 대역폭(Bandwidth) 필드(또는 정보)를 포함할 수 있다. 여기서, 수행 능력 정보는 NSF의 처리 능력(processing capability)을 나타낸다.
수행 능력 정보는 NSF가 현재 담당하는 작업량(workload)과 해당 정보의 비교를 통해 NSF가 정체(congestion) 상태인지 여부를 결정하는 데 사용될 수 있다. 또한, 수행 능력 정보는 NSF에서 이용 가능한 능력과 같은 각각의 유형의 자원의 이용 가능한 양을 지정하는 데 사용될 수 있다.
또한, 처리 정보는 NSF의 사용 가능한 처리 능력(processing power)를 나타낸다. 대역폭은 아웃 바운드(outbound), 인바운드(inbound)의 두 가지 경우에 사용 가능한 네트워크 양에 대한 정보를 나타낸다. 처리 정보 및 대역폭 정보는 보안 제어기에 의한 NSF의 인스턴스(또는 인스턴스화) 요청에 사용될 수 있다.
본 명세서 제안하는 등록 인터페이스는 생성된 인스턴스의 사용 및 제한을 제어할 수 있으며, 상태(status)에 따라 적절한 요청을 수행할 수 있다.
역할 기반 ACL (Role-based Access Control List)
역할 기반 ACL 정보는 엔티티(entity)에 부여된 역할에 따라 NSF에 대한 엔티티 접근을 허용할지 또는 거부할지 결정하기 위하여 NSF의 접근 정책을 지정할 수 있다. 각각의 NSF는 역할 기반 ACL과 연결되어 엔티티의 접근 요청을 허용할지 또는 거부할지 결정할 수 있다.
도 9 및 도 10은 본 발명의 일 실시예에 따른 역할 기반 ACL(Role-based Access Control List)을 예시하는 도면이다.
도 9를 참조하면, 역할 기반 ACL는 하나 이상의 역할 ID를 포함할 수 있다. 여기서, 역할 ID는 엔티티(예: 관리자, 개발자 등)의 역할을 식별하는데 이용되는 정보를 나타낸다.
도 10을 참조하면, 역할 기반 ACL에 포함되는 각각의 역할 ID는 허용/거부로 분류되는 접근 유형들을 포함할 수 있다. 즉, 역할 기반 ACL은 각각의 역할 ID에서 허용되거나 거부되는 접근 유형들의 집합으로 구성될 수 있다. 여기서, 접근 유형은 NSF 규칙(rule) 구성(configuration), NSF 규칙 업데이트(update) 및/또는 NSF 모니터링(monitoring)과 같은 특정 유형의 접근 요청을 식별하는데 사용될 수 있다.
본 명세서에서 제안하는 등록 인터페이스의 정보 모델은 아키텍처 변경없이 I2NSF 프레임 워크를 기반으로 할 수 있다. 따라서, 이 문서는 제안된 아키텍처에서 컴포넌트 간 안전한 통신을 달성하기 위하여 상술한 IETF 드래프트 문서(예컨대, rfc8329.txt)에서 명시된 I2NSF 프레임 워크의 보안 고려 사항을 공유할 수 있다.
도 11는 본 발명의 일 실시예에 따른 네트워크 장치의 블록 구성도를 예시한다. 네트워크 장치는 상술한 I2NSF 시스템(또는 보안 관리 시스템)에 해당하거나, I2NSF 시스템 내에 포함되는 장치일 수 있다. I2NSF 시스템 내에 포함되는 장치의 예로는 상술한 I2NSF, 보안 제어기, 개발자 관리 시스템, NSF 등이 포함될 수 있다.
도 11을 참조하면, 네트워크 장치(1100)는 프로세서(processor, 1110), 메모리(memory, 1120) 및 통신 모듈(communication module, 1130)을 포함한다.
프로세서(1110)는 앞서 도 1 내지 도 10에서 제안된 기능, 과정 및/또는 방법을 구현한다. 메모리(1120)는 프로세서(1110)와 연결되어, 프로세서(1110)를 구동하기 위한 다양한 정보를 저장한다. 통신 모듈(1130)은 프로세서(1110)와 연결되어, 유/무선 신호를 송신 및/또는 수신한다.
메모리(1120)는 프로세서(1110) 내부 또는 외부에 있을 수 있고, 잘 알려진 다양한 수단으로 프로세서(1110)와 연결될 수 있다.
이상에서 설명된 실시예들은 본 발명의 구성요소들과 특징들이 소정 형태로 결합된 것들이다. 각 구성요소 또는 특징은 별도의 명시적 언급이 없는 한 선택적인 것으로 고려되어야 한다. 각 구성요소 또는 특징은 다른 구성요소나 특징과 결합되지 않은 형태로 실시될 수 있다. 또한, 일부 구성요소들 및/또는 특징들을 결합하여 본 발명의 실시예를 구성하는 것도 가능하다. 본 발명의 실시예들에서 설명되는 동작들의 순서는 변경될 수 있다. 어느 실시예의 일부 구성이나 특징은 다른 실시예에 포함될 수 있고, 또는 다른 실시예의 대응하는 구성 또는 특징과 교체될 수 있다. 특허청구범위에서 명시적인 인용 관계가 있지 않은 청구항들을 결합하여 실시예를 구성하거나 출원 후의 보정에 의해 새로운 청구항으로 포함시킬 수 있음은 자명하다.
본 발명에 따른 실시예는 다양한 수단, 예를 들어, 하드웨어, 펌웨어(firmware), 소프트웨어 또는 그것들의 결합 등에 의해 구현될 수 있다. 하드웨어에 의한 구현의 경우, 본 발명의 일 실시예는 하나 또는 그 이상의 ASICs(application specific integrated circuits), DSPs(digital signal processors), DSPDs(digital signal processing devices), PLDs(programmable logic devices), FPGAs(field programmable gate arrays), 프로세서, 콘트롤러, 마이크로 콘트롤러, 마이크로 프로세서 등에 의해 구현될 수 있다.
또한, 펌웨어나 소프트웨어에 의한 구현의 경우, 본 발명의 일 실시예는 이상에서 설명된 기능 또는 동작들을 수행하는 모듈, 절차, 함수 등의 형태로 구현되어, 다양한 컴퓨터 수단을 통하여 판독 가능한 기록매체에 기록될 수 있다. 여기서, 기록매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 기록매체에 기록되는 프로그램 명령은 본 발명을 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 가능한 것일 수도 있다. 예컨대 기록매체는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체(Magnetic Media), CD-ROM(Compact Disk Read Only Memory), DVD(Digital Video Disk)와 같은 광 기록 매체(Optical Media), 플롭티컬 디스크(Floptical Disk)와 같은 자기-광 매체(Magneto-Optical Media), 및 롬(ROM), 램(RAM), 플래시 메모리 등과 같은 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치를 포함한다. 프로그램 명령의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함할 수 있다. 이러한 하드웨어 장치는 본 발명의 동작을 수행하기 위해 하나 이상의 소프트웨어 모로서 작동하도록 구성될 수 있으며, 그 역도 마찬가지이다.
아울러, 본 발명에 따른 장치나 단말은 하나 이상의 프로세서로 하여금 앞서 설명한 기능들과 프로세스를 수행하도록 하는 명령에 의하여 구동될 수 있다. 예를 들어 그러한 명령으로는, 예컨대 JavaScript나 ECMAScript 명령 등의 스크립트 명령과 같은 해석되는 명령이나 실행 가능한 코드 혹은 컴퓨터로 판독 가능한 매체에 저장되는 기타의 명령이 포함될 수 있다. 나아가 본 발명에 따른 장치는 서버 팜(Server Farm)과 같이 네트워크에 걸쳐서 분산형으로 구현될 수 있으며, 혹은 단일의 컴퓨터 장치에서 구현될 수도 있다.
또한, 본 발명에 따른 장치에 탑재되고 본 발명에 따른 방법을 실행하는 컴퓨터 프로그램(프로그램, 소프트웨어, 소프트웨어 어플리케이션, 스크립트 혹은 코드로도 알려져 있음)은 컴파일 되거나 해석된 언어나 선험적 혹은 절차적 언어를 포함하는 프로그래밍 언어의 어떠한 형태로도 작성될 수 있으며, 독립형 프로그램이나 모듈, 컴포넌트, 서브루틴 혹은 컴퓨터 환경에서 사용하기에 적합한 다른 유닛을 포함하여 어떠한 형태로도 전개될 수 있다. 컴퓨터 프로그램은 파일 시스템의 파일에 반드시 대응하는 것은 아니다. 프로그램은 요청된 프로그램에 제공되는 단일 파일 내에, 혹은 다중의 상호 작용하는 파일(예컨대, 하나 이상의 모듈, 하위 프로그램 혹은 코드의 일부를 저장하는 파일) 내에, 혹은 다른 프로그램이나 데이터를 보유하는 파일의 일부(예컨대, 마크업 언어 문서 내에 저장되는 하나 이상의 스크립트) 내에 저장될 수 있다. 컴퓨터 프로그램은 하나의 사이트에 위치하거나 복수의 사이트에 걸쳐서 분산되어 통신 네트워크에 의해 상호 접속된 다중 컴퓨터나 하나의 컴퓨터 상에서 실행되도록 전개될 수 있다.
본 발명은 본 발명의 필수적 특징을 벗어나지 않는 범위에서 다른 특정한 형태로 구체화될 수 있음은 당업자에게 자명하다. 따라서, 상술한 상세한 설명은 모든 면에서 제한적으로 해석되어서는 아니 되고 예시적인 것으로 고려되어야 한다. 본 발명의 범위는 첨부된 청구항의 합리적 해석에 의해 결정되어야 하고, 본 발명의 등가적 범위 내에서의 모든 변경은 본 발명의 범위에 포함된다.
이상, 전술한 본 발명의 바람직한 실시예는, 예시의 목적을 위해 개시된 것으로, 당업자라면 이하 첨부된 특허청구범위에 개시된 본 발명의 기술적 사상과 그 기술적 범위 내에서, 다양한 다른 실시예들을 개량, 변경, 대체 또는 부가 등이 가능할 것이다.

Claims (11)

  1. 등록 인터페이스(Registration Interface)를 통해 네트워크 보안 기능(NSF: Network Secure Function)을 관리하는 보안 관리 시스템에서, 보안 제어기(Security Controller)에 의해 수행되는 방법은,
    상기 보안 관리 시스템에서 필요한 NSF에 대한 인스턴스화(instantiation) 요청 메시지를 개발자 관리 시스템(Developer’s Management System)으로 전송하는 단계; 및
    상기 요청 메시지에 대한 응답으로 상기 필요한 NSF에 대한 NSF 인스턴스의 등록을 지시하는 등록 메시지를 상기 개발자 관리 시스템으로부터 수신하는 단계를 포함하는 방법.
  2. 제1 항에 있어서,
    상기 보안 관리 시스템에서 필요한 NSF의 능력 정보(Capability Information) 또는 서명(signature)을 인식하는 단계를 더 포함하고,
    상기 인스턴스화 요청 메시지는 상기 능력 정보 또는 상기 서명을 포함하는 방법.
  3. 제1 항에 있어서,
    상기 NSF 인스턴스는 상기 인스턴스화 요청 메시지에 기초하여 개발자 관리 시스템에 의해 생성되는 방법.
  4. 제1 항에 있어서,
    상기 보안 관리 시스템에서 불필요한 NSF에 대한 역인스턴스화(de-instantiation) 요청 메시지를 개발자 관리 시스템으로 전송하는 단계를 더 포함하고,
    상기 역인스턴스화 요청 메시지에 대응되는 NSF 인스턴스가 상기 개발자 관리 시스템에 의해 삭제되는 방법.
  5. 제1 항에 있어서,
    상기 등록 메시지는 NSF 인스턴스의 보안 능력을 나타내는 NSF 능력 정보(Capability Information) 또는 새로운 인스턴스에 대한 네트워크 접근을 위해 이용되는 NSF 접근 정보(Access Information) 중 적어도 하나를 포함하는 방법.
  6. 제5 항에 있어서,
    상기 NSF 접근 정보는 IPv4(Internet Protocol version 4) 주소(address), IPv6(Internet Protocol version 6) 주소, 포트 번호(port number) 또는 지원되는 전송 프로토콜(transport protocol) 중 적어도 하나를 포함하는 방법.
  7. 제6 항에 있어서,
    상기 지원되는 전송 프로토콜은 가상 확장(Virtual Extensible) LAN(VXLAN), VXLAN를 위한 일반 프로토콜 확장(VXLAN-GPE(Generic Protocol Extension)), 일반 경로 캡슐화(GRE: Generic Route Encapsulation) 또는 이더넷(Ethernet) 중 적어도 하나를 포함하는 방법.
  8. 제5 항에 있어서,
    상기 NSF 능력 정보는 네트워크 보안 능력(Network-Security Capabilities), 컨텐츠 보안 능력(Content-Security Capabilities), 공격 완화 능력(Attack Mitigation Capabilities), 수행 능력(performance capabilities) 중 적어도 하나를 포함하는 방법.
  9. 제8 항에 있어서,
    상기 수행 능력은 처리(Processing) 및 대역폭(Bandwidth) 정보를 포함하는 방법.
  10. 제8 항에 있어서,
    상기 역할 기반 접근 제어 리스트는 엔티티의 역할 식별에 이용되는 하나 이상의 역할 ID를 포함하고,
    상기 역할 ID는 특정 유형의 접근 요청을 식별하는데 사용되는 하나 이상의 접근 유형을 포함하는 방법.
  11. 등록 인터페이스(Registration Interface)를 통해 네트워크 보안 기능(NSF: Network Secure Function)을 관리하는 보안 제어기(Security Controller)에 있어서,
    외부 장치와 무선 또는 유선으로 통신하기 위한 통신부; 및
    상기 통신부와 기능적으로 연결되는 프로세서를 포함하되, 상기 프로세서는,
    상기 보안 관리 시스템에서 필요한 NSF에 대한 인스턴스화(instantiation) 요청 메시지를 개발자 관리 시스템(Developer’s Management System)으로 전송하고, 및
    상기 요청 메시지에 대한 응답으로 상기 필요한 NSF에 대한 NSF 인스턴스의 등록을 지시하는 등록 메시지를 상기 개발자 관리 시스템으로부터 수신하는 장치.
PCT/KR2018/002954 2017-03-13 2018-03-13 네트워크 보안 기능에 대한 등록 인터페이스 정보 모델 WO2018169291A1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2017-0031424 2017-03-13
KR20170031424 2017-03-13

Publications (1)

Publication Number Publication Date
WO2018169291A1 true WO2018169291A1 (ko) 2018-09-20

Family

ID=63522477

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2018/002954 WO2018169291A1 (ko) 2017-03-13 2018-03-13 네트워크 보안 기능에 대한 등록 인터페이스 정보 모델

Country Status (1)

Country Link
WO (1) WO2018169291A1 (ko)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040042609A1 (en) * 2002-09-04 2004-03-04 Tekelec Methods and systems for enhancing network security in a telecommunications signaling network
US20100217850A1 (en) * 2009-02-24 2010-08-26 James Michael Ferris Systems and methods for extending security platforms to cloud-based networks
US20150207813A1 (en) * 2012-02-01 2015-07-23 Vorstack, Inc. Techniques for sharing network security event information
US20160226835A1 (en) * 2015-01-29 2016-08-04 Blackrock Financial Management, Inc. Authenticating Connections and Program Identity in a Messaging System
US20170012968A1 (en) * 2014-03-26 2017-01-12 Huawei Technologies Co., Ltd. Network function virtualization-based certificate configuration method, apparatus, and system

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040042609A1 (en) * 2002-09-04 2004-03-04 Tekelec Methods and systems for enhancing network security in a telecommunications signaling network
US20100217850A1 (en) * 2009-02-24 2010-08-26 James Michael Ferris Systems and methods for extending security platforms to cloud-based networks
US20150207813A1 (en) * 2012-02-01 2015-07-23 Vorstack, Inc. Techniques for sharing network security event information
US20170012968A1 (en) * 2014-03-26 2017-01-12 Huawei Technologies Co., Ltd. Network function virtualization-based certificate configuration method, apparatus, and system
US20160226835A1 (en) * 2015-01-29 2016-08-04 Blackrock Financial Management, Inc. Authenticating Connections and Program Identity in a Messaging System

Similar Documents

Publication Publication Date Title
WO2021060854A1 (ko) 네트워크 접속 제어 시스템 및 그 방법
CA3034809C (en) Extension of network control system into public cloud
US9407602B2 (en) Methods and apparatus for redirecting attacks on a network
US9906557B2 (en) Dynamically generating a packet inspection policy for a policy enforcement point in a centralized management environment
CN106575338B (zh) 加密体系架构
KR102136039B1 (ko) 소프트웨어 정의 네트워크에서의 보안
WO2023033586A1 (ko) Tcp 세션 제어에 기초하여 애플리케이션의 네트워크 접속을 제어하기 위한 시스템 및 그에 관한 방법
WO2017070712A1 (en) Distributed firewalls and virtual network services using network packets with security tags
WO2013048111A2 (ko) 클라우드 컴퓨팅 서비스로의 침입을 탐지하는 방법 및 장치
WO2018101565A1 (ko) 네트워크 가상화 환경에서 보안 관리를 위한 구조
MXPA06013129A (es) Contencion automatizada de un invasor en redes.
US10785196B2 (en) Encryption key management of client devices and endpoints within a protected network
WO2023085791A1 (ko) 컨트롤러 기반 네트워크 접속을 제어하기 위한 시스템 및 그에 관한 방법
US8607302B2 (en) Method and system for sharing labeled information between different security realms
WO2023090755A1 (ko) 가상화 인스턴스의 네트워크 접속을 제어하기 위한 시스템 및 그에 관한 방법
WO2023146304A1 (ko) 애플리케이션의 파일 송신 및 수신을 제어하기 위한 시스템 및 그에 관한 방법
WO2019098678A1 (ko) 보안 서비스를 제공하기 위한 방법 및 이를 위한 장치
WO2019088671A1 (ko) 네트워크 보안 서비스를 제공하기 위한 방법 및 이를 위한 장치
Han et al. State-aware network access management for software-defined networks
WO2016200232A1 (ko) 서버 장애 시 원격 서버 복구 시스템 및 방법
WO2018169291A1 (ko) 네트워크 보안 기능에 대한 등록 인터페이스 정보 모델
WO2018097422A1 (ko) 네트워크 보안 기능에 의해 트리거되는 트래픽 스티어링을 위한 방법 및 시스템, 이를 위한 장치
WO2018169287A1 (ko) 보안 서비스를 제공하기 위한 방법, 시스템 및 이를 위한 장치
JP6359260B2 (ja) クラウド環境においてセキュアなクレジットカードシステムを実現するための情報処理システムおよびファイアウォール装置
WO2018169293A1 (ko) 트래픽 스티어링을 위한 방법 및 시스템, 이를 위한 장치

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18768108

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18768108

Country of ref document: EP

Kind code of ref document: A1