WO2018101565A1 - 네트워크 가상화 환경에서 보안 관리를 위한 구조 - Google Patents

네트워크 가상화 환경에서 보안 관리를 위한 구조 Download PDF

Info

Publication number
WO2018101565A1
WO2018101565A1 PCT/KR2017/007108 KR2017007108W WO2018101565A1 WO 2018101565 A1 WO2018101565 A1 WO 2018101565A1 KR 2017007108 W KR2017007108 W KR 2017007108W WO 2018101565 A1 WO2018101565 A1 WO 2018101565A1
Authority
WO
WIPO (PCT)
Prior art keywords
security
nsf
policy
user
management system
Prior art date
Application number
PCT/KR2017/007108
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 WO2018101565A1 publication Critical patent/WO2018101565A1/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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general

Definitions

  • the present invention relates to a security management architecture of network function virtualization.
  • Network Functions Virtualization is a new area for the network industry. NFV separates network functions from dedicated hardware devices and implements these functions as pure software instances running on commodity production servers, ensuring lower network deployment and maintenance costs.
  • Network Security Functions such as firewalls, Intrusion Detection Systems (IDS), and Intrusion Protection Systems (IPS), are virtual, which can be automatically provided and dynamically moved according to real-time security requirements. It may be provided as a network function. In this specification, the description focuses on the NSF, not the general NFV.
  • NSF Interface to Network Security Functions
  • IETF Internet Engineering Task Force
  • an object of the present invention is to present a general architecture for NSF-based security management using NFV.
  • the specification mitigates some real-world attack scenarios, such as the proposed framework, such as blacklisting of risk domains, hourly access control policies, and suspicious call detection for Voice over IP (Voice over IP) to Voice over LTE (VoLTE) services. It is aimed at suggesting how to do it.
  • the proposed framework such as blacklisting of risk domains, hourly access control policies, and suspicious call detection for Voice over IP (Voice over IP) to Voice over LTE (VoLTE) services. It is aimed at suggesting how to do it.
  • the architecture for security management in network function virtualization may include an I2NSF framework, application logic, policy updater and event collector.
  • an application user may enforce a security policy from a user perspective in a user friendly manner. More specifically, the architecture according to an embodiment of the present invention provides a user-level security interface that does not require specific information about network resources and protocols, thereby providing a user with a security requirement in a more familiar manner. Can be defined.
  • the I2NSF user can directly establish a generalized security policy from the user's point of view, and can efficiently manage security by receiving feedback from the NSF.
  • FIG. 1 is a diagram illustrating an architecture for security management based on NFV.
  • FIG. 2 is a diagram illustrating a user interface of an I2NSF user.
  • FIG. 3 is a diagram illustrating a data model of a Consumer-Facing Interface.
  • FIG. 4 is a diagram illustrating a security management architecture of I2NSF.
  • FIG. 5 is a diagram illustrating a security management architecture of Malware domain blacklisting.
  • FIG. 6 illustrates a security management architecture within the I2NSF framework.
  • FIG. 7 illustrates a security management architecture for Malware domain blacklisting.
  • FIG. 8 is a flowchart illustrating a security management method of the security management system according to an embodiment of the present invention.
  • Network Function Virtualization provides a new way of designing and deploying network security services, but in the absence of standards / standardized network interface services between network security services, it provides a practical ecosystem to seamlessly integrate network security services. You may not be able to build. Therefore, the present specification proposes an architecture for a security management service based on NSF (Network Security Functions) using NFV.
  • NSF Network Security Functions
  • the proposed architecture allows users to define security requirements in a user-friendly manner by providing them with a user-level generalized security interface that does not require specific information about network resources and protocols.
  • the first embodiment proposes a basic component (eg, security policy manager, NSF capability manager, application logic, policy updater, and event collector) and an interface design method for the proposed architecture.
  • the first embodiment illustrates the use of the present invention in three cases: (1) blacklisting of risk domains, (2) hourly access control policies, and (3) suspicious call detection for VoIP-VoLTE services. Look around.
  • the present specification will be described in detail with reference to the implementation method of the proposed architecture.
  • the present specification looks at some technical challenges for deploying / applying the proposed architecture in a real network environment.
  • Section 2 proposes NFV based security management service architecture.
  • Section 3 describes three main uses of the proposed architecture.
  • Section 4 describes how to implement the proposed architecture in practice.
  • Section 5 describes the technical issues for the implementation of the architecture.
  • Section 6 provides a summary and analysis of related studies.
  • Section 7 discusses the conclusion.
  • FIG. 1 is a diagram illustrating an architecture for security management based on NFV.
  • the proposed architecture to support flexible and effective security policy enforcement includes (1) I2NSF user 100, (2) security management system 110 and (3) NSF instances 120, such as It can be composed of three layers.
  • the architecture of the present invention is designed to support flexible and effective security policy enforcement.
  • I2NSF user 100 herein refers to NFV-based security applications.
  • the application logic 100-1 may generate a user level security policy.
  • the policy updater 100-2 may distribute the policies to the security controller 110-1 through a consumer-facing interface.
  • the security policy manager 110-2 may map a user level policy to a lower level security policy related to the NSF capability registered in the NSF capability manager 110-3. After mapping, the security policy manager 110-2 may deliver the corresponding policies to the NSF 120 through an NSF Facing Interface.
  • NSF Facing Interface the operation of each network component will be described in detail.
  • the security policy manager 110-2 receives a user level policy from the policy updater 100-2 through the consumer-facing interface, and registers the user level policy with the specific NSF registered with the NSF capability manager 110-3.
  • the security policy manager 110-2 may deliver these policies to the NSF (s) via the NSF-Facing Interface.
  • the NSF 120 may transmit an event to the security policy manager 110-2 through the NSF Facing Interface. Thereafter, the security policy manager 110-2 may transmit the corresponding event to the event collector 100-3 through the consumer-facing interface.
  • the NSF capability manager 110-3 may be a configuration integrated with the security controller 110-1.
  • the NSF capability manager 110-3 stores the capabilities of the NSF registered in the developer management system 110-4 through the registration interface and shares them with the security policy manager 110-2 to secure the security policy manager 110-2. Allows the creation of low-level policies related to specific NSF capabilities.
  • the NSF capability manager 110-3 may request the developer's management system to register the capability of the NSF in the management table of the NSF capability manager 110-3 through the registration interface whenever a new NSF is registered. If the existing NSF is deleted, the NSF capability manager 110-3 may remove the capability of the NSF from the management table.
  • Developer management system 110-4 may be a component that registers a new NSF capability with NSF capability manager 110-3 via a registration interface. If there is an update in the registered NSF, the updated content / information may be delivered to the NSF capability manager 110-3 in the developer management system.
  • Application logic 100-1 may be a configuration that creates a user level security policy to block or mitigate security attacks (in a security management architecture).
  • the application logic 100-1 may receive an event to update (or create) a user level policy from the event collector 100-3, and update (or create) a user level policy based on the collected event. have.
  • the application logic 100-1 may transmit a user level policy to the policy updater 100-2 to deliver a recently updated policy. Section 3 below describes how to design the application logic 100-1 through three use cases.
  • the policy updater 100-2 receives a user level security policy generated by the application logic 100-1 and distributes / delivers it to the security controller 110-1 through the consumer-facing interface. Can be.
  • the event collector 100-3 may receive an event from the security controller 110-1 that should be reflected in the user-level policy update (or generation) of the application logic 100-1. Since the low-level security policy can be updated according to events occurring in the NSF, a procedure for receiving the event in the NSF is required. After receiving the event, the event collector 100-3 forwards it to the application logic 100-1 so that the application logic 100-1 can receive the user level based on the event received from the security controller 110-1. Update (or create) a security policy.
  • the general architecture based on NFV is designed to respond to possible security attacks. This section discusses blacklisted threats in dangerous domains, access control policies over time, and detection of suspicious calls for VoIP-VoLTE services.
  • Blacklisting dangerous domains means maintaining and publishing blacklists of IP addresses of attacking hosts, servers, and networks that are suspected of malicious activity.
  • the risk domain administrator can assume the role of application logic to perform security management.
  • the dangerous domain list is stored in the dangerous domain database and can be updated manually or automatically by the dangerous domain manager serving the application logic.
  • dangerous domain administrators can periodically load a list of dangerous domains from the Dangerous Domains database and use new user-level security policies (e.g. IP addresses) to prevent packet forwarding with newly added dangerous domains. Blacklist blocking).
  • Risky domain administrators can send new user-level security policies to policy renewers, and policy updates can deploy new user-level security policies received to security controllers.
  • the security controller can map user level policies to low level policies and apply low level security policies to the NSF.
  • NSF When NSF detects a new dangerous domain, it can send an IP address corresponding to the detected domain to the security controller through the NSF-Facing Interface.
  • the security controller can pass the IP address to the event collector.
  • the event collector passes the IP address to the risk domain manager, which allows the risk domain manager to update the risk domain database.
  • Hourly access control policies can manage a user's access to a particular website for a particular period of time. For example, in a company, administrators can block employees from accessing the Youtube website, which prevents employees from concentrating their work hours.
  • I2NSF users can register blacklists with blocking websites and blocking times in the application logic.
  • Application logic can store the list in a database and create user-level security policies (for example, check blocking websites and blocking times to block access to blocking websites during the blocking time).
  • the application logic passes the created user-level security policy to the policy updater, who can then forward it to the security controller.
  • the security policy administrator can map user-level policies to lower-level policies, then send and apply them to the NSF.
  • VoIP-VoLTE security management can maintain and publish illegal device blacklists, including IP addresses, source ports, expiration times, user agents, and SIP URIs of illegal call or suspected Session Initiation Protocol (SIP) devices.
  • VoIP-VoLTE security manager serves as the application logic for the VoIP-VoLTE security service in FIG.
  • the list of illegal device information is stored in the VoIP-VoLTE database and can be updated manually or automatically by the VoIP-VoLTE security manager.
  • the VoIP-VoLTE Security Manager periodically loads a list of illegal device information from the VoIP-VoLTE database and prevents packet forwarding with newly added VoIP-VoLTE attackers (e.g., Illegal device blacklists using IP addresses, source ports, etc.
  • the VoIP-VoLTE security manager can send the new user-level security policy created to the policy updater, and the policy updater can distribute the received user-level security policy to the security controller.
  • the security controller maps user-level policy to multiple lower-level policies and applies the lower-level security policy to the NSF.
  • information of the domain can be sent by the NSF to the security controller via the NSF Facing Interface.
  • the security controller can pass this to the event collector.
  • the event collector forwards the detected domain information to the VoIP-VoLTE security manager, which can update the VoIP-VoLTE database based thereon.
  • This section proposes a method of implementing each component and interface in the proposed architecture, and considers the example of using 3.3 above.
  • This implementation can be used to determine whether an incoming call has fraudulent phone activity (for example, a call from a blacklisted location during an abnormal time frame), thereby blocking suspicious VoIP-VoLTE calls.
  • FIG. 2 is a diagram illustrating a user interface of an I2NSF user.
  • two web pages may be considered: (1) a policy setting page for a policy updater and (2) a log message page for an event collector.
  • YANG is widely used to model configuration and state data manipulated by standard network protocols, such as RESTCONF, which provides a programming interface for accessing HTTP over data defined in YANG.
  • RESTCONF standard network protocols
  • YANG can be considered / used to define a data model for communication.
  • a field may be created for defining a user level security policy such as a country included in a blacklist for a certain time. If an administrator sets a new user level security policy, the I2NSF user's data model parser can interpret the policy and generate an XML file according to the YANG data model.
  • RESTCONF Network Configuration
  • FIG. 3 is a diagram illustrating a data model of a Consumer-Facing Interface.
  • Figure 3 shows part of the data model design related to policy management for detecting suspicious calls in VoIP-VoLTE services.
  • This data model may consist of (1) policy life cycle management, (2) policy rules, and (3) actions.
  • the Policy Lifecycle Management field may specify an expiration time and / or set of expiration events to determine the lifetime of the policy itself.
  • the policy rule field may indicate specific information about a user level policy such as a service type, a condition, and a valid time interval.
  • the Action field specifies what action to take. For example, if both permit and mirror are 'true', call traffic from caller locations that are blacklisted at the exception time (in the valid time interval) may be blocked, and deep packet inspection (Deep) It can be delivered sequentially to a predefined host for Packet Inspection (DPI).
  • DPI Deep packet inspection
  • the main role of the security management system is to translate user-level policies into lower-level policy sets. For example, a security management system may map a country name into a set of IP addresses using a geolocation database that provides each country's IP address. After converting the user level security policy, the security management system may create lower level security policies to direct network traffic to that IP address and / or that IP address.
  • the data model parser can generate an XML file for the low-level security policy and pass it on to the appropriate NSF instance.
  • the security management system may interpret the security event generated by the NSF as a user level log message of the YANG data model, and forward it to the I2NSF user in the opposite direction.
  • the NSF-Facing Interface can also use the RESTCONF protocol and the YANG data model in its implementation.
  • I2NSF is currently working on defining a standard data model and protocol for the NSF-Facing Interface.
  • a firewall application may be selected as the NSF instance to determine whether a VoIP-VoLTE call is suspicious by checking the caller / recipient's location and phone time. If the phone has a suspicious behavior pattern, the network traffic of that phone can be effectively blocked by firewall applications in accordance with low-level security policies.
  • the results of the firewall application can be passed from the YANG data model to the security management system through the RESANGON protocol.
  • DPI may be further used to analyze network traffic of suspicious senders.
  • This section looks at additional considerations for implementing the present invention and for improving system performance.
  • the update time may be different from that of the security controller, and inconsistencies in the higher level security policy may occur during this update process.
  • This user level security policy mismatch is similar to the configuration mismatch during the update process commonly seen in SDN transitions.
  • a secure and authenticated communication channel must be established between network entities (e.g., I2NSF user and security management system). If you do not guarantee this communication channel, an inappropriate security policy can be maliciously modified by an attacker. Thus, efficient key management is needed to properly distribute keys to network entities.
  • network entities e.g., I2NSF user and security management system.
  • an architecture that allows a user to configure and manage a user level security policy for controlling an NSF instance without detailed implementation related to the NSF is presented.
  • a general architecture for NSF-based security management using NFV has been presented.
  • various examples have been introduced to describe the detailed implementation of the proposed architecture.
  • the second embodiment proposes a security management architecture in the Interface to Network Security Functions (IISNS) framework.
  • This security management architecture may include I2NSF users, security management systems (ie, security controllers and developer management systems), and Network Security Functions (NSFs) of the I2NSF framework.
  • I2NSF users can include application logic, policy updaters, and policy collectors.
  • the security controller may include a security policy manager and an NSF capability manager. Description of each configuration may be equally applicable to the above description with respect to FIG. 1, and overlapping descriptions will be omitted.
  • the second embodiment proposes a function of the above-described configurations and security management processing at the user level.
  • the second embodiment also describes representative use cases such as malware domain list security management and VoIP-VoLTE security management.
  • I2NSF users can provide these policies to the security controller through the Consumer-Facing Interface.
  • an architecture for security management can be proposed for a given user level policy of the I2NSF framework.
  • This architecture may include I2NSF users, security management systems (ie, security controllers and developer management systems), and the NSF of the I2NSF framework.
  • I2NSF users can include application logic, policy updaters, and policy collectors.
  • the security controller may include a security policy manager and an NSF capability manager.
  • the security policy manager and NSF capability manager of the security controller can control the updated security policy provided by the policy updater of the I2NSF user through the consumer-facing interface.
  • Policy renewers can provide new or updated policies to security controllers.
  • the policy collector may correspondingly receive the user level policy through the security controller. The policy collector can then update the current policy of the application logic accordingly.
  • the second embodiment proposes a security management architecture that integrates additional components for security management into the I2NSF framework.
  • This architecture is designed to support flexible and effective security policies.
  • Application Logic creates a user level policy, and the policy updater can send it to the security policy manager through the consumer-facing interface.
  • the security policy administrator can map user level policies to the various lower level policies of the security controller. After mapping to sub-policies, the security policy manager sends these policies to the NSF so that they can be applied to the NSF.
  • the second embodiment has two main goals for the security management architecture as follows.
  • This section describes the security management architecture of I2NSF and focuses on a security management system with a security controller and a developer management system. It also describes the basic operation of the security controller and details about each component of the architecture.
  • FIG. 4 is a diagram illustrating a security management architecture of I2NSF.
  • the security management architecture of Figure 4 is designed to support the enforcement of a flexible and effective security policy.
  • the application logic of the I2NSF user creates a user level policy in response to a new security attack, and the policy updater of the I2NSF user sends this policy to the security policy manager of the security controller.
  • the security policy manager may map user level policies to several lower level policies related to NSF capabilities registered with the NSF capability manager. After the mapping to these low level policies is completed, the security policy manager can forward these policies to the NSF via the NSF Facing Interface.
  • each structure is mentioned later.
  • the Security Policy Manager receives user-level policies from policy renewers through the Consumer-Facing Interface, and maps user-level policies to various lower-level policies related to specific NSF capabilities registered with the NSF Capability Manager or to lower-level policies. This component maps the policies of user to user level policy. In addition, the security policy manager may forward these policies to the NSF (s) via the NSF Facing Interface.
  • the NSF can send the changed low-level policy to the security policy manager through the NSF Facing Interface. Thereafter, the security policy manager may map the changed lower level policy to the user level policy through the Consumer-Facing Interface, and transmit the changed lower level policy or the user level policy to a policy collector.
  • the NSF Capability Manager may be a configuration integrated into the security controller. Through the registration interface, NSF capability managers can store the capabilities of NSFs registered in the developer management system and share them with the security policy manager so that the security policy manager can create low-level policies related to specific NSF capabilities. In addition, the NSF capability manager may request the developer's management system to register the NSF's capabilities in the management table of the NSF capability manager through the registration interface whenever a new NSF is registered. If the existing NSF is deleted, the NSF Capability Manager can remove the NSF's capabilities from the management table.
  • the developer management system may be a component that registers a new NSF capability with the NSF capability manager through a registration interface. If there is an update in the registered NSF, the updated content / information may be communicated to the NSF capability manager in the developer management system.
  • Application logic may be a configuration that creates a user level security policy to block or mitigate security attacks (in a security management architecture).
  • the application logic can send the created policies to the policy updater. The detailed operation of the application logic will be described later along with the following use examples.
  • the policy updater may be configured to receive a user level security policy generated by the application logic and distribute / deliver it to the security policy manager through the consumer-facing interface.
  • the policy collector can receive updated user-level security policies from the security controller through the Consumer Facing Interface and forward them to the application logic. Since the lower level security policy may be updated according to events occurring in the NSF, such an update is necessary. After receiving the event, the policy collector can forward it to the application logic so that the application logic can update (or create) that user level security policy received from the security controller.
  • This architecture is designed to counter possible security attacks.
  • This section illustrates the procedure for defending the security attack of the I2NSF framework [i2nsf-framework] against a list of security attacks in malware domains and VoIP / VoLTE security attacks.
  • FIG. 5 is a diagram illustrating a security management architecture of Malware domain blacklisting.
  • Malware domain blacklisting refers to maintaining and publishing IP addresses of possible attack hosts, servers, and networks suspected of malicious activity.
  • the Malware domain list can be updated manually or automatically by the Malware domain administrator of the I2NSF user.
  • Malware domain administrators can create new user-level security policies periodically to prevent packet forwarding with newly added Malware domains and enforce NSF's low-level security policies.
  • Malware domain administrators can also send new user-level security policies to the Policy Updater, which can then forward them to the security controller.
  • the updated lower level policy may be sent by the NSF to the security controller via the NSF Facing Interface, allowing the security controller to create a user level security policy that corresponds with the lower level policy.
  • the security controller can provide a user level security policy to the policy collector. Policy collectors can pass policies to Malware domain managers as application logic.
  • VoIP-VoLTE security management can maintain and publish blacklists of IP addresses, source ports, expiration times, user agents, and Session Initiation Protocol (SIP) URIs of SIP devices that are suspected of illegal calls and authentication.
  • SIP Session Initiation Protocol
  • the VoIP-VoLTE security manager may correspond to the application logic for the VoIP-VoLTE security service of FIG.
  • VoIP-VoLTE security managers performing application logic functions can update the illegal device information list manually or automatically.
  • VoIP-VoLTE security managers can periodically create new user-level security policies to prevent packet forwarding with newly added VoIP-VoLTE attackers and to enforce NSF's low-level security policies.
  • the VoIP-VoLTE security manager can send new user-level security policies to the policy updater, who can forward them to the security controller.
  • NSF sends updated low-level policies for VoIP-VoLTE attacks to the security controller through the NSF Facing Interface, so that the security controller can implement user-level security policies that correspond to those low-level policies such as IP addresses, user agents, and their agents. It can create and expire a time value that needs to be added by the security controller.
  • the security controller can provide a user level security policy to the policy collector. Policy collectors can forward policies to VoIP-VoLTE security managers as application logic.
  • the security management architecture is derived from the I2NSF framework [i2nsf-framework], there may be security considerations of the I2NSF framework.
  • an appropriate secure communication channel should be used to convey control or management messages between the components of the proposed architecture.
  • This embodiment describes the security management architecture of the Interface to Network Security Functions (IISNS) framework.
  • This security management architecture may include I2NSF users, security management systems (ie, security controllers and developer management systems), and Network Security Functions (NSFs) of the I2NSF framework.
  • I2NSF users can include application logic, policy updaters, and event collectors.
  • the security controller may include a security policy manager and an NSF capability manager.
  • typical use cases such as Malware domain list security management, VoIP-VoLTE security management, and hourly access control.
  • the above descriptions with respect to the first and second embodiments may be applied in the same manner, and redundant descriptions are omitted.
  • I2NSF users can provide these user-level security policies to security controllers through a consumer-facing interface.
  • This architecture may include I2NSF users, security management systems (ie, security controllers and developer management systems), and the NSF of the I2NSF framework.
  • I2NSF users can include application logic, policy updaters, and event collectors.
  • the security controller includes a security policy manager and an NSF capability manager.
  • the security controller's security policy manager and NSF capability manager can control the updated security policy provided by the policy updater of the I2NSF user through the Consumer-Facing Interface. If a new policy has been created or an existing policy needs to be updated, the policy renewer can provide the security controller with the new policy and / or updates to the existing policy. On the other hand, when an event occurs that requires the NSF to change the low-level policy, the NSF can send the event to the security controller. The security controller forwards the event to the event collector, which can then forward it to the application logic. The application logic can then update the current policy according to the received event.
  • the third embodiment proposes a security management architecture that integrates additional components for security management into the I2NSF framework.
  • This architecture is designed to support flexible and effective security policies.
  • the application logic creates a user level policy, which the policy updater can then send to the security policy manager via the Consumer-Facing Interface.
  • the security policy administrator can map user level policies to the various lower level policies of the security controller. After mapping, lower-level policies can be distributed to the NSF and applied to the NSF.
  • the two main objectives of the security management architecture according to the third embodiment are as follows.
  • This section describes the security management architecture of I2NSF and focuses on the security management system, which includes security controllers and developer management systems. In addition, this section describes the basic operation of the security controller and details each component included in the architecture.
  • FIG. 6 illustrates a security management architecture within the I2NSF framework.
  • the architecture of FIG. 6 is designed to support the enforcement of a flexible and effective security policy.
  • the application logic of the I2NSF user creates a user level policy according to the new security attack, and the policy updater of the I2NSF user sends the user level policy to the security policy manager of the security controller.
  • the security policy manager may map user level policies to several lower level policies related to NSF capabilities registered with the NSF capability manager. After mapping, the security policy manager can distribute the lower level policies to the NSF (s) via the NSF Facing Interface.
  • the Security Policy Manager is configured to receive user level policies from policy updaters through the Consumer-Facing Interface and to map user level policies to several lower level policies related to specific NSF capabilities of the NSF Capability Manager. In addition, the security policy manager may forward these low-level policies to the NSF (s) via the NSF Facing Interface.
  • the NSF may send the event to the security policy manager through the NSF Facing Interface. Thereafter, the security policy manager sends the event to the event collector through the consumer-facing interface.
  • NSF Capability Manager is a configuration integrated into the security controller.
  • NSF capability managers can store NSF capabilities registered in the developer management system through a registration interface and share them with the security policy manager to enable the security policy manager to create low-level policies related to the NSF capability.
  • the NSF capability manager may request the developer management system to register the NSF capability in the management table of the NSF capability manager through the registration interface.
  • the NSF capability manager removes the NSF capability from the management table.
  • the developer management system is configured to register new NSF capabilities with the NSF capability manager through a registration interface. In addition, if there is an update in a registered NSF, the update is passed from the developer management system to the NSF capability manager.
  • Application logic is a configuration that creates a user level security policy to block or mitigate security attacks, and sends the generated policy to a policy updater. This application logic is described in detail in the following use cases.
  • the policy updater is a configuration that receives the user level security policy generated by the application logic and passes it to the security policy manager through the Consumer Facing Interface.
  • the event collector receives events from the security controller that should be reflected when updating (or creating) user-level policies in the application logic. Since the lower level security policy is updated according to specific events occurring in the NSF, a procedure for receiving events in the NSF is required. After receiving the event, the event collector passes it to the application logic so that the application logic can update (or create) a user level security policy based on the event received from the security controller.
  • This architecture is designed to respond to security attacks that may occur in a real environment.
  • This section describes the security procedures of the I2NSF framework [i2nsf-framework] against security attack lists, VoIP / VoLTE security attacks, and hourly access control in the Malware domain.
  • Malware domain blacklisting maintains and publishes IP addresses of possible attack hosts, servers, and networks suspected of malicious activity.
  • FIG. 7 illustrates a security management architecture for Malware domain blacklisting.
  • the list of Malware domains can be updated manually or automatically by the Malware domain administrator of the I2NSF user.
  • Malware domain administrators can create new user-level security policies periodically to prevent packet forwarding with newly added Malware domains and to enforce NSF's low-level security policies.
  • Malware domain administrators can also send new user-level security policies to policy updaters, who can then forward them to the security controller.
  • NSF When NSF detects a new risk domain, it can send its IP address to the security controller through the NSF Facing Interface.
  • the security controller passes the IP address to the event collector, which can then pass that IP address to the risk domain administrator. Based on this, the risk domain administrator can update the risk domain database.
  • VoIP-VoLTE security management maintains and publishes a blacklist of IP addresses, source ports, expiration times, user agents, and Session Initiation Protocol (SIP) URIs of SIP devices that are suspected of illegal calls and authentication.
  • SIP Session Initiation Protocol
  • the VoIP-VoLTE security manager plays the role of application logic for the VoIP-VoLTE security service in FIG.
  • VoIP-VoLTE security manager performing application logic functions can update the list of illegal device information manually or automatically.
  • VoIP-VoLTE security managers can periodically create new user-level security policies to prevent packet forwarding with newly added VoIP-VoLTE attackers and to enforce NSF's low-level security policies.
  • the VoIP-VoLTE security manager can send new user-level security policies to the policy updater, who can forward them to the security controller.
  • domain information such as IP address, user agent and expiration time value is sent by the NSF to the security controller via the NSF Facing interface.
  • the security controller forwards the detected domain information to the event collector, the event collector forwards the detected domain information to the VoIP-VoLTE security manager, and the VoIP-VoLTE security manager based on the detected domain information to create a VoIP-VoLTE database. Update.
  • Hourly access control policies govern a user's access to certain Web sites for a specific period of time. For example, in a company, managers can block employees from accessing Youtube, which can interfere with their workday.
  • the I2NSF user registers a list of blocked websites and blocking times in the application logic based on the hourly access control.
  • the application logic stores the list in a database and creates a user level security policy (for example, checking blocked websites and blocking times in the list to block access to the website).
  • the application logic passes it to the policy updater, which in turn passes it to the security controller.
  • the security policy manager maps user-level policies to lower-level policies and then sends them to the NSF for the NSF to apply the lower-level policies.
  • the security management architecture is derived from the I2NSF framework [i2nsf-framework], there may be security considerations of the I2NSF framework.
  • an appropriate secure communication channel should be used to convey control or management messages between the components of the proposed architecture.
  • FIG. 8 is a flowchart illustrating a security management method of the security management system according to an embodiment of the present invention.
  • the above-described embodiments may be applied in the same or similar manner, and overlapping descriptions may be omitted.
  • the security management system may receive a user level policy for blocking or mitigating a security attack from the I2NSF user (S810).
  • the security management system may map the user level policy to lower level security policies related to the NSF capability registered in the security management system (S820).
  • the security management system may deliver the lower level security policies to at least one NSF (S830).
  • I2NSF users may include application logic, policy updaters, and / or event collectors.
  • the application logic creates and updates user level policies and sends them to the policy updater
  • the policy updaters deliver user level policies to the security management system through a user-oriented interface
  • event collectors are based on the creation or updating of user level policies. Event can be received and sent to the application logic.
  • the user level policy may be generated based on a blacklist including IP addresses of specific attacking hosts, servers, and networks as an example.
  • the event may correspond to an IP address satisfying the inclusion criteria of the blacklist.
  • the user level policy may be generated based on a blacklist including a blocking website and a blocking time as another embodiment.
  • the user level policy may be generated based on an illegal device block list that includes the IP address, source port, expiration time, user agent and / or SIP URI of a particular SIP device.
  • the event may correspond to domain information satisfying the inclusion criteria in the illegal device blocking list.
  • the security management system may include a security policy manager, an NSF capability manager, and / or a developer management system.
  • the developer management system registers and updates NSF capabilities through the registration interface, and the NSF capability manager can store the registered and updated NSF capabilities in the developer management system.
  • the security policy manager may map user level policies to lower level security policies associated with the NSF capabilities stored in the NSF capability manager and deliver the lower level security policies to the at least one NSF via an NSF-facing interface. .
  • 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.
  • the present invention can be applied to various security management systems.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

본 발명은 네트워크 가상화 기반의 네트워크 보안 기능(Network Security Function, NSF) 제공에 관한 I2NSF (Interface to Network Security Functions) 프레임워크에서 I2NSF 사용자가 효과적으로 NSF의 보안 관리를 실현하기 위한 구조를 제시한다. 제안하는 구조를 통해 I2NSF 사용자가 직접 사용자 기반 상위 수준(high-level)의 보안 정책을 수립하고, Security Controller는 이러한 사용자 기반 상위 수준 보안 정책을 NSF가 이해할 수 있는 NSF 기반 하위 수준(low-level) 보안 정책으로 번역한다. 보안 컨트롤러(Security Controller)를 이러한 하위 수준 보안 정책을 NETCONF를 통해 NSF에게 전달하여 해당 보안 서비스를 수행할 수 있게 설정한다. I2NSF 사용자는 NSF에서 발생하는 이벤트를 피드백 받음으로써 결과적으로 효과적인 보안 관리를 실현할 수 있다. 본 발명에서는 I2NSF 프레임워크에서 I2NSF 사용자의 보안 관리를 위해 추가되는 구성 요소들이 어떤 기능들을 수행하는지를 기술한다.

Description

네트워크 가상화 환경에서 보안 관리를 위한 구조
본 발명은 네트워크 기능 가상화의 보안 관리 아키텍처에 관한 것이다.
네트워크 기능 가상화(Network Functions Virtualization; NFV)는 네트워크 산업을 위한 새로운 영역이다. NFV는 네트워크 기능을 전용 하드웨어 기기에서 분리하여 범용 제품 서버에서 실행되는 순수 소프트웨어 인스턴스로 이러한 기능을 구현함으로써 네트워크 배포 및 유지 관리 비용 절감을 보장한다. 방화벽, 침입 탐지 시스템(Intrusion Detection System; IDS) 및 침입 방지 시스템 (Intrusion Protection System; IPS)과 같은 NSF(Network Security Functions)는, 실시간 보안 요구 사항에 따라 자동으로 제공되고 동적으로 이동될 수 있는 가상 네트워크 기능으로서 제공될 수도 있다. 본 명세서에서는 일반 NFV가 아닌 NSF에 초점을 맞춰 기술한다.
NFV 기반 보안 애플리케이션을 성공적으로 배포하기 위해서는, NSF가 여러 공급 업체에서 개발하거나 다른 네트워크 운영 업체에서 관리하기 때문에 표준화가 중요하다. 최근에는 NSF를 제어하기 위한 몇 가지 기본 표준 인터페이스가 IETF(Internet Engineering Task Force)라는 국제 인터넷 표준화 기구의 일부인 I2NSF (Interface to Network Security Functions) 워킹 그룹에 의해 개발 중이다. 따라서, 몇 년 내로, 다양한 NSF가 표준 인터페이스를 통해 NFV 기반 보안 서비스의 중앙 관리 엔티티인 보안 컨트롤러라는 네트워크 엔티티에 의해 원격으로 제어될 수 있다.
그러나, 보안 컨트롤러는 네트워크 상의 보안 정책을 생성하고 관리할 수 있는 임의의 I2NSF 사용자와 통신해야 하기 때문에 NF 기반 보안 애플리케이션에서 표준 개발을 위한 여지가 여전히 남아있다. 본 명세서에서는 보안 컨트롤러로 관리되는 모든 NFV 기반 보안 애플리케이션을 NFV 지원 네트워크에 심리스하게/원활하게 통합하는 계층화된 아키텍처를 제안한다. 이 아키텍처를 통해 애플리케이션 사용자는 사용자 친화적인 방법으로 사용자 수준의 보안 정책을 시행할 수 있다.
본 명세서에서는 NFV를 이용한 NSF 기반의 보안 관리를 위한 일반적인 아키텍처 제시를 목적으로 한다.
또한, 본 명세서는 제안된 프레임워크가 위험 도메인의 블랙리스트, 시간별 액세스 제어 정책 및 VoIP(Voice over IP)-VoLTE(Voice over LTE) 서비스에 대한 의심스러운 전화 탐지와 같은 몇 가지 실제 공격 시나리오를 완화할 수 있는 방법 제안을 목적으로 한다.
이를 위해, 본 명세서에서는 구체적으로 제안된 아키텍처의 상세한 구현을 설명하기 위한 예제를 중심으로 설명한다. 이에 기초하여, 향후 다양한 네트워크 공격을 완화할 수 있는 가능성을 보여주기 위해 제안된 프레임워크가 완벽하게 구현될 수 있다.
본 발명의 일 실시 예에 따르면, 네트워크 기능 가상화에서의 보안 관리를 위한 아키텍처는 I2NSF 프레임워크, 애플리케이션 로직, 정책 갱신자 및 이벤트 수집기를 포함할 수 있다.
본 발명의 일 실시 예에 따른 아키텍처를 통해, 애플리케이션 사용자는 사용자 친화적인 방법으로 사용자 관점에서의 보안 정책을 시행할 수 있다. 보다 상세하게는, 본 발명의 일 실시 예에 따른 아키텍처를 통해, 네트워크 리소스 및 프로토콜에 대한 특정 정보가 필요 없는 사용자 수준의 보안 인터페이스를 사용자에게 제공함으로써, 사용자로 하여금 보다 친숙한 방식으로 보안 요구 사항을 정의하도록 할 수 있다.
또한, 본 발명의 일 실시예에 따른 아키텍처를 통해, I2NSF 사용자가 직접 사용자 관점에서 일반화 된 보안 정책을 수립하고 NSF에서 발생하는 이벤트를 피드백 받음으로써 효율적인 보안 관리를 실현할 수 있다.
도 1은 NFV에 기반한 보안 관리를 위한 아키텍처를 예시한 도면이다.
도 2는 I2NSF 사용자의 사용자 인터페이스를 예시한 도면이다.
도 3은 Consumer-Facing Interface의 데이터 모델을 예시한 도면이다.
도 4는 I2NSF의 보안 관리 아키텍처를 예시한 도면이다.
도 5는 Malware 도메인 블랙리스트 작성의 보안 관리 아키텍처를 예시한 도면이다.
도 6은 I2NSF 프레임워크 내의 보안 관리 아키텍처를 예시한 도면이다.
도 7은 Malware 도메인 블랙리스트 작성의 보안 관리 아키텍처를 예시한 도면이다.
도 8은 본 발명의 일 실시예에 따른 보안 관리 시스템의 보안 관리 방법에 관한 순서도이다.
본 명세서에서 사용되는 용어는 본 명세서에서의 기능을 고려하면서 가능한 현재 널리 사용되는 일반적인 용어를 선택하였으나, 이는 당 분야에 종사하는 기술자의 의도, 관례 또는 새로운 기술의 출현 등에 따라 달라질 수 있다. 또한 특정 경우는 출원인이 임의로 선정한 용어도 있으며, 이 경우 해당되는 실시예의 설명 부분에서 그 의미를 기재할 것이다. 따라서 본 명세서에서 사용되는 용어는, 단순한 용어의 명칭이 아닌 그 용어가 아닌 실질적인 의미와 본 명세서의 전반에 걸친 내용을 토대로 해석되어야 함을 밝혀두고자 한다.
더욱이, 이하 첨부 도면들 및 첨부 도면들에 기재된 내용들을 참조하여 실시 예를 상세하게 설명하지만, 실시예들에 의해 제한되거나 한정되는 것은 아니다.
이하, 첨부한 도면들을 참조하여 본 발명의 바람직한 실시예를 보다 상세하게 설명하고자 한다.
[1] 제1 실시 예
네트워크 기능 가상화 (NFV)는 네트워크 보안 서비스를 설계하고 배포하는 새로운 방법을 제공하지만, 네트워크 보안 서비스들 사이의 규격/표준화된 네트워크 인터페이스 서비스가 없는 경우, 네트워크 보안 서비스들을 완벽하게 통합하는 실용적인 에코 시스템을 구축하지 못할 수도 있다. 따라서, 본 명세서에서는 NFV를 사용하는 NSF(Network Security Functions) 기반의 보안 관리 서비스를 위한 아키텍처를 제안한다. 제안된 아키텍처는 네트워크 리소스 및 프로토콜에 대한 특정 정보가 필요 없는 사용자 수준의 일반화 된 보안 인터페이스를 사용자에게 제공함으로써, 사용자에게 친숙한 방식으로 사용자로 하여금 보안 요구 사항을 정의하도록 할 수 있다.
1. 도입
제1 실시 예에서는 제안된 아키텍처를 위한 기본 구성 요소(예를 들어, 보안 정책 관리자, NSF 능력 관리자, 애플리케이션 논리, 정책 갱신자 및 이벤트 수집기)와 인터페이스 설계 방식을 제안한다. 또한, 제1 실시예에서는 (1) 위험 도메인의 블랙리스트, (2) 시간별 액세스 제어 정책 및 (3) VoIP-VoLTE 서비스에 대한 의심스러운 전화 탐지, 이렇게 세 가지 케이스에 대한 본 발명의 사용예를 중심으로 살펴본다. 또한, 본 명세서에서는 제안된 아키텍처의 구현 방법에 대해 예를 들어 상세히 설명한다. 또한, 본 명세서에서는 제안된 아키텍처를 실제 네트워크 환경에 배치/적용하기 위한 몇 가지 기술적 과제에 대해 살펴본다.
이하, 설명의 편의를 위해 주제별로 절을 나누어 설명한다. 2절에서는 NFV 기반의 보안 관리 서비스 아키텍처에 대해 제안한다. 3절에서는 제안된 아키텍처를 사용하는 세 가지 주요 사용예에 대해 설명한다. 4절에서는 실제로 제안된 아키텍처를 사례를 통해 구현하는 방법에 대해 설명한다. 5절에서는 아키텍처 구현에 대한 기술적 문제에 대해 설명한다. 6절에서는 관련 연구에 대한 요약 및 분석 내용을 설명한다. 7절에서는 결론에 대해 살펴본다.
2. 아키텍처
본 명세서에서는 NFV에 기반한 보안 관리 서비스를 위한 추가 구성 요소를 통합한 계층화된 아키텍처를 제안한다. 본 명세서의 도면들에서 화살표는 기능 구성 요소들 간의 통신을 나타낸다. 특히, 도면에서 양방향 화살표는 양방향으로의 두 구성 요소간 상호 작용을 나타내며, 단방향 화살표는 화살표가 가리키는 방향으로의 두 구성 요소 간 상호 작용을 나타낸다.
도 1은 NFV에 기반한 보안 관리를 위한 아키텍처를 예시한 도면이다.
도 1을 참조하면, 유연하고 효과적인 보안 정책 시행을 지원하기 위해 제안된 아키텍처는, (1) I2NSF 사용자(100) (2) 보안 관리 시스템(110) 및 (3) NSF 인스턴스들(120), 이렇게 세 가지 계층으로 구성될 수 있다.
본 발명의 아키텍처는 유연하고 효과적인 보안 정책 시행을 지원하도록 설계되었다. 본 명세서에서 I2NSF 사용자(100)라는 용어는 NFV 기반의 보안 애플리케이션을 의미한다.
I2NSF 사용자(100)에서 애플리케이션 로직(100-1)은 사용자 수준의 보안 정책을 생성할 수 있다. 정책 갱신자(100-2)는 컨수머 지향 인터페이스(Consumer-Facing interface)를 통해 보안 컨트롤러(110-1)에 정책들을 배포할 수 있다. 보안 컨트롤러(110-1)에서 보안 정책 관리자(110-2)는 사용자 수준의 정책을 NSF 능력 관리자(110-3)에 등록된 NSF 능력과 관련된 하위 수준 보안 정책에 매핑할 수 있다. 매핑 후, 보안 정책 관리자(110-2)는 NSF 지향 인터페이스(NSF Facing Interface)를 통해 NSF(120)에 해당 정책들을 전달할 수 있다. 이하에서는, 각 네트워크 구성 요소의 동작에 대해 상세히 살펴본다.
2.1 보안 정책 관리자(110-2)
보안 정책 관리자(110-2)는 Consumer-Facing Interface를 통해 정책 갱신자(100-2)로부터 사용자 수준의 정책을 수신하고, 사용자 수준의 정책을 NSF 능력 관리자(110-3)에 등록된 특정 NSF 능력과 관련된 여러 하위 수준의 정책들과 매핑하거나 또는 하위 수준의 정책들을 사용자 수준의 정책으로 매핑하는 구성 요소이다. 또한, 보안 정책 관리자(110-2)는 이러한 정책들을 NSF-Facing Interface를 통해 NSF(들)에게 전달할 수 있다.
하위 수준 정책 변경이 필요한 이벤트가 NSF(120)에서 발생하면, NSF(120)는 NSF Facing Interface를 통해 보안 정책 관리자(110-2)에게 이벤트를 전송할 수 있다. 이후, 보안 정책 관리자(110-2)는 Consumer-Facing Interface를 통해 해당 이벤트를 이벤트 수집기(100-3)로 전송할 수 있다.
2.2 NSF 능력 관리자(110-3)
NSF 능력 관리자(110-3)는 보안 컨트롤러(110-1)에 통합된 구성일 수 있다. NSF 능력 관리자(110-3)는 등록 인터페이스를 통해 개발자 관리 시스템(110-4)에 등록된 NSF의 능력을 저장하고 이를 보안 정책 관리자(110-2)와 공유하여 보안 정책 관리자(110-2)가 특정 NSF 능력과 관련된 하위 수준 정책을 생성할 수 있도록 할 수 있다. 또한, NSF 능력 관리자(110-3)는 새로운 NSF가 등록될 때마다 등록 인터페이스를 통해 NSF 능력 관리자(110-3)의 관리 테이블에 NSF의 능력을 등록하도록 개발자의 관리 시스템에 요청할 수 있다. 기존의 NSF가 삭제되면 NSF 능력 관리자(110-3)는 관리 테이블에서 NSF의 능력을 제거할 수 있다.
2.3 개발자 관리 시스템(110-4)
개발자 관리 시스템(110-4)은 등록 인터페이스를 통해 NSF 능력 관리자(110-3)에 새로운 NSF 능력을 등록하는 구성 요소일 수 있다. 등록된 NSF에 업데이트가 있으면, 업데이트된 내용/정보는 개발자 관리 시스템에서 NSF 능력 관리자(110-3)에게 전달될 수 있다.
2.4 애플리케이션 로직(100-1)
애플리케이션 로직(100-1)은 (보안 관리 아키텍처에서) 보안 공격을 차단 또는 완화하기 위해 사용자 수준의 보안 정책을 생성하는 구성일 수 있다. 애플리케이션 로직(100-1)은 이벤트 수집기(100-3)로부터 사용자 수준의 정책을 갱신(또는 생성)하는 이벤트를 수신하고, 수집된 이벤트를 기반으로 사용자 수준의 정책을 업데이트(또는 생성)할 수 있다. 다음으로, 애플리케이션 로직(100-1)은 최근 업데이트된 정책을 전달하기 위해 사용자 수준의 정책을 정책 갱신자(100-2)로 전송할 수 있다. 이하의 3절에서는 세 가지 사용예를 통해 애플리케이션 로직(100-1)을 설계하는 방법에 대해 설명한다.
2.5 정책 갱신자(100-2)
정책 갱신자(100-2)는 애플리케이션 로직(100-1)에 의해 생성된 사용자 수준의 보안 정책을 수신하고, 이를 Consumer-Facing Interface를 통해 보안 컨트롤러(110-1)로 배포/전달하는 구성일 수 있다.
2.6 이벤트 수집기(100-3)
이벤트 수집기(100-3)는 애플리케이션 로직(100-1)의 사용자 수준의 정책 업데이트(또는 생성)에 반영되어야 하는 이벤트를 보안 컨트롤러(110-1)로부터 수신할 수 있다. NSF에서 발생하는 이벤트에 따라 하위 수준의 보안 정책이 업데이트될 수 있으므로, NSF에서 이벤트를 수신하는 절차가 필요하다. 이벤트를 수신한 후 이벤트 수집기(100-3)는, 이를 애플리케이션 로직(100-1)으로 전달하여 애플리케이션 로직(100-1)이 보안 컨트롤러(110-1)로부터 수신한 이벤트를 기반으로 사용자 수준의 보안 정책을 업데이트(또는 생성)하도록 할 수 있다.
3. 사용예
NFV를 기반으로 한 일반적인 아키텍처는 가능한 보안 공격에 대응하도록 설계되었다. 본 절에서는 위험한 도메인의 블랙리스트에 있는 보안 공격 방어, 시간에 따른 액세스 제어 정책 및 VoIP-VoLTE 서비스에 대한 의심스러운 전화의 탐지 절차에 대해 설명한다.
3.1 위험한 도메인들의 블랙리스트
위험한 도메인(예를 들어, malware 배포에 사용되는 도메인 등) 블랙리스트 작성은 악성 활동이 의심되는 공격 호스트, 서버 및 네트워크의 IP 주소에 대한 블랙리스트를 유지 및 게시하는 것을 의미한다. 위험한 도메인 블랙리스트 작성을 위한 보안 관리 아키텍처의 경우, 위험 도메인 관리자는 보안 관리를 수행하기 위해 애플리케이션 로직의 역할을 담당할 수 있다.
위험한 도메인 블랙리스트 작성에 기초하여, 위험한 도메인 리스트는 위험한 도메인 데이터베이스에 저장되며, 애플리케이션 로직 기능을 하는 위험한 도메인 관리자에 의해 수동 또는 자동으로 업데이트될 수 있다. 또한, 위험한 도메인 관리자는 위험한 도메인 데이터 베이스로부터 위험한 도메인 리스트를 주기적으로 로드하고, 새로 추가된 위험한 도메인들과의 패킷 전달을 방지하기 위해 새로운 사용자 수준의 보안 정책(예를 들어, IP 주소를 사용하여 위험한 도메인들의 리스트 차단, 블랙리스트 차단)을 생성할 수 있다. 위험한 도메인 관리자는 새로운 사용자 수준 보안 정책을 정책 갱신자로 전송할 수 있으며, 정책 업데이트는 수신한 새로운 사용자 수준 보안 정책을 보안 컨트롤러에 배포할 수 있다. 보안 컨트롤러는 사용자 수준 정책을 하위 수준 정책들에 매핑하고, 하위 수준 보안 정책들을 NSF에 적용할 수 있다.
NSF가 새로운 위험한 도메인을 탐지하면, 탐지한 도메인에 대응하는 IP 주소를 NSF-Facing Interface를 통해 보안 컨트롤러로 전송할 수 있다. 보안 컨트롤러는 이벤트 수집기에 해당 IP 주소를 전달할 수 있다. 이벤트 수집기는 IP 주소를 위험 도메인 관리자로 전달하면, 이를 기초로 위험 도메인 관리자가 위험 도메인 데이터베이스를 업데이트할 수 있다.
3.2 시간별 액세스 제어 정책들
시간별 액세스 제어 정책들은 특정 기간 동안 특정 웹 사이트에 대한 사용자의 액세스를 관리할 수 있다. 예를 들어, 회사에서 관리자는 직원이 업무 시간의 집중을 방해하는 Youtube 웹 사이트에 액세스하는 것을 차단할 수 있다.
I2NSF 사용자는 시간별 접근 제어를 기반으로 애플리케이션 로직에서 차단 웹 사이트 및 차단 시간이 포함된 블랙리스트를 등록할 수 있다. 애플리케이션 로직은 해당 목록을 데이터 베이스에 저장하고 사용자 수준의 보안 정책을 생성할 수 있다(예를 들어, 차단 웹 사이트 및 차단 시간을 확인하여 차단 시간 동안의 차단 웹 사이트에 대한 액세스 차단).
애플리케이션 로직은 생성한 사용자 수준의 보안 정책을 정책 갱신자로 전달하면, 정책 갱신자가 이를 보안 컨트롤러로 전달할 수 있다. 보안 컨트롤러에서 보안 정책 관리자는 사용자 수준 정책을 하위 수준 정책들에 매핑한 다음, 이들을 NSF에 전송 및 적용할 수 있다.
3.3 VoIP-VoLTE 서비스에 대한 의심스러운 전화 탐지
VoIP-VoLTE 보안 관리는 불법적인 전화나 인증이 의심되는 SIP(Session Initiation Protocol) 장치의 IP 주소, 소스 포트, 만료 시간, 사용자 에이전트 및 SIP URI가 포함된 불법 장치 차단 목록을 유지 및 게시할 수 있다. 일반 보안 관리 아키텍처에서 VoIP-VoLTE 보안 관리자는 도 1에서의 VoIP-VoLTE 보안 서비스를 위한 애플리케이션 로직 역할을 담당한다.
VoIP-VoLTE 보안 관리에 기초하여, 불법 장치 정보 목록은 VoIP-VoLTE 데이터 베이스에 저장되며, VoIP-VoLTE 보안 관리자에 의해 수동 또는 자동으로 업데이트될 수 있다. 또한, VoIP-VoLTE 보안 관리자는 주기적으로 VoIP-VoLTE 데이터 베이스로부터 불법 장치 정보 목록을 로드하고, 새로 추가된 VoIP-VoLTE 공격자와의 패킷 전달을 방지하기 위해 새로운 사용자 수준의 보안 정책(예를 들어, IP 주소, 소스 포트 등을 사용하는 불법 장치 차단 목록)을 생성할 수 있다. 또한, VoIP-VoLTE 보안 관리자는 생성한 새로운 사용자 수준 보안 정책을 정책 갱신자로 전송할 수 있으며, 정책 갱신자는 수신한 사용자 수준 보안 정책을 보안 컨트롤러로 배포할 수 있다. 보안 컨트롤러는 사용자 수준 정책을 여러 하위 수준 정책들에 매핑하고 하위 수준 보안 정책을 NSF에 적용하게 된다.
NSF가 도메인으로부터 전달된 비정상적인 메시지 또는 전화를 검출하면, IP 주소, 사용자 에이전트 및 만료 시간 값과 같은 도메인의 정보가 NSF에 의해 NSF Facing Interface를 통해 보안 컨트롤러로 전송될 수 있다. 보안 컨트롤러는 이를 이벤트 수집기로 전달할 수 있다. 이벤트 수집기는 탐지된 도메인 정보를 VoIP-VoLTE 보안 관리자에게 전달하면, VoIP-VoLTE 보안 관리자는 이에 기초하여 VoIP-VoLTE 데이터베이스를 업데이트할 수 있다.
4. 구현
본 절에서는 제안된 아키텍처에서 각 구성 요소와 인터페이스를 구현하는 방법에 대해 제안하며, 이때 앞서 상술한 3.3 절의 사용예를 고려한다. 이러한 구현을 통해 착신호에 사기 전화 동작(예를 들어, 비정상적인 시간대에 블랙리스트에 올라있는 위치에서 통화가 이루어지는 동작 등)이 있는지 여부를 확인하여 의심스러운 VoIP-VoLTE 전화의 차단이 가능하다.
4.1 I2NSF 사용자
관리자에게보다 친숙하고 접근 가능한 관리 서비스를 제공하기 위해, 웹 서버 및 관리자가 사용자 수준의 보안 정책을 설정할 수 있는 사용자 인터페이스를 제공하는 몇 개의 웹 페이지가 제공/생성될 수 있다.
도 2는 I2NSF 사용자의 사용자 인터페이스를 예시한 도면이다.
도 2를 참조하면, 관리자가 보안 정책을 관리하기 위해서는, (1) 정책 갱신자에 대한 정책 설정 페이지와 (2) 이벤트 수집기에 대한 로그 메시지 페이지, 이렇게 두 가지 웹 페이지가 고려될 수 있다. YANG은 YANG에서 정의된 데이터로의 HTTP를 통한 접속을 위한 프로그래밍 인터페이스를 제공하는 RESTCONF와 같은 표준 네트워크 프로토콜에 의해 조작된 구성과 상태 데이터를 모델링하는 데 널리 사용되기 때문에, I2NSF 사용자와 보안 관리 시스템 간의 통신을 위한 데이터 모델을 정의하기 위해 YANG이 고려/사용될 수 있다.
정책 설정 페이지에서, 특정 시간 동안 블랙리스트에 포함된 국가와 같은 사용자 수준의 보안 정책을 정의하기 위한 필드가 생성될 수 있다. 만일, 관리자가 새로운 사용자 수준의 보안 정책을 설정하면, I2NSF 사용자의 데이터 모델 파서(parser)가 정책을 해석하고 YANG 데이터 모델에 따라 XML 파일을 생성할 수 있다.
로그 메시지 페이지에는, 보안 관리 시스템에서 이벤트 수집기로 이벤트가 전달되는 경우, 보안 관리 시스템 및 NSF 인스턴스에서 보안 애플리케이션의 결과 및/또는 기능 구성 요소의 상태를 보고하는 이벤트에 대한 정보가 표시될 수 있다.
4.2 Consumer-Facing Interface
I2NSF 사용자와 보안 관리 시스템 간의 상호 작용을 가능하게 하기 위해 RESTCONF를 기반으로 한 통신 채널이 구현될 수 있다. 또한, I2NSF 사용자는 구현 시 웹 애플리케이션을 기반으로 하기 때문에, 네트워크 구성(NETCONF) 프로토콜 대신 RESTCONF가 선호될 수 있다.
또한, Consumer-Facing Interface를 위한 표준화된 데이터 모델이 아직 없기 때문에, 보안 정책 요구 사항에 기반한 데이터 모델이 설계될 필요가 있다.
도 3은 Consumer-Facing Interface의 데이터 모델을 예시한 도면이다.
도 3에서는 VoIP-VoLTE 서비스에서 의심스러운 전화를 탐지하기 위한 정책 관리와 관련된 데이터 모델 설계의 일부를 보여준다.
알려지지 않은 공격 및 조건에 정책을 적용하기 위한 일반적인 데이터 모델이 설계될 수 있다. 이러한 데이터 모델은 (1) 정책 라이프 사이클 관리, (2) 정책 규칙 및 (3) 조치로 구성될 수 있다. (1) 정책 라이프 사이클 관리 필드는 정책 자체의 수명을 결정하기 위해 만료 시간 및/또는 만료 이벤트 세트를 지정할 수 있다. (2) 정책 규칙 필드는 서비스 타입, 조건 및 유효한 시간 간격과 같은 사용자 수준 정책에 대한 특정 정보를 나타낼 수 있다. (3) 조치 필드는 어떤 행동을 취해야 하는지를 지정한다. 예를 들어, 허가(permit) 및 미러(mirror) 모두 ‘true’인 경우, 예외 시간(유효 시간 간격에 포함)에 블랙리스트에 있는 발신자 위치의 통화 트래픽은 차단될 수 있으며, 딥 패킷 검사(Deep Packet Inspection; DPI)를 위해 사전 정의된 호스트로 순차적으로 전달 될 수 있다.
4.3 보안 관리 시스템
보안 관리 시스템의 주된 역할은 사용자 수준의 정책을 하위 수준의 정책 집합으로 변환하는 것이다. 예를 들어, 보안 관리 시스템은 각 국가의 IP 주소를 제공하는 위치 정보 데이터베이스를 사용하여 국가 이름을 일련의 IP 주소들의 세트로 매핑할 수 있다. 사용자 수준의 보안 정책을 변환한 후, 보안 관리 시스템은 네트워크 트래픽을 해당 IP 주소 및/또는 해당 IP 주소로 지정하기 위해 하위 수준 보안 정책들을 생성할 수 있다. 데이터 모델 파서는 하위 수준 보안 정책을 위한 XML 파일을 생성하여, 이를 적절한 NSF 인스턴스에 전달할 수 있다. 또한, 보안 관리 시스템은 NSF에 의해 생성된 보안 이벤트를 YANG 데이터 모델의 사용자 수준 로그 메시지로 해석하여, 이를 I2NSF 사용자에게 반대 방향으로 전달할 수 있다.
4.4 NSF-Facing Interface
Consumer-Facing Interface와 마찬가지로 NSF-Facing Interface 역시, 구현 시 RESTCONF 프로토콜과 YANG 데이터 모델을 사용할 수 있다. I2NSF는 최근 NSF-Facing Interface에 대한 표준 데이터 모델과 프로토콜을 정의하기 위한 작업을 진행 중에 있다.
4.5 NSF 인스턴스들
사용예에서는 발신자/착신자의 위치 및 전화 시간을 확인함으로써 VoIP-VoLTE 전화가 의심스러운지 여부를 결정하기 위해, NSF 인스턴스로서 방화벽 애플리케이션이 선택될 수 있다. 전화에 의심스러운 동작 패턴이 있는 경우, 해당 전화의 네트워크 트래픽은 하위 수준 보안 정책에 따라 방화벽 애플리케이션에 의해 효과적으로 차단될 수 있다. 방화벽 애플리케이션의 결과는 RESANGON 프로토콜을 통해 YANG 데이터 모델에서 보안 관리 시스템으로 전달될 수 있다.
특정 상황에 따라 다수의 NSF 인스턴스들이 고려될 수 있다. 예를 들어, 의심스러운 발신자의 네트워크 트래픽을 분석하는 데 DPI가 추가로 사용될 수 있다.
5. 주요 기술적 과제
본 절에서는 본 발명을 구현하고 시스템 성능을 향상시키기 위해 추가적으로 고려해야 할 사항에 대해 살펴보며, 다음과 같다:
(1) 정책 갱신자가 보안 컨트롤러를 최근의 사용자 수준 정책으로 업데이트함에 따라 업데이트 시간이 보안 컨트롤러와 달라질 수 있으며, 이 업데이트 프로세스 중에 상위 레벨 보안 정책의 불일치가 발생할 수 있다. 이러한 사용자 수준 보안 정책의 불일치는 SDN 전환에서 공통적으로 볼 수 있는 업데이트 프로세스 중 구성 불일치와 유사하다.
(2) 보안 컨트롤러가 수신하는 정책 흐름으로 확장할 수 없기 때문에, 하나의 보안 컨트롤러가 증가하는 다수의 I2NSF 사용자들을 모두 처리 할 수 없게 되어 확장성 문제가 발생할 수 있다.
(3) 네트워크 엔티티들(예를 들어, I2NSF 사용자와 보안 관리 시스템) 사이에 안전하고 인증된 통신 채널이 설정되어야 한다. 이러한 통신 채널을 보장하지 않으면, 부적절한 보안 정책이 공격자에 의해 악의적으로 변경될 수 있다. 따라서, 네트워크 엔티티들에 키를 적절히 분배하기 위해서는 효율적인 키 관리가 필요하다.
(4) 보안 컨트롤러가 사용자 수준 및 하위 수준 정책을 처리할 때, 처리 시퀀스들은 보안 컨트롤러와 NSF들 모두에서 동기화 문제를 일으킬 수 있다. 이 동기화 문제가 발생하지 않도록 보안 컨트롤러에 적절한 스케줄링 모델을 정의해야 한다.
(5) Consumer-Facing Interface를 통해 전달될 높은 수준의 정책들을 생성하기 위해, 먼저 Consumer-Facing Interface에서 일반적인 정책 데이터 모델이 정의되어야 한다. 이를 위해, 형태 및 내용과 무관하게, 정책을 쉽게 관리 할 수 있는 정책 추상화(Simplified Use of Policy Abstractions; SUPA)의 일반적인 데이터 모델이 사용될 수 있다.
6. 관련 연구
네트워크 서비스 가상화를 보안 서비스에 사용하는 것에 대한 관심은 네트워킹 커뮤니티에서 꾸준히 증가하고 있다. 그러나, 앞서 상술한 바와 같이, NSF에 대한 표준 인터페이스 및 스펙이 없다면, NSF를 매끄럽게 통합 및 관리하는 것이 불가능하다. 특히, 사용자 수준의 보안 정책을 위한 표준 인터페이스가 없기 때문에 NSF 기반 애플리케이션을 실제 환경에 배포하기가 어렵다.
이를 해결하기 위해, 본 명세서에서는 제1 실시예로서 사용자가 NSF와 관련된 세부 구현없이 NSF 인스턴스를 제어하기 위한 사용자 수준의 보안 정책을 구성 및 관리 할 수 있는 아키텍처를 제시하였다.
7. 결론
이상으로, 제1 실시예로서 NFV를 이용한 NSF 기반의 보안 관리를 위한 일반적인 아키텍처를 제시하였다. 또한, 앞서 제1 실시예로 제안된 프레임워크가 위험 도메인의 블랙리스트, 시간별 액세스 제어 정책 및 VoIP-VoLTE 서비스에 대한 의심스러운 전화 탐지와 같은 몇 가지 실제 공격 시나리오를 완화시킬 수 있는 방법에 대해 살펴보았다. 또한, 다양한 예제를 도입하여 구체적으로 제안된 아키텍처의 상세한 구현을 설명하였다.
[2] 제2 실시예
제2 실시예는 I2NSF(Interface to Network Security Functions) 프레임워크에서의 보안 관리 아키텍처를 제안한다. 이 보안 관리 아키텍처는 I2NSF 사용자, 보안 관리 시스템(즉, 보안 컨트롤러 및 개발자 관리 시스템) 및 I2NSF 프레임워크의 NSF(Network Security Functions)를 포함할 수 있다. I2NSF 사용자는 애플리케이션 로직, 정책 갱신자 및 정책 수집기를 포함할 수 있다. 보안 컨트롤러는 보안 정책 관리자와 NSF 능력 관리자를 포함할 수 있다. 각 구성에 관한 설명은 앞서 도 1과 관련하여 상술한 설명이 동일하게 적용될 수 있으며, 중복되는 설명은 생략한다.
또한, 제2 실시예는 상술한 구성들의 기능과 사용자 수준에서의 보안 관리 처리에 대해 제안한다. 또한, 제2 실시예는 malware 도메인 리스트 보안 관리 및 VoIP-VoLTE 보안 관리와 같은 대표적인 사용 사례에 대해서도 설명한다.
이외에, 제2 실시예에는 앞서 상술한 제1 실시예의 설명이 동일/유사하게 적용될 수 있으며, 중복되는 설명은 생략한다. 또한, 주제별로 절을 나누어 설명한다.
1. 도입
I2NSF 프레임워크[i2nsf-framework]에 사용자의 사용자 수준 보안 정책을 적용하기 위해, I2NSF 사용자는 Consumer-Facing Interface를 통해 보안 컨트롤러에 이러한 정책을 제공할 수 있다. 제2 실시예에서는 보안 관리를 위한 아키텍처가 I2NSF 프레임워크의 주어진 사용자 수준 정책에 대해 제안될 수 있다. 이 아키텍처는 I2NSF 사용자, 보안 관리 시스템(즉, 보안 컨트롤러 및 개발자 관리 시스템) 및 I2NSF 프레임워크의 NSF를 포함할 수 있다. I2NSF 사용자에는 애플리케이션 로직, 정책 갱신자 및 정책 수집기가 포함될 수 있다. 보안 컨트롤러는 보안 정책 관리자 및 NSF 능력 관리자를 포함할 수 있다.
보안 컨트롤러의 보안 정책 관리자 및 NSF 능력 관리자는 Consumer- Facing Interface를 통해 I2NSF 사용자의 정책 갱신자에서 제공하는 업데이트된 보안 정책을 제어할 수 있다. 정책 갱신자는 보안 컨트롤러에 새롭거나 업데이트된 정책을 제공할 수 있다. 반면, NSF가 하위 수준 정책을 변경하는 이벤트가 발생하면, 정책 수집기는 이에 상응하여 보안 컨트롤러를 통해 사용자 수준 정책을 수신할 수 있다. 그 후, 정책 수집기는 애플리케이션 로직의 현재 정책도 이에 따라 업데이트할 수 있다.
제2 실시예에서는 보안 관리를 위한 추가 구성 요소를 I2NSF 프레임워크에 통합하는 보안 관리 아키텍처를 제안한다. 이러한 아키텍처는 유연하고 효과적인 보안 정책을 지원하도록 설계되었다. Application Logic은 사용자 수준의 정책을 생성하고, 정책 갱신자는 이를 Consumer- Facing Interface를 통해 보안 정책 관리자로 전송할 수 있다. 보안 정책 관리자는 사용자 수준 정책을 보안 컨트롤러의 여러 하위 수준 정책들에 매핑할 수 있다. 하위 정책들에 매핑한 후, 보안 정책 관리자는 이러한 정책들이 NSF에 적용될 수 있도록 NSF로 전송하게 된다.
2. 목적
제2 실시예는 다음과 같이 보안 관리 아키텍처에 대한 두 가지 주요 목표를 갖는다.
(1) 높은 수준의 보안 관리: NSF에서의 유연하고 효과적인 보안 정책의 시행을 지원하기 위해 일반적인 보안 관리 아키텍처의 설계를 제안한다.
(2) 보안 정책들의 자동 업데이트: 새로운 보안 공격에 대한 업데이트된 하위 수준의 보안 정책을 대응하는 사용자 수준 보안 정책에 반영한다.
3. 보안 관리를 위한 아키텍처
본 절에서는 I2NSF의 보안 관리 아키텍처에 대해 설명하고 보안 컨트롤러와 개발자 관리 시스템을 갖춘 보안 관리 시스템에 중점을 두고 설명한다. 또한, 보안 컨트롤러의 기본 동작 및 아키텍처의 각 구성 요소에 대한 세부 정보를 설명한다.
도 4는 I2NSF의 보안 관리 아키텍처를 예시한 도면이다.
도 4의 보안 관리 아키텍처는 유연하고 효과적인 보안 정책의 시행을 지원하도록 설계되었다. I2NSF 사용자의 애플리케이션 로직은 새로운 보안 공격에 따라 사용자 수준의 정책을 생성하면, I2NSF 사용자의 정책 갱신자가 이러한 정책을 보안 컨트롤러의 보안 정책 관리자에게 전송한다. 보안 정책 관리자는 사용자 수준 정책을 NSF 능력 관리자에 등록된 NSF 능력과 관련된 몇 가지 하위 수준의 정책들에 매핑할 수 있다. 이와 같은 낮은 수준의 정책으로의 매핑이 완료된 후, 보안 정책 관리자는 이러한 정책들을 NSF Facing Interface를 통해 NSF에 전달할 수 있다. 이하에서는 각 구성에 대해 후술한다.
2.1. 보안 정책 관리자
보안 정책 관리자는 Consumer-Facing Interface를 통해 정책 갱신자로부터 사용자 수준의 정책을 수신하고, 사용자 수준의 정책을 NSF 능력 관리자에 등록된 특정 NSF 능력과 관련된 여러 하위 수준의 정책들과 매핑하거나 또는 하위 수준의 정책들을 사용자 수준의 정책으로 매핑하는 구성 요소이다. 또한, 보안 정책 관리자는 이러한 정책들을 NSF Facing Interface를 통해 NSF(들)에게 전달할 수 있다.
하위 수준 정책 변경이 필요한 이벤트가 NSF에서 발생하면, NSF는 NSF Facing Interface를 통해 보안 정책 관리자에게 변경된 하위 수준 정책을 전송할 수 있다. 이후, 보안 정책 관리자는 Consumer-Facing Interface를 통해 상기 변경된 하위 수준의 정책을 사용자 수준의 정책에 매핑하고, 상기 변경된 하위 수준의 정책 또는 사용자 수준의 정책을 정책 수집기로 전송할 수 있다.
2.2 NSF 능력 관리자
NSF 능력 관리자는 보안 컨트롤러에 통합된 구성일 수 있다. NSF 능력 관리자는 등록 인터페이스를 통해 개발자 관리 시스템에 등록된 NSF의 능력을 저장하고 이를 보안 정책 관리자와 공유하여 보안 정책 관리자가 특정 NSF 능력과 관련된 하위 수준 정책을 생성할 수 있도록 할 수 있다. 또한, NSF 능력 관리자는 새로운 NSF가 등록될 때마다 등록 인터페이스를 통해 NSF 능력 관리자의 관리 테이블에 NSF의 능력을 등록하도록 개발자의 관리 시스템에 요청할 수 있다. 기존의 NSF가 삭제되면 NSF 능력 관리자는 관리 테이블에서 NSF의 능력을 제거할 수 있다.
2.3 개발자 관리 시스템
개발자 관리 시스템은 등록 인터페이스를 통해 NSF 능력 관리자에 새로운 NSF 능력을 등록하는 구성 요소일 수 있다. 등록된 NSF에 업데이트가 있으면, 업데이트된 내용/정보는 개발자 관리 시스템에서 NSF 능력 관리자에게 전달될 수 있다.
2.4 애플리케이션 로직
애플리케이션 로직은 (보안 관리 아키텍처에서) 보안 공격을 차단 또는 완화하기 위해 사용자 수준의 보안 정책을 생성하는 구성일 수 있다. 애플리케이션 로직은 생성된 정책들을 정책 갱신자로 전송할 수 있다. 애플리케이션 로직의 보다 상세한 동작에 관해서는 이하의 사용예와 함께 후술한다.
2.5 정책 갱신자
정책 갱신자는 애플리케이션 로직에 의해 생성된 사용자 수준의 보안 정책을 수신하고, 이를 Consumer-Facing Interface를 통해 보안 정책 관리자로 배포/전달하는 구성일 수 있다.
2.6 정책 수집기
정책 수집기는 업데이트된 사용자 수준의 보안 정책을 Consumer Facing Interface를 통해 보안 컨트롤러로부터 수신하고, 이를 애플리케이션 로직으로 전달할 수 있다. NSF에서 발생하는 이벤트에 따라 하위 수준의 보안 정책이 업데이트될 수 있으므로, 상기와 같은 업데이트가 필요하다. 이벤트를 수신한 후 정책 수집기는, 이를 애플리케이션 로직으로 전달하여 애플리케이션 로직이 보안 컨트롤러로부터 수신한 해당 사용자 수준의 보안 정책을 업데이트(또는 생성)하도록 할 수 있다.
3. 사용예
본 아키텍처는 가능한 보안 공격에 대응하도록 설계되었다. 본 절에서는 malware 도메인 및 VoIP/VoLTE 보안 공격에서 주어진 보안 공격 리스트에 대해 I2NSF 프레임워크[i2nsf-framework]의 보안 공격 방어를 위한 절차를 예시한다.
3.1. Malware 도메인 리스트에 대한 보안 관리
도 5는 Malware 도메인 블랙리스트 작성의 보안 관리 아키텍처를 예시한 도면이다.
Malware 도메인 블랙리스트 작성은 악의적인 활동이 의심되는 가능한 공격 호스트, 서버 및 네트워크들의 IP 주소들을 유지 및 게시하는 것을 말한다.
Malware 도메인 블랙리스트 작성에 기반하여, Malware 도메인 리스트는 I2NSF 사용자의 Malware 도메인 관리자에 의해 수동 또는 자동으로 업데이트될 수 있다. 또한, Malware 도메인 관리자는 새롭게 추가된 Malware 도메인과의 패킷 전달을 방지하고 NSF의 하위 수준 보안 정책을 시행하기 위해, 주기적으로 새로운 사용자 수준의 보안 정책을 생성할 수 있다. 또한, Malware 도메인 관리자는 새로운 사용자 수준 보안 정책을 Policy Updater로 전송할 수 있으며, Policy Updater는 이를 보안 컨트롤러로 전달할 수 있다.
업데이트된 하위 수준 정책은 NSF Facing Interface를 통해 NSF에 의해 보안 컨트롤러로 전송되어, 보안 컨트롤러가 하위 수준 정책과 대응하는 사용자 수준 보안 정책을 생성하도록 할 수 있다. 보안 컨트롤러는 정책 수집기에 사용자 수준 보안 정책을 제공할 수 있다. 정책 수집기는 애플리케이션 로직으로서 정책을 Malware 도메인 관리자에 전달할 수 있다.
3.2 VoIP-VoLTE를 위한 보안 관리
VoIP-VoLTE 보안 관리는 불법적인 전화 및 인증이 의심되는 SIP 장치의 IP 주소, 소스 포트, 만료 시간, 사용자 에이전트 및 SIP(Session Initiation Protocol) URI의 블랙리스트를 유지 및 게시할 수 있다. 일반적인 보안 관리 아키텍처에서 VoIP-VoLTE 보안 관리자는 도 4의 VoIP-VoLTE 보안 서비스를 위한 애플리케이션 로직에 해당할 수 있다.
VoIP-VoLTE 보안 관리를 기반으로, 애플리케이션 로직 기능을 수행하는 VoIP-VoLTE 보안 관리자는 불법 장치 정보 리스트를 수동 또는 자동으로 업데이트할 수 있다. 또한, VoIP-VoLTE 보안 관리자는 새롭게 추가된 VoIP-VoLTE 공격자와의 패킷 전달을 방지하고 NSF의 하위 수준 보안 정책을 시행하기 위해 주기적으로 새로운 사용자 수준 보안 정책을 생성할 수 있다. VoIP-VoLTE 보안 관리자는 새로운 사용자 수준 보안 정책을 정책 갱신자로 전송할 수 있으며, 정책 갱신자는 이를 보안 컨트롤러로 전달할 수 있다.
NSF는 VoIP-VoLTE 공격에 대해 업데이트된 하위 수준 정책을 NSF Facing Interface를 통해 보안 컨트롤러로 전송되므로, 보안 컨트롤러가 IP 주소, 사용자 에이전트 및 해당 에이전트와 같은 상기 하위 수준 정책과 대응되는 사용자 수준 보안 정책을 생성하고, 보안 컨트롤러에 의해 추가될 필요가 있는 시간 값을 만료시킬 수 있다. 보안 컨트롤러는 정책 수집기에 사용자 수준 보안 정책을 제공할 수 있다. 정책 수집기는 애플리케이션 로직으로서 VoIP-VoLTE 보안 관리자에 정책을 전달할 수 있다.
7. 보안 고려 사항
보안 관리 아키텍처는 I2NSF 프레임워크[i2nsf-framework]로부터 파생되므로, I2NSF 프레임워크의 보안 고려 사항이 존재할 수 있다. 특히, 제안된 아키텍처의 구성 요소들간에 제어 메시지 또는 관리 메시지를 전달하는 데 적절한 보안 통신 채널이 사용되어야 한다.
[3] 제3 실시예
본 실시예에서는 I2NSF(Interface to Network Security Functions) 프레임워크의 보안 관리 아키텍처에 대해 설명한다. 이 보안 관리 아키텍처는 I2NSF 사용자, 보안 관리 시스템(즉, 보안 컨트롤러 및 개발자 관리 시스템) 및 I2NSF 프레임워크의 NSF(Network Security Functions)를 포함할 수 있다. I2NSF 사용자는 애플리케이션 로직, 정책 갱신자 및 이벤트 수집기를 포함할 수 있다. 보안 컨트롤러는 보안 정책 관리자와 NSF 능력 관리자를 포함할 수 있다. 이하에서는 앞서 상술한 구성들의 기능과 보안 관리 처리에 대해 설명한다. 또한, 이하에서는 Malware 도메인 리스트 보안 관리, VoIP-VoLTE 보안 관리 및 시간별 액세스 제어와 같은 대표적인 사용 사례에 대해 설명한다. 각 구성에 관한 설명은 앞서 제1 및 제2 실시예와 관련하여 상술한 설명이 동일하게 적용될 수 있으며, 중복되는 설명은 생략한다.
1. 도입
I2NSF 프레임워크 [i2nsf-framework]에 사용자의 사용자 수준 보안 정책을 적용하기 위해, I2NSF 사용자는 소비자 지향 인터페이스(Consumer Facing Interface)를 통해 보안 컨트롤러에 이러한 사용자 수준 보안 정책을 제공할 수 있다. 이하에서는 I2NSF 프레임워크의 주어진 사용자 수준 정책을 위한 보안 관리 아키텍처를 제안한다. 이 아키텍처는 I2NSF 사용자, 보안 관리 시스템(즉, 보안 컨트롤러 및 개발자 관리 시스템) 및 I2NSF 프레임워크의 NSF를 포함할 수 있다. I2NSF 사용자는 애플리케이션 로직, 정책 갱신자 및 이벤트 수집기를 포함할 수 있다. 보안 컨트롤러는 보안 정책 관리자 및 NSF 능력 관리자를 포함한다.
보안 컨트롤러의 보안 정책 관리자와 NSF 능력 관리자는 I2NSF 사용자의 정책 갱신자가 Consumer-Facing Interface를 통해 제공하는 업데이트된 보안 정책을 제어할 수 있다. 새 정책이 생성되었거나 기존 정책이 업데이트되어야 할 필요가 있는 경우, 정책 갱신자가 새 정책 및/또는 기존 정책의 업데이트 내용을 보안 컨트롤러에 제공할 수 있다. 반면, NSF가 하위 수준 정책을 변경해야 하는 이벤트가 발생하면, NSF는 해당 이벤트를 보안 컨트롤러로 전송할 수 있다. 보안 컨트롤러는 해당 이벤트를 이벤트 수집기로 전달하면, 이벤트 수집기가 이를 애플리케이션 로직으로 전달할 수 있다. 그 후, 애플리케이션 로직은 수신한 이벤트에 따라 현재 정책을 업데이트할 수 있다.
제3 실시예에서는 보안 관리를 위한 추가 구성 요소를 I2NSF 프레임워크에 통합하는 보안 관리 아키텍처를 제안한다. 이러한 아키텍처는 유연하고 효과적인 보안 정책을 지원하도록 설계되었다. 애플리케이션 로직은 사용자 수준 정책을 생성하고 정책 갱신자는 이를 Consumer-Facing Interface를 통해 보안 정책 관리자로 전송할 수 있다. 보안 정책 관리자는 사용자 수준 정책을 보안 컨트롤러의 여러 하위 수준 정책들에 매핑할 수 있다. 매핑 후, 하위 수준의 정책들은 NSF에 배포되어 NSF에 적용될 수 있다.
2. 목표
제3 실시예에 따른 보안 관리 아키텍처의 두 가지 주 목적은 다음과 같다.
(1) 높은 수준의 보안 관리: NSF들에서의 유연하고 효과적인 보안 정책의 시행을 지원하기 위한 보안 관리 아키텍처의 설계를 제안한다.
(2) 보안 정책의 자동 업데이트: NSF들이 새로운 보안 공격에 대해 하위 수준 정책을 변경해야 하는 이벤트가 발생한 경우, 해당 이벤트를 대응하는 사용자 수준의 보안 정책들에 반영하기 위함이다.
3. 보안 관리 아키텍처
본 절에서는 I2NSF의 보안 관리 아키텍처에 대해 설명하고 보안 컨트롤러 및 개발자 관리 시스템이 포함된 보안 관리 시스템에 중점을 두고 설명한다. 또한, 본 절에서는 보안 컨트롤러의 기본 동작에 대해 설명하고 아키텍처에 포함되는 각 구성 요소의 세부 사항을 설명한다.
도 6은 I2NSF 프레임워크 내의 보안 관리 아키텍처를 예시한 도면이다.
도 6의 아키텍처는 유연하고 효과적인 보안 정책의 시행을 지원하도록 설계되었다. I2NSF 사용자의 애플리케이션 로직은 새로운 보안 공격에 따라 사용자 수준의 정책을 생성하고, I2NSF 사용자의 정책 갱신자는 상기 사용자 수준의 정책을 보안 컨트롤러의 보안 정책 관리자에게 보낸다. 보안 정책 관리자는 사용자 수준 정책을 NSF 능력 관리자에 등록된 NSF 능력과 관련된 몇 개의 하위 수준 정책들에 매핑할 수 있다. 매핑 후, 보안 정책 관리자는 NSF Facing Interface를 통해 하위 수준 정책들을 NSF(들)로 배포할 수 있다. 다음 절에서는 각 구성 요소의 세부 사항에 대해 설명한다.
4.1 보안 정책 관리자
보안 정책 관리자는 Consumer-Facing Interface를 통해 정책 갱신자로부터 사용자 수준 정책을 수신하고, 사용자 수준 정책을 NSF 능력 관리자의 특정 NSF 능력과 관련된 몇 개의 하위 수준 정책들로 매핑하는 구성이다. 또한, 보안 정책 관리자는 이러한 하위 수준 정책들을 NSF Facing Interface를 통해 NSF(들)로 전달할 수 있다.
한편, 하위 레벨 정책을 변경해야 하는 이벤트가 NSF에서 발생하면, NSF는 NSF Facing Interface를 통해 보안 정책 관리자에게 해당 이벤트를 전송할 수 있다. 이후, 보안 정책 관리자는 Consumer-Facing Interface를 통해 해당 이벤트를 이벤트 수집기로 전송한다.
4.2 NSF 능력 관리자
NSF 능력 관리자는 보안 컨트롤러에 통합된 구성이다. NSF 능력 관리자는 등록 인터페이스를 통해 개발자 관리 시스템에 등록된 NSF 능력을 저장하고, 이를 보안 정책 관리자와 공유하여 보안 정책 관리자가 NSF 능력과 관련된 하위 수준 정책을 생성하도록 할 수 있다. 또한, 새로운 NSF가 등록될 때마다, NSF 능력 관리자는 등록 인터페이스를 통해 NSF 능력 관리자의 관리 테이블에 NSF 능력을 등록하도록 개발자 관리 시스템에 요청할 수 있다. 한편, 기존의 NSF가 삭제되면, NSF 능력 관리자는 관리 테이블에서 NSF 능력을 제거한다.
4.3 개발자 관리 시스템
개발자 관리 시스템은 등록 인터페이스를 통해 NSF 능력 관리자에 새로운 NSF 능력을 등록하는 구성이다. 또한, 등록된 NSF에 업데이트가 있는 경우, 해당 업데이트는 개발자 관리 시스템에서 NSF 능력 관리자로 전달된다.
4.4. 애플리케이션 로직
애플리케이션 로직은 보안 공격을 차단 또는 완화하기 위한 사용자 수준 보안 정책을 생성하고, 생성된 정책을 정책 갱신자로 전송하는 구성이다. 이러한 애플리케이션 로직에 대해서는 이하의 사용예에서 자세한 동작을 설명한다.
4.5. 정책 갱신자
정책 갱신자는 애플리케이션 로직에서 생성된 사용자 수준 보안 정책을 수신하고, 이를 Consumer Facing Interface를 통해 보안 정책 관리자에게 전달하는 구성이다.
4.6 이벤트 수집기
이벤트 수집기는 애플리케이션 로직의 사용자 수준 정책을 업데이트(또는 생성)할 때 반영되어야 하는 이벤트를 보안 컨트롤러로부터 수신한다. NSF에서 발생하는 특정 이벤트에 따라 하위 수준의 보안 정책이 업데이트되므로, NSF에서 이벤트를 수신하는 절차가 필요하다. 이벤트를 수신한 후, 이벤트 수집기는 이를 애플리케이션 로직으로 전달하여, 애플리케이션 로직이 보안 컨트롤러로부터 수신한 이벤트를 기반으로 사용자 수준의 보안 정책을 업데이트(또는 생성)할 수 있도록 한다.
5. 사용예
본 아키텍처는 실제 환경에서 발생할 수 있는 보안 공격에 대응하도록 설계된다. 본 절에서는 Malware 도메인에서 주어진 보안 공격 리스트, VoIP/VoLTE 보안 공격 및 시간별 액세스 제어에 대한 I2NSF 프레임워크[i2nsf-framework]의 보안 공격에 대한 방어 절차를 설명한다.
5.1. Malware 도메인 리스트 보안 관리
Malware 도메인 차단 리스트 작성은 악의적인 활동이 의심되는 가능한 공격 호스트, 서버 및 네트워크의 IP 주소들을 유지 및 게시한다.
도 7은 Malware 도메인 블랙리스트 작성의 보안 관리 아키텍처를 예시한 도면이다.
Malware 도메인 블랙리스트 작성에 기초하여, Malware 도메인들의 리스트는 I2NSF 사용자의 Malware 도메인 관리자에 의해 수동 또는 자동으로 업데이트될 수 있다. 또한, Malware 도메인 관리자는 새로 추가된 Malware 도메인과의 패킷 전달을 방지하고 NSF의 하위 수준 보안 정책들을 시행하기 위해 주기적으로 새로운 사용자 수준 보안 정책을 생성할 수 있다. 또한, Malware 도메인 관리자는 새로운 사용자 수준 보안 정책을 정책 갱신자로 전송할 수 있으며, 정책 갱신자는 보안 컨트롤러로 이를 전달할 수 있다.
NSF가 새로운 위험 도메인을 탐지하면, 해당 IP 주소를 NSF Facing Interface를 통해 보안 컨트롤러로 전송할 수 있다. 보안 컨트롤러는 이벤트 수집기에 IP 주소를 전달하며, 이벤트 수집기는 해당 IP 주소를 위험 도메인 관리자에게 전달할 수 있다. 이에 기초하여, 위험 도메인 관리자는 위험 도메인 데이터 베이스를 업데이트할 수 있다.
5.2 VoIP-VoLTE에 대한 보안 관리
VoIP-VoLTE 보안 관리는 불법적인 전화 및 인증이 의심되는 SIP 장치의 IP 주소, 소스 포트, 만료 시간, 사용자 에이전트(User agent) 및 SIP(Session Initiation Protocol) URI의 블랙리스트를 유지 관리하고 게시한다. 보안 관리 아키텍처에서 VoIP-VoLTE 보안 관리자는 도 6에서의 VoIP-VoLTE 보안 서비스를 위한 애플리케이션 로직의 역할을 수행한다.
VoIP-VoLTE 보안 관리에 기초하여, 애플리케이션 로직 기능을 수행하는 VoIP-VoLTE 보안 관리자는 불법 장치 정보의 목록를 수동 또는 자동으로 업데이트할 수 있다. 또한, VoIP-VoLTE 보안 관리자는 새롭게 추가된 VoIP-VoLTE 공격자와의 패킷 전달을 방지하고 NSF의 하위 수준 보안 정책을 시행하기 위해 주기적으로 새로운 사용자 수준 보안 정책을 생성할 수 있다. 또한, VoIP-VoLTE 보안 관리자는 새로운 사용자 수준 보안 정책을 정책 갱신자로 전송할 수 있으며, 정책 갱신자는 이를 보안 컨트롤러로 전달할 수 있다.
NSF가 도메인으로부터 전달된 비정상적인 메시지 또는 전화를 검출하는 경우, IP 주소, 사용자 에이전트 및 만료 시간 값과 같은 도메인 정보는 NSF Facing 인터페이스를 통해 NSF에 의해 보안 컨트롤러로 전송된다. 보안 컨트롤러는 이벤트 수집기에 탐지된 도메인 정보를 전달하고, 이벤트 수집기는 탐지된 도메인 정보를 VoIP-VoLTE 보안 관리자로 전달하며, VoIP-VoLTE 보안 관리자는 탐지된 도메인 정보에 기초하여 VoIP-VoLTE 데이터 베이스를 업데이트한다.
5.3 시간별 액세스 제어에 대한 보안 관리
시간별 액세스 제어 정책은 특정 기간 동안 특정 웹 사이트에 대한 사용자의 액세스를 관리한다. 예를 들어, 회사에서 관리자는 직원이 근무 시간 동안 업무에 방해가 될 수 있는 Youtube에 액세스하는 것을 차단할 수 있다.
I2NSF 사용자는, 시간별 액세스 제어에 기초하여, 애플리케이션 로직에 차단된 웹 사이트 및 차단 시간의 리스트를 등록한다. 애플리케이션 로직은 리스트를 데이터 베이스에 저장하고 사용자 수준의 보안 정책(예를 들어, 리스트에서 차단된 웹 사이트 및 차단 시간을 확인하여 웹 사이트에 대한 액세스 차단)을 생성한다. 애플리케이션 로직은 이를 정책 갱신자로 전달하면, 정책 갱신자는 이를 보안 컨트롤러로 전달한다. 보안 컨트롤러에서 보안 정책 관리자는 사용자 수준 정책을 하위 수준 정책들에 매핑한 다음, NSF가 하위 수준 정책들을 적용할 수 있도록 이들을 NSF로 전송한다.
6. 보안 고려 사항
보안 관리 아키텍처는 I2NSF 프레임워크[i2nsf-framework]로부터 파생되므로, I2NSF 프레임워크의 보안 고려 사항이 존재할 수 있다. 특히, 제안된 아키텍처의 구성 요소들간에 제어 메시지 또는 관리 메시지를 전달하는 데 적절한 보안 통신 채널이 사용되어야 한다.
도 8은 본 발명의 일 실시예에 따른 보안 관리 시스템의 보안 관리 방법에 관한 순서도이다. 본 순서도와 관련하여 앞서 상술한 실시예들이 동일/유사하게 적용될 수 있으며, 중복되는 설명은 생략할 수 있다.
우선, 보안 관리 시스템은 I2NSF 사용자로부터 보안 공격을 차단 또는 완화하기 위한 사용자 수준 정책을 수신할 수 있다(S810).
다음으로, 보안 관리 시스템은 상기 사용자 수준 정책을 보안 관리 시스템에 등록된 NSF 능력과 관련된 하위 수준 보안 정책들에 매핑할 수 있다(S820).
마지막으로, 보안 관리 시스템은 하위 수준 보안 정책들을 적어도 하나의 NSF에 전달할 수 있다(S830).
I2NSF 사용자는 애플리케이션 로직, 정책 갱신자 및/또는 이벤트 수집기를 포함할 수 있다. 여기서, 애플리케이션 로직은 사용자 수준 정책을 생성 및 업데이트하여 정책 갱신자로 전송하며, 정책 갱신자는 사용자 수준 정책을 사용자 지향 인터페이스를 통해 보안 관리 시스템으로 전달하며, 이벤트 수집기는 사용자 수준 정책의 생성 또는 업데이트에 기초가 되는 이벤트를 수신하여 애플리케이션 로직으로 전송할 수 있다.
사용자 수준 정책은 일 실시예로서, 특정 공격 호스트, 서버 및 네트워크의 IP 주소가 포함된 블랙리스트를 기반으로 생성될 수 있다. 이 경우, 이벤트는 상기 블랙리스트로의 포함 기준을 만족하는 IP 주소에 해당할 수 있다.
또는, 사용자 수준 정책은 다른 실시예로서, 차단 웹 사이트 및 차단 시간이 포함된 블랙리스트를 기반으로 생성될 수 있다.
또는, 사용자 수준 정책은 다른 실시예로서, 특정 SIP 장치의 IP 주소, 소스 포트, 만료 시간, 사용자 에이전트 및/또는 SIP URI가 포함된 불법 장치 차단 목록을 기반으로 생성될 수 있다. 이 경우, 이벤트는 불법 장치 차단 목록으로의 포함 기준을 만족하는 도메인 정보에 해당할 수 있다.
보안 관리 시스템은 보안 정책 관리자, NSF 능력 관리자 및/또는 개발자 관리 시스템을 포함할 수 있다. 개발자 관리 시스템은 등록 인터페이스를 통해 NSF 능력을 등록 및 업데이트하며, NSF 능력 관리자는 개발자 관리 시스템에 등록 및 업데이트된 NSF 능력을 저장할 수 있다. 보안 정책 관리자는 사용자 수준 정책을 NSF 능력 관리자에 저장된 NSF 능력과 관련된 하위 수준 보안 정책들과 매핑하고, 하위 수준 보안 정책들을 NSF 지향 인터페이스(NSF-Facing Interface)를 통해 적어도 하나의 NSF로 전달할 수 있다.
본 발명에 따른 실시예는 다양한 수단, 예를 들어, 하드웨어, 펌웨어(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 (20)

  1. 보안 관리 시스템의 보안 관리 방법에 있어서,
    I2NSF(Interface to Network Security Functions) 사용자로부터 보안 공격을 차단 또는 완화하기 위한 사용자 기반 상위 수준 (high-level) 보안 정책을 수신하는 단계;
    상기 사용자 관점 보안 정책을 상기 보안 관리 시스템에 등록된 NSF 능력(capability)과 관련된 NSF 기반 하위 수준(low-level) 보안 정책들에 매핑하는 단계; 및
    상기 하위 수준 보안 정책들을 적어도 하나의 NSF에 전달하는 단계; 를 포함하는, 보안 관리 방법.
  2. 제 1 항에 있어서,
    상기 I2NSF 사용자는 애플리케이션 로직, 정책 갱신자 및/또는 이벤트 수집기를 포함하는, 보안 관리 방법.
  3. 제 2 항에 있어서,
    상기 애플리케이션 로직은 상기 사용자 수준 보안 정책을 생성 및 업데이트하여 상기 정책 갱신자로 전송하며,
    상기 정책 갱신자는 상기 사용자 수준 보안 정책을 사용자 지향 인터페이스(Consumer-Facing Interface)를 통해 상기 보안 관리 시스템으로 전달하며,
    상기 이벤트 수집기는 상기 사용자 수준 보안 정책의 생성 또는 업데이트에 기초가 되는 이벤트를 수신하여 상기 애플리케이션 로직으로 전송하는, 보안 관리 방법.
  4. 제 3 항에 있어서,
    상기 사용자 수준 보안 정책은 특정 공격 호스트, 서버 및 네트워크의 IP(Internet Protocol) 주소가 포함된 블랙리스트를 기반으로 생성되는, 보안 관리 방법.
  5. 제 4 항에 있어서,
    상기 이벤트는 상기 블랙리스트로의 포함 기준을 만족하는 IP 주소에 해당하는, 보안 관리 방법.
  6. 제 3 항에 있어서,
    상기 사용자 수준 보안 정책은 차단 웹 사이트 및 차단 시간이 포함된 블랙리스트를 기반으로 생성되는, 보안 관리 방법.
  7. 제 3 항에 있어서,
    상기 사용자 수준 보안 정책은 특정 SIP(Session Initiation Protocol) 장치의 IP 주소, 소스 포트, 만료 시간, 사용자 에이전트 및/또는 SIP URI가 포함된 불법 장치 차단 목록을 기반으로 생성되는, 보안 관리 방법.
  8. 제 7 항에 있어서,
    상기 이벤트는 상기 불법 장치 차단 목록으로의 포함 기준을 만족하는 도메인 정보에 해당하는, 보안 관리 방법.
  9. 제 1 항에 있어서,
    상기 보안 관리 시스템은 보안 정책 관리자, NSF 능력 관리자 및/또는 개발자 관리 시스템을 포함하는, 보안 관리 방법.
  10. 제 9 항에 있어서,
    상기 개발자 관리 시스템은 등록 인터페이스를 통해 NSF 능력을 등록 및 업데이트하며,
    상기 NSF 능력 관리자는 상기 개발자 관리 시스템에 등록 및 업데이트된 NSF 능력을 저장하며,
    상기 보안 정책 관리자는 상기 사용자 수준 보안 정책을 상기 NSF 능력 관리자에 저장된 상기 NSF 능력과 관련된 상기 하위 수준 보안 정책들과 매핑하고, 상기 하위 수준 보안 정책들을 NSF 지향 인터페이스(NSF-Facing Interface)를 통해 상기 적어도 하나의 NSF로 전달하는, 보안 관리 방법.
  11. 보안 관리 아키텍처에 있어서,
    보안 공격을 차단 또는 완화하기 위한 사용자 기반 상위 수준(high-level) 보안 정책을 생성하는 I2NSF(Interface to Network Security Functions) 사용자;
    상기 I2NSF 사용자로부터 상기 사용자 수준 보안 정책을 수신하고, 상기 사용자 수준 보안 정책을 상기 보안 관리 시스템에 등록된 NSF 능력(capability)과 관련된 NSF 기반 하위 수준(low-level) 보안 정책들에 매핑하는, 보안 관리 시스템;
    상기 보안 관리 시스템으로부터 상기 하위 수준 보안 정책들을 수신하는 적어도 하나의 NSF; 를 포함하는, 보안 관리 아키텍처.
  12. 제 11 항에 있어서,
    상기 I2NSF 사용자는 애플리케이션 로직, 정책 갱신자 및/또는 이벤트 수집기를 포함하는, 보안 관리 아키텍처.
  13. 제 12 항에 있어서,
    상기 애플리케이션 로직은 상기 사용자 수준 보안 정책을 생성 및 업데이트하여 상기 정책 갱신자로 전송하며,
    상기 정책 갱신자는 상기 사용자 수준 보안 정책을 사용자 지향 인터페이스(Consumer Facing Interface)를 통해 상기 보안 관리 시스템으로 전달하며,
    상기 이벤트 수집기는 상기 사용자 수준 보안 정책의 생성 또는 업데이트에 기초가 되는 이벤트를 수신하여 상기 애플리케이션 로직으로 전송하는, 보안 관리 아키텍처.
  14. 제 13 항에 있어서,
    상기 사용자 수준 보안 정책은 특정 공격 호스트, 서버 및 네트워크의 IP(Internet Protocol) 주소가 포함된 블랙리스트를 기반으로 생성되는, 보안 관리 아키텍처.
  15. 제 14 항에 있어서,
    상기 이벤트는 상기 블랙리스트로의 포함 기준을 만족하는 IP 주소에 해당하는, 보안 관리 아키텍처.
  16. 제 13 항에 있어서,
    상기 사용자 수준 보안 정책은 차단 웹 사이트 및 차단 시간이 포함된 블랙리스트를 기반으로 생성되는, 보안 관리 아키텍처.
  17. 제 13 항에 있어서,
    상기 사용자 수준 보안 정책은 특정 SIP(Session Initiation Protocol) 장치의 IP 주소, 소스 포트, 만료 시간, 사용자 에이전트 및/또는 SIP URI가 포함된 불법 장치 차단 목록을 기반으로 생성되는, 보안 관리 아키텍처.
  18. 제 17 항에 있어서,
    상기 이벤트는 상기 불법 장치 차단 목록으로의 포함 기준을 만족하는 도메인 정보에 해당하는, 보안 관리 아키텍처.
  19. 제 11 항에 있어서,
    상기 보안 관리 시스템은 보안 정책 관리자, NSF 능력 관리자 및/또는 개발자 관리 시스템을 포함하는, 보안 관리 아키텍처.
  20. 제 19 항에 있어서,
    상기 개발자 관리 시스템은 등록 인터페이스를 통해 NSF 능력을 등록 및 업데이트하며,
    상기 NSF 능력 관리자는 상기 개발자 관리 시스템에 등록 및 업데이트된 NSF 능력을 저장하며,
    상기 보안 정책 관리자는 상기 사용자 수준 보안 정책을 상기 NSF 능력 관리자에 저장된 상기 NSF 능력과 관련된 상기 하위 수준 보안 정책들과 매핑하고, 상기 하위 수준 보안 정책들을 NSF 지향 인터페이스(NSF Facing Interface)를 통해 상기 적어도 하나의 NSF로 전달하는, 보안 관리 아키텍처.
PCT/KR2017/007108 2016-12-01 2017-07-04 네트워크 가상화 환경에서 보안 관리를 위한 구조 WO2018101565A1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2016-0163114 2016-12-01
KR20160163114 2016-12-01

Publications (1)

Publication Number Publication Date
WO2018101565A1 true WO2018101565A1 (ko) 2018-06-07

Family

ID=62242561

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2017/007108 WO2018101565A1 (ko) 2016-12-01 2017-07-04 네트워크 가상화 환경에서 보안 관리를 위한 구조

Country Status (2)

Country Link
KR (1) KR101863236B1 (ko)
WO (1) WO2018101565A1 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210029175A1 (en) * 2019-07-24 2021-01-28 Research & Business Foundation Sungkyunkwan University Security policy translation in interface to network security functions
CN114666161A (zh) * 2022-04-29 2022-06-24 深信服科技股份有限公司 一种组件安全策略管理方法、装置、设备及存储介质

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020009418A1 (ko) * 2018-07-02 2020-01-09 성균관대학교 산학협력단 I2nsf 네트워크 보안 기능에 직면한 인터페이스 yang 데이터 모델
US11792227B2 (en) 2019-06-12 2023-10-17 Research & Business Foundation Sungkyunkwan University I2NSF network security function facing interface YANG data model
KR102335012B1 (ko) * 2019-11-04 2021-12-07 성균관대학교산학협력단 I2nsf 네트워크 보안 능력에 직면한 인터페이스 yang 데이터 모델
US20220141256A1 (en) * 2020-11-02 2022-05-05 Research & Business Foundation Sungkyunkwan University Method and system for performing security management automation in cloud-based security services

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120159632A1 (en) * 2009-08-25 2012-06-21 Telefonaktiebolaget L M Ericsson (Publ) Method and Arrangement for Detecting Fraud in Telecommunication Networks

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106464659A (zh) * 2014-06-30 2017-02-22 上海贝尔股份有限公司 软件定义网络中的安全
KR101669518B1 (ko) * 2014-12-30 2016-10-27 주식회사 시큐아이 Sdn 기반의 네트워크 모듈 관리 장치 및 방법

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120159632A1 (en) * 2009-08-25 2012-06-21 Telefonaktiebolaget L M Ericsson (Publ) Method and Arrangement for Detecting Fraud in Telecommunication Networks

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
H. KIM ET AL: "An Architecture for Security Management in I2NSF Framework draft-kim-i2nsf-security-management-architecture-00", DRAFT-KIM-I2NSF-SECURITY-MANAGEMENT-ARCHITECTURE-00, 4 July 2016 (2016-07-04), XP055607018, Retrieved from the Internet <URL:https://datatracker.ietf.org/doc/draft-kim-i2nsf-security-management-architecture/00> *
H. KIM: "An Architecture for Security Management in I2NSF Framework draft-kim-i2nsf-security-management-architecture-03.txt", DRAFT-KIM-I2NSF-SECURITY-MANAGEMENT-ARCHITECTURE-03,, 31 October 2016 (2016-10-31), XP015116427, Retrieved from the Internet <URL:https://datatracker.ietf.org/doc/draft-kim-i2nsf-security-management-architecture> *
J. JEONG: "I2NSF Data Model of Consumer-Facing Interface for Security Management draft-jeong-i2nsf-consumer-facing-interface-dm-00", DRAFT-JEONG-I2NSF-CONSUMER-FACING-INTERFACE-DM-00, NETWORK WORKING GROUP , INTERNET -DRAFT, 13 November 2016 (2016-11-13), XP055607009, Retrieved from the Internet <URL:https://tools.ietf.org/html/draft-jeong-i2nsf-consumer-facing-interface-dm-00> *
R. KUMAR: "Requirements for Client-Facing Interface to Security Controller. draft-ietf-i2nsf-client-facing-interface-req-00", DRAFT-IETF-I2NSF-CLIENT-FACING-INTERFACE-REQ-00, I2NSF WORKING GROUP , INTERNET -DRAFT, 28 October 2016 (2016-10-28), XP055607013, Retrieved from the Internet <URL:https://datatracker.ietf.org/doc/draft-ietf-i2nsf-client-facing-interface-req/00/?include-text=1> *
S. HYUN ET AL: "NSF-triggered Traffic Steering in I2NSF Framework; draft-hyun-i2nsf-nsf-triggered-steering-01.txt", DRAFT-HYUN- I2NSF-NSF-TRIGGERED-STEERING-01, NETWORK WORKING GROUP , INTERNET -DRAFT, 13 November 2016 (2016-11-13), XP015116617, Retrieved from the Internet <URL:https://datatracker.ietf.org/doc/draft-hyun-i2nsf-nsf-triggered-steering/01> *
SANGHAK OH: "A Flexible Architecture for Orchestrating Network Security Functions to Support High-level Security Policies", IMCOM, 7 January 2017 (2017-01-07), Retrieved from the Internet <URL:https://www.semanticscholar.org/paper/A-flexible-architecture-for-orchestrating-network-Oh-Kim/05a693720465dcc2509af10cb72d19972e04b6c4> *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210029175A1 (en) * 2019-07-24 2021-01-28 Research & Business Foundation Sungkyunkwan University Security policy translation in interface to network security functions
US11632402B2 (en) * 2019-07-24 2023-04-18 Research & Business Foundation Sungkyunkwan University Security policy translation in interface to network security functions
CN114666161A (zh) * 2022-04-29 2022-06-24 深信服科技股份有限公司 一种组件安全策略管理方法、装置、设备及存储介质
CN114666161B (zh) * 2022-04-29 2024-04-09 深信服科技股份有限公司 一种组件安全策略管理方法、装置、设备及存储介质

Also Published As

Publication number Publication date
KR101863236B1 (ko) 2018-06-01

Similar Documents

Publication Publication Date Title
WO2018101565A1 (ko) 네트워크 가상화 환경에서 보안 관리를 위한 구조
KR102136039B1 (ko) 소프트웨어 정의 네트워크에서의 보안
US9407602B2 (en) Methods and apparatus for redirecting attacks on a network
WO2013085281A1 (ko) 클라우딩 컴퓨팅 서비스에서의 보안을 위한 방법 및 장치
WO2012141556A2 (en) Machine-to-machine node erase procedure
WO2023033586A1 (ko) Tcp 세션 제어에 기초하여 애플리케이션의 네트워크 접속을 제어하기 위한 시스템 및 그에 관한 방법
WO2019098678A1 (ko) 보안 서비스를 제공하기 위한 방법 및 이를 위한 장치
JP2022514172A (ja) 相乗的なｄｎｓセキュリティ更新
WO2023033585A1 (ko) 분산 게이트웨이 환경에 최적화된 터널링 및 게이트웨이 접속 시스템 및 그에 관한 방법
WO2016195199A1 (ko) 무선 통신 시스템에서 폴링 채널을 통해 요청을 처리하기 위한 방법 및 이를 위한 장치
WO2023090755A1 (ko) 가상화 인스턴스의 네트워크 접속을 제어하기 위한 시스템 및 그에 관한 방법
WO2023163514A1 (ko) 컨트롤러 기반의 네트워크 접속을 제어하기 위한 시스템 및 그에 관한 방법
WO2023146304A1 (ko) 애플리케이션의 파일 송신 및 수신을 제어하기 위한 시스템 및 그에 관한 방법
WO2015194885A1 (ko) 클라이언트 경로 제어 시스템을 활용한 장애유발 클라이언트 검출 방법 및 시스템
WO2023177238A1 (ko) 컨트롤러 기반의 네트워크 접속을 제어하기 위한 시스템 및 그에 관한 방법
WO2019088671A1 (ko) 네트워크 보안 서비스를 제공하기 위한 방법 및 이를 위한 장치
WO2022231304A1 (ko) 컨트롤러 기반의 네트워크 접속을 제어하기 위한 시스템 및 그에 관한 방법
WO2013129804A1 (ko) 무선 네트워크 부하 저감 정책 분석 방법 및 시스템과 기록매체
KR20180046894A (ko) Nfv 기반 메시징 서비스 보안 제공 방법 및 이를 위한 시스템
WO2023211120A1 (ko) 프록시에 기반하여 애플리케이션의 파일 송신 및 수신을 제어하기 위한 시스템 및 그에 관한 방법
WO2018097422A1 (ko) 네트워크 보안 기능에 의해 트리거되는 트래픽 스티어링을 위한 방법 및 시스템, 이를 위한 장치
WO2024029658A1 (ko) 네트워크에서의 접근 통제 시스템 및 그 방법
WO2017155280A2 (ko) Sdn/nfv 기반 ip 통화 서비스 보안 시스템 및 보안 시스템의 동작 방법
WO2018169287A1 (ko) 보안 서비스를 제공하기 위한 방법, 시스템 및 이를 위한 장치
WO2017014381A1 (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: 17877286

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: 17877286

Country of ref document: EP

Kind code of ref document: A1