WO2018169292A1 - Method and system for providing security service and device for same - Google Patents

Abstract

A data communication method for an I2NSF user device comprises the steps of: encoding security policy data with respect to a security service; and transmitting the security policy data to a security controller by means of a user-contact interface, wherein the security policy data can comprise a policy lifecycle field comprising the lifecycle of the security policy, a policy rule field comprising the rule of the security policy and an operation field comprising an operation to be performed if the rule is matched.

Description

Method and system for providing security service, apparatus for same

The present invention relates to a system for providing a security service, and more particularly to an interface of a system for providing a security service.

Today, many companies, such as service providers and Internet service providers, have adopted Network Functions Virtualization (NFV) technology to reduce operating costs and leverage resources in a more efficient and flexible way. In addition, the use of network functions and resources provided by third-party service providers is becoming increasingly popular. To protect their network systems and information assets, companies have begun to subscribe to and use the security features provided by third-party security vendors instead of operating security appliances themselves.

This operational model offers a variety of benefits. Companies can reduce capital outlays because they do not have to pay for physical security equipment. In addition, you can always maintain an up-to-date database of various attack signatures.

However, since security functions are developed by multiple solution vendors and managed by multiple network operators, in order to successfully deploy NFV-based security functions, Standardization is required.

An object of the present invention is to propose a data model for an interface of a system for providing a security service.

The technical problems to be achieved in the present invention are not limited to the technical problems mentioned above, and other technical problems not mentioned above will be clearly understood by those skilled in the art from the following description. Could be.

A data communication method of an I2NSF user device according to an embodiment of the present invention includes encoding security policy data for a security service; And forwarding the security policy data to a security controller via a consumer-facing interface, wherein the security policy data includes a policy lifecycle field that includes a lifecycle of the security policy, and a rule of the security policy. It may include a policy rule field and an action field including an action to be performed when the rule is matched.

In an embodiment, the encoding of the security policy data may be performed using a YANG data modeling language.

According to an embodiment of the present invention, an I2NSF user device includes a communication module for communicating data; And a processor for controlling the communication module, the processor encoding: security policy data for a security service; And transmitting the security policy data to a security controller through a consumer-facing interface, wherein the security policy data includes a policy lifecycle field including a lifecycle of the security policy, a policy rule field including a rule of the security policy, and It may include an action field including an action to be performed when the rule is matched.

In an embodiment, the policy lifecycle field may include policy lifecycle ID information identifying the policy lifecycle field, expiration event information indicating an event that causes the security policy to expire, and an indication of when the security policy expires. Expiration time information may be included.

In an embodiment, the policy rule field may include policy rule ID information identifying the policy rule field, rule name information indicating a name of the rule, and policy date information indicating a date when a rule of the security policy is created. can do.

In an embodiment, the policy rule field may further include service information indicating a service for performing a network security function (NSF) to manage a security attack.

In an embodiment, the policy rule field may further include condition information indicating an inspection condition to be applied to a packet or traffic by a network security function (NSF) for security inspection.

In an embodiment, the operation field may include inflow operation information indicating a configuration of an inflow operation and outflow operation information indicating a configuration of an outflow operation.

In an embodiment, the configuration of the inflow operation may include at least one of a permit, a mirror, or a log, and the configuration of the leakage operation may include redirection.

According to an embodiment of the present invention, high-level security management can be provided by proposing a design of a generic security management architecture in order to support flexible and efficient security policies in NSF.

Further, according to an embodiment of the present invention, it is possible to provide an automatic update of security policies by providing a reflection of updated low-level security policies for new security attacks on corresponding user perspective security policies. .

The effects obtainable in the present invention are not limited to the above-mentioned effects, and other effects not mentioned will be clearly understood by those skilled in the art from the following description. .

BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, included as part of the detailed description in order to provide a thorough understanding of the present invention, provide embodiments of the present invention and together with the description, describe the technical features of the present invention.

1 illustrates an I2NSF (Interface to Network Security Functions) system according to an embodiment of the present invention.

2 illustrates the architecture of an I2NSF system in accordance with another embodiment of the present invention.

3 illustrates a hairdressing model for a consumer-facing interface of an I2NSF system in accordance with an embodiment of the present invention.

4 illustrates a generic data model for a security service according to one embodiment of the invention.

5 illustrates a YANG data model for a security service according to an embodiment of the present invention.

6 illustrates a generic data model for a security service according to another embodiment of the present invention.

7 and 8 illustrate a YANG data model for a security service according to another embodiment of the invention.

9 illustrates a generic data model for a security service according to another embodiment of the present invention.

10 illustrates a YANG data model for a security service according to another embodiment of the present invention.

11 illustrates XML output for a VoIP service according to one embodiment of the invention.

12 illustrates a block diagram of a network device according to an embodiment of the present invention.

 12 illustrates a block diagram of a network device according to an embodiment of the present invention.

13 is a flowchart of a data communication method of a network device via a consumer-facing interface according to an embodiment of the present invention.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. The detailed description, which will be given below with reference to the accompanying drawings, is intended to explain exemplary embodiments of the present invention and is not intended to represent the only embodiments in which the present invention may be practiced. The following detailed description includes specific details in order to provide a thorough understanding of the present invention. However, one of ordinary skill in the art appreciates that the present invention may be practiced without these specific details.

In some instances, well-known structures and devices may be omitted or shown in block diagram form centering on the core functions of the structures and devices in order to avoid obscuring the concepts of the present invention.

Specific terms used in the following description are provided to help the understanding of the present invention, and the use of such specific terms may be changed to other forms without departing from the technical spirit of the present invention.

Recently, a basic standard interface for NFV-based security functions has been developed by the Interface to Network Security Functions (I2NSF) working group. It is part of the International Internet Standards Organization called the Internet Engineering Task Force (IETF).

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.

In the I2NSF architecture, without having to consider the management of the NSF (s) in detail (management of the NSF eventually requires enforcement of the security policy), the user is required to protect network resources in the user's network system. A protection policy can be defined. In addition, a standardized interface from multiple vendors to NSF (s) can simplify the setup and management of tasks for heterogeneous NSF (s).

The present specification proposes a YANG data model for security management based on I2NSF using NFV (Network Function Virtualization).

In addition, the present specification proposes a security management architecture based on the I2NSF framework. As an embodiment, the security management architecture may include instance (s) of NSF (s) of the lowest layer of the I2NSF user, Security Management System, and / or framework. For example, the security management system may include a security controller and a developer's management system. The security controller may include a Security Policy Manager and an NSF Capability Manager.

In addition, the present specification proposes a data model for performing a mission for a security service (eg, VoIP-VoLTE) in an I2NSF security management system.

The present invention has the following objects / effects.

User perspective High-level security management: To propose a design of a generic security management architecture to support flexible and efficient security policies in NSF.

Automatic update of security policies: To provide for the reflection of updated low-level security policies against new security attacks against the corresponding user-view security policies. User perspective security policy / management may be referred to as high-level security policy / management.

Terminologies that may be used herein are defined as follows.

Application Logic: A component of the security management architecture that creates a user perspective security policy for blocking or mitigating security attacks.

Policy Updater: A component that delivers a user perspective security policy to a security controller. User perspective policies are retrieved from the application logic.

Security Policy Manager: A component that maps a user perspective security policy received from a policy updater to a low level security policy and vice versa.

NSF Capability Manager: A component that stores NSF capabilities registered by the developer management system through a registration interface and shares them with the Security Policy Manager to create a corresponding low level security policy.

Event Collector: A component that receives events from a security controller, which is used to update (or create) a user perspective policy in application logic.

Network Security Function (NSF): Means a function or device for the specific handling of a received packet. The NSF may operate at various layers of various protocol stacks (eg, network layer or other Open System Interconnection (OSI) layer, etc.).

For example, as examples of NSFs, firewalls, intrusion prevention systems (IPS) / intrusion detection systems (IDS), deep packet inspection (DPI), application visibility and Application Visibility and Control (AVC), Network Virus and Malware Scanning, Sandbox, Data Loss Prevention (DLP), Distribute Denial of Service (DDoS) mitigation, A transport layer security (TLS) proxy, anti-spoofing, and the like may be included. The NSF according to an embodiment of the present invention may be implemented in any of the above-described examples, and various types of NSF may be used. In addition, multiple NSFs of the same type may be implemented. In addition, the NSF according to the present invention may be implemented by combining any one or more of the above-described examples.

## Hereinafter, the architecture / framework of the I2NSF system and the components of the I2NSF system will be described. In addition, the potential constraints on how I2NSF can limit the functionality of NFS, while facilitating the implementation of security features in a technology- and vendor-independent manner in Software-Defined Networking (SDN) and Network Function Virtualization (NFV) environments. Explain whether or not

The I2NSF framework allows users of an I2NSF system (e.g., an application, overlay or cloud network management system, or enterprise network administrator or management system) to inform the I2NFS system which I2NSF functions should be applied to which traffic (or traffic patterns). Requires a standard interface. The I2NSF system can recognize this standard interface as a set of security rules for monitoring and controlling the behavior of different traffic. The I2NSF framework also provides a standard interface for monitoring flow-based security functions where users are hosted and managed by different administrative domains.

1 illustrates an I2NSF (Interface to Network Security Functions) system according to an embodiment of the present invention.

1 is a basic architecture / framework of an I2NSF system, which is illustrated in terms of a network operator management system. Thus, FIG. 1 does not assume any particular management architecture for NSFs or how NSFs are managed (at the developer side). In particular, the network operations management system does not participate in NSF data plane activity. In general, all I2NSF interfaces may require at least mutual authentication and authorization for use.

Referring to FIG. 1, 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).

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. Hereinafter, each component (I2NSF component) and each interface (I2NSF interface) of the I2NSF system will be described.

I2NSF user

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. For example, 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 user perspective security policy for the security service he wants and notify the network operations management system.

On the other hand, in preparing the user perspective security policy, the I2NSF user considers the types of NSF (s) required to realize a security service or security policy rule configuration for each NSF (s). You can't.

In addition, the I2NSF user may be informed of security event (s) occurring in the underlying NSF (s) by the network operations management system. By analyzing their security event (s), I2NSF users can identify new attacks and update (or create) user perspective security policies to cope with the new attacks. As such, I2NSF users can define, manage, and monitor security policies.

Network operations management system

A network operations management system is a component that acts as a collection and distribution point for providing security, monitoring, and other operations. For example, 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.

One of the primary roles of network operations management systems (or security controllers) is to translate user perspective security policies (or policy rules) from I2NSF users into low-level security policy rules for specific NSF (s). It is. The network operations management system (or security controller) may receive the user perspective 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).

In addition, 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. In addition, 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

NSF is a logical entity or software component that provides security related services. For example, NFC (eg, a firewall) may receive a low level security policy, and may detect, block or mitigate malicious network traffic based thereon. In this way, the integrity and confidentiality of the network communication stream can be guaranteed.

Developer management system

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. User perspective security policies (or policy rules) created by I2NSF users may be communicated to the network operations management system via this CFI. In addition, security alerts by the NSF (s) may be communicated from the network operations management system to the I2NSF user via this CFI.

I2NSF NSF-Face Interface (Simply NSF-Face Interface (NFI))

NFI is an interface located between the network operations management system (or security controller) and the NSF (s).

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.). Thus, when setting security policy rules to the NSF, the network operations management system does not need to consider vendor specific differences and / or the form factor of the NSF. This NFI may be used to specify and monitor a flow-based security policy enforced by one or more NSFs. For example, the network operations management system may deliver a flow-based security policy to each flow-based NSF via an NFI interface in order to enforce a user perspective security policy by an I2NSF user. Here, 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.

As such, 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.

On the other hand, the I2NSF management system does not need to use all the functions of a given NSF, nor need to use all available NSFs. Thus, this abstraction allows NSF features to be treated as building blocks by the NSF system. Thus, developers are free to use the security features defined by NSF, which are vendor and technology independent.

I2NSF registration interface (simple 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).

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. .

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. In FIG. 2, descriptions overlapping with those described above in FIG. 1 will be omitted.

Referring to FIG. 2, 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. For example, 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 (CFI). The security management system layer also communicates with the NFC instance layer via the NSF-Directional Interface (NFI). For example, 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. In addition, 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 (RI).

The operation of the I2NSF system of FIG. 2 will be briefly described as follows. First, the application logic can create a user perspective policy and send it to the security policy manager via CFI. The security policy manager can map user perspective policies to multiple low-level policies at the security controller. After mapping, low level policy may be distributed to NSF (s) via NFI to be enforced at NSF (s). If an event occurs for the NSF to change the low level policy, the NSF may send an event to the security controller via the NFI. The security controller then forwards the event through the CFI to the event collector. Next, the event collector sends the event to the application logic. The application logic then updates the current policy according to the event. The operation of each component will be described in detail below.

Meanwhile, the I2NSF user layer of FIG. 2, 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 are respectively the I2NSF user component, network operation management system component, and developer management system component of FIG. 1. And an NSF component. In addition, 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. Hereinafter, newly defined components included in each layer will be described.

I2NSF user

As mentioned above, 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 a component that creates a user perspective security policy. To this end, the application logic receives an event for updating (or creating) a user perspective policy from an event collector and updates (or creates) a user perspective policy based on the collected event. After that, the user perspective policy is sent to the policy updater for distribution to the security controller. To update (or create) a user perspective policy, the event collector receives the events sent by the security collector and sends them to the application logic. Based on this feedback, application logic can update (or create) a user perspective security policy.

In FIG. 2, the application logic, the policy updater, and the event collector are shown in separate configurations, but are not limited thereto. In other words, each is a logical component, and may be implemented as one or a plurality of components in the I2NSF system. For example, it may be implemented by a single I2NSF user component as shown in FIG.

Security management system

As mentioned above, 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 user perspective 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.

In FIG. 2, the security policy manager and the NSF capability manager are illustrated in separate configurations, but are not limited thereto. In other words, each is a logical component, and may be implemented as one component in the I2NSF system.

NSF Instances

As shown in FIG. 2, the NSF instance layer includes NSFs. At this time, all NSFs are located in this NSF instance layer. On the other hand, after mapping the user perspective policy to the low level policy, the security policy manager forwards the policy to the NSF (s) via NFI. In this case, NFC can detect, block or mitigate malicious network traffic based on the received low level security policy.

## Hereinafter, the information and data model for I2NSF will be described. In particular, the information and data model (YANG data model) for the consumer-facing interface in the I2NSF system is described.

To this end, the basic concepts of the information model and data model are explained first.

Basically, the information model and data model can be used to define managed objects in network management. Despite the overlapped details, the information model and data model have different characteristics in terms of network management.

In general, the main purpose of an information model is to model managed objects at the conceptual level, without relying on any particular implementation or protocol. To clarify the overall design, the information model must hide all protocol and implementation details that define the relationships between managed objects. Based on this, the information model can be implemented in different ways and can be mapped to different protocols. As such, the information model is protocol neutral. In general, an information model may be defined in an exemplary manner, using a natural language such as English. In addition, it may be desirable to use an object-oriented technique to describe the information model.

In general, the data model is defined as a lower level of abstraction and provides many details. The data model provides details on the specifications of the implementation and protocols, such as rules describing how managed objects are mapped to low-level protocol constructs. Because conceptual models can be implemented in a variety of ways, multiple data models can be derived from a single information model.

On the other hand, the impressive role of NFV in network management leads to the rapid advent of NFV in this industry. As a practical application, NFS, such as a firewall, intrusion detection system (IDS), intrusion protection system (IPS), may also be provided as a virtual network function (VNF). With virtualization technology, this VNF can be automatically provided and dynamically migrated based on real-time security requirements.

This specification proposes an information model and a data model for implementing a security function based on NFV. In particular, this specification proposes an information model and data model for an I2NSF consumer-facing interface (CFI), based on the I2NSF framework described above in FIGS. 1 and 2. In other words, the present specification proposes an information model and a data model for a security service in the security management architecture so that the security management architecture described above can support a flexible and effective security policy.

3 illustrates a hairdressing model for a consumer-facing interface of an I2NSF system in accordance with an embodiment of the present invention. In the embodiment of FIG. 3, the I2NSF system has the architecture of the I2NSF system described above in FIG. 1 or 2.

The uniform model of the embodiment of FIG. 3 provides an information model for the consumer-facing interface towards the security controller based on the requirements of the consumer-facing interface. This information model defines the relationships between the various managed objects and those objects needed to build a consumer-facing interface. This information model can be organized based on the “Event-Condition-Action” (ECA) policy model. This ECA policy model may be defined by the capability information model for I2NSF. This capability information model (NSF capability model) corresponds to the security policy model of NSF-face interface and consumer-face interface.

As mentioned above, I2NSF provides a consumer-facing interface that conveys user perspective security policy to the security controller for security enforcement in NSF. This consumer-facing interface is created using a set of objects, each of which captures a unique set of information from the security manager (ie, I2NSF user) needed to express the security policy. An object can have relationships with various other objects that represent a complete set of requirements. The information model captures managed objects and the relationships between these objects. The information model proposed in this document follows the requirements of the consumer-facing interface. On the other hand, a data model, representing an implementation of the proposed information model of a particular data representation language, is described separately below.

Referring to FIG. 3, the policy model includes an event sub-model, a condition sub-model and an action sub-model. Each will be described below.

Information Model for Policy

A policy object represents a mechanism for expressing a security policy by a security administrator (eg, an I2NSF user) using a consumer-facing interface forward to the security controller. The policy will be implemented by the NSF. The policy object contains some or all of the following information (fields):

Name: This field identifies the name of the policy object.

Date: This field indicates the date on which the policy object was created or last modified.

Multi-Tenancy: Multi-tenancy environment information with a policy applied. Rules within a policy may refer to sub-objects (eg, domains, tenants, roles, and users). This field may be either a reference to a multi-tenancy object defined elsewhere or a concrete object.

End-Group: This field contains a list of logical entities in the business environment to which the security policy applies. This field may be referenced by condition objects (eg, source, destination, match) in the rule. This field may be either a reference to an end-group object or a concrete object defined elsewhere.

Threat-Feed: This field indicates the threat feed, such as Botnet server, GeoIP, and malware signature. This information (field) may be referenced by the rule action object to directly execute threat mitigation.

Telemetry-Data: This field indicates telemetry collection related information that the rule action object may refer to for collecting interest in telemetry information. For example, the telemetry collection related information may include what type of telemetry is collected, where the telemetry source is, where the telemetry information is transmitted, and the like.

Rule: This field contains a list of rules. If the rule does not have user-defined precedence, any conflict must be resolved manually.

Owner: This field defines the owner of this policy. Only the owner has the authority to modify the contents of the policy.

A policy, on the other hand, is a container of rules. To express a rule, the rule must have complete information such as where and when the policy will be applied. Rules are made by defining a set of managed objects and the relationships between them. Policy rules may relate to segmentation, threat mitigation, or the collection of telemetry data from NSFs in a network, which will be designated as a submodel of the policy model.

The rule object contains some or all of the following information (fields):

Name: This field identifies the name of the rule object.

Date: This field indicates the date on which the rule object was created or last modified.

Event: This field contains information that determines whether or not a rule condition can be evaluated.

Condition: This field contains all the checking conditions to apply to the objective traffic.

Action: This field identifies the action to be taken if a rule is matched. If no rule matches the traffic type, there is always an implicit action to drop the traffic.

Priority: This field identifies the priority assigned to this rule by the security administrator. This field helps in conflict resolution when two or more rules match a given traffic class.

Event sub-model

The event object contains information related to scheduling the rule. The rule may be activated based on a time calendar or security event that includes a threat level change.

The event object contains some or all of the following information (fields).

Name: This field identifies the name of the event-map-group object.

Date: This field indicates the date on which the event-map-group object was created or last modified.

Event-Type: This field identifies whether the event that triggers policy enforcement is "ADMIN-ENFORCED", "TIME-ENFORCED" or "EVENT-ENFORCED".

Time-Information: This field repeats the time calendar for periodic enforcement or "BEGIN-TIME" and "END-Time" for one time enforcement. TIME) ".

Event-Map-Group: This field contains a security event or threat map to determine when the policy needs to be activated. This may be a reference to an event-map-group object to be defined later.

Event-map-group

This object represents an event map containing threat levels and security events used for dynamic policy enforcement. The event-map-group object contains some or all of the following information (fields).

Name: This field identifies the name of the event-map-group object.

Date: This field indicates the date on which the event-map-group object was created or last modified.

Security-Events: This field contains a list of security events used for the purpose of Security Policy definition.

Threat-map: This field contains a list of threat levels used for security policy definition purposes.

Conditional Sub-Model

This object represents the condition that the security manager wants to apply checks on traffic to determine whether a set of actions in a rule can be executed or not.

The condition object contains some or all of the following information (fields).

Source: This field identifies the source of the traffic. This field may be a reference to one of the above-defined policy-endpoint-group, threat-feed or custom-list. This field may be a special object "all" that matches all traffic. This field may also be a telemetry-source for telemetry collection policy.

Destination: This field identifies the destination of the traffic. This may be a reference to one of the policy-endpoint-group, threat-feed, or custom-list defined above. This may be a special object "all" that matches all traffic. It may also be a telemetry-destination for the telemetry collection policy.

Match: This field identifies the matching criteria used to evaluate whether the specified action needs to be performed. This may be one of a set of policy-endpoint-groups or traffic rules that identify a set of applications.

Match-Direction: This field identifies the matching criteria used to evaluate whether the specified action needs to be done. This may be one of a set of policy-endpoint-groups or traffic rules that identify a set of applications.

Exception: This field identifies exception considerations when a rule is evaluated for a given communication. This may be a reference to a "policy-endpoint-group" object or a set of traffic matching criteria.

Behavioral Sub-Model

This object represents the action that the security manager wants to perform based on a particular traffic class.

The action object contains some or all of the following information (fields):

Name: This field identifies the name of the action object.

Date: This field indicates the date on which the action object was created or last modified.

Primary-Action: This field identifies the action when the rule is matched by the NSF. Primary-Operations are "PERMIT", "DENY", "MIRROR", "REDIRECT", "RATE-LIMIT", "TRAFFICCLASS" "," AUTHENTICATE-SESSION "," IPS "," APP-FIREWALL ", or" COLLECT ".

Secondary-Action: The security administrator can also specify additional actions if the rules match. The secondary-operation may be one of "LOG", "SYSLOG" or "SESSION-LOG".

Information model for multi-tenancy

Multi-tenancy is an important aspect of any application that enables multiple administrative domains to manage application resources. An enterprise organization can have multiple tenants and departments, such as human resources (HR), finance and legal departments, and each tenant needs to manage its own security policy. Has To service providers, tenants represent consumers who want to manage their own security policy.

There are multiple managed objects that make up the multi-tenancy aspect. The following lists these objects and their relationships.

Policy-Domain

This object defines a boundary within the security controller for policy management purposes. This object may vary depending on how the security controller is deployed and hosted. For example, if an enterprise hosts a security controller in their network, the domain may simply represent the enterprise. However, if a cloud service provider hosts a managed service, the domain may represent a single consumer of that provider. The multi-tenancy model can work in all these environments.

The policy-domain object contains some or all of the following information (fields):

Name: This field identifies the name of the organization or customer that the policy-domain represents.

Address: This field indicates the address of the organization or consumer.

Contact: This field indicates the contact information of the organization or consumer.

Date: This field indicates the date on which this account was created or last modified.

Authentication-Method: This field indicates the authentication method to be used for the policy-domain. This should be a reference to the 'Policy-Management-Authentication-Method' object.

Policy-Tenant

This object defines an entity within an organization. An entity can be a department or business unit within a corporate organization that wants to manage its own policy due to regulatory compliance or business reasons.

The policy-tenant object contains some or all of the following information (fields):

Name: This field identifies the name of the department or division within the organization.

Date: This field indicates the date on which this account was created or last modified.

Domain: This field identifies the domain to which the policy-tenant belongs. It must be a reference to a policy-domain object.

Policy-rule

This object defines a set of permissions assigned to a user in an organization who wants to manage their own security policy. This object provides a convenient way of assigning policy users a set of permissions or job functions within an organization.

The policy-rule object contains some or all of the following information (fields):

Name: This field identifies the name of the rule.

Date: This field indicates the date this rule was created or last modified.

Access-Profile: This field identifies the access profile for the role. Profiles may grant or deny access to a group of endpoints for policy management purposes, or restrict certain operations related to policy management.

Policy-User

This object represents a unique identity within an organization. Identity authenticates the security controller using credentials such as passwords or tokens to perform policy management. The user can be an individual, system or application that requires access to the security controller.

The policy-user object contains some or all of the following information (fields):

Name: This field identifies the user's name.

Date: This field indicates the date this user was created or last modified.

Email: This field indicates the user's email address.

Scope-Type: This field identifies whether the user has domain-wide or tenant-wide privileges.

Scope-Reference: This field must be a reference to either a policy-domain or a policy-tenant object.

Role: This field must be a reference to a policy-role object that defines a specific permission.

Policy-Management-Authentication-Method

This object represents the authentication schemes provided by the security controller.

This object contains some or all of the following information (fields):

Name: This field identifies the name of this object.

Date: This field indicates the date this object was created or last modified.

Authentication-Method: This field identifies the authentication method. This authentication method may be password-based, token-based, certificate-based or single sign-on authentication.

Mutual-Authentication: This field indicates whether mutual authentication is mandatory.

Token-Server: This field stores information about the server that validates the submitted token as a credential.

Certificate-Server: This field stores information about the server that validates the submitted certificate as a credential.

Single Sign-on-Server: This field stores information about the server that validates user credentials.

Information model for policy endpoint groups

Policy endpoint groups are an important part of creating user configuration-based policies. Security administrators create and use this object to represent logical entities in their business environment to which the security policy applies.

There are multiple managed objects that make up a group of policy endpoints. The following lists these objects and their relationships.

Tag-source

This object represents the source of information for the tag. Tags within a group must be mapped to corresponding contents in order to enforce the security policy.

The tag-source object contains some or all of the following information (fields):

Name: This field identifies the name of this object.

Date: This field indicates the date this object was created or last modified.

Tag-Type: This field identifies the endpoint group type. This may be a user-group, an app-group, a device-group, or a location-group.

Tag-Source-Server: This field identifies information related to the source of the tag, such as IP address and UDP / TCP port information.

Tag-Source-Application: This field identifies the protocol used to communicate with the server, such as LDAP, Active Directory, or CMDB.

Tag-Source-Credentials: This field identifies the credential information needed to access the server.

User-group

This object represents a group of users based on either tags or other information.

The user-group object contains some or all of the following information (fields):

Name: This field identifies the name of this object.

Date: This field indicates the date this object was created or last modified.

Group-Type: This field identifies whether the user group is based on User-tag, User-names or IP-address.

Metadata-Server: This field must be a reference to a metadata-source object.

Group-Member: This field is a list of user-tags, user-names or IP addresses based on group-type.

Risk-Level: This field indicates the importance or risk level of the endpoint to the security administrator for policy purposes. The valid range may be 0 to 9.

Device-group

This object represents a device group based on one of tags or other information.

The device group object contains some or all of the following information (fields):

Name: This field identifies the name of this object.

Date: This field indicates the date this object was created or last modified.

Group-Type: This field identifies whether the device group is based on Device-tag, Device-names or IP-address.

Tag-Server: This field must be a reference to a tag-source object.

Group-Member: This field is a list of device-tags, device-names or IP addresses based on group-type.

Risk-Level: This field indicates the importance or risk level of the endpoint to the security administrator for policy purposes. The valid range may be 0 to 9.

Application-group

This object represents a group of applications based on tags or other information.

The application-group object contains some or all of the following information (fields):

Name: This field identifies the name of this object.

Date: This field indicates the date this object was created or last modified.

Group-Type: This field identifies whether the device group is based on App-tag, App-names or IP-address.

Tag-Server: This field must be a reference to a tag-source object.

Group-Member: This field is a list of app-tags, app-names or IP addresses based on group-type.

Risk-Level: This field indicates the importance or risk level of the endpoint to the security administrator for policy purposes. The valid range may be 0 to 9.

Location-group

This object represents a group of locations based on either tags or other information.

The location-group object contains some or all of the following information (fields):

Name: This field identifies the name of this object.

Date: This field indicates the date this object was created or last modified.

Group-Type: This field identifies whether the device group is based on Location-tag, Location-names or IP-address.

Tag-Server: This field must be a reference to a tag-source object.

Group-Member: This field is a list of location-tags, location-names or IP addresses based on group-type.

Risk-Level: This field indicates the importance or risk level of the endpoint to the security administrator for policy purposes. The valid range may be 0 to 9.

Information Model for Threat Prevention

Threat protection plays an important role in overall security posture by reducing attack surfaces. This information may be provided in the form of threat feeds such as Botnet and GeoIP from third parties or external services.

There are multiple managed objects that make up this category. The following lists the relationships between these objects and these objects.

Threat-Feed

This object represents threat servers such as Botnet servers and GeoIP.

The threat-feed object contains some or all of the following information (fields):

Name: This field identifies the name of this object.

Date: This field indicates the date this object was created or last modified.

Feed-Type: This field identifies whether the feed type is IP address-based or URL-based.

Feed-Server: This field identifies information about the feed provider, which may be an external server or a local server.

Feed-Priority: This field indicates the feed priority level for resolving disputes when there are multiple feed sources. The valid range can be 0 to 9.

Custom-List

This object represents a custom list created for the purpose of defining exceptions to threat feeds. The organization may wish to allow certain exceptions to the list of threats obtained from third parties.

The custom-list object contains some or all of the following information (fields):

Name: This field identifies the name of this object.

Date: This field indicates the date this object was created or last modified.

List-Type: This field identifies whether the list type is IP address-based or URL-based.

List-Property: This field identifies a property of the list, such as a blacklist or whitelist.

List-Content: This field contains content such as an IP address or URL name.

Malware-Scan-Group

This object represents the information needed to detect malware. This information may be provided from a local server or periodically uploaded from a third party.

This object contains some or all of the following information (fields):

Name: This field identifies the name of this object.

Date: This field indicates the date this object was created or last modified.

Signature-Server: This field contains information about the server from which signatures can be downloaded periodically whenever an update is available.

File-Types: This field contains a list of file types needed to scan for viruses.

Malware-Signatures: This field contains a list of malware signatures or hash values.

Information model for telemetry data

Telemetry gives system administrators visibility of network activities that can be tapped for further security analysis, such as detecting potential vulnerabilities, malicious activities, and so on. provide visibility.

Telemetry-data

This object contains the information gathered for telemetry.

This object contains some or all of the following information (fields):

Name: This field identifies the name of this object.

Date: This field indicates the date this object was created or last modified.

Log-Data: This field identifies whether log data needs to be collected.

Syslog-Data: This field identifies whether Syslog data needs to be collected.

SNMP-Data: This field identifies whether SNMP trap and alarm data need to be collected.

sFlow-Record: This field identifies whether sFlow records need to be collected.

NetFlow-Record: This field identifies whether NetFlow records need to be collected.

NSF-Stats: This field identifies whether statistics need to be collected from the NSF dump.

Telemetry-source

This object contains information related to the telemetry source. The source will be NSF in the network.

This object contains some or all of the following information (fields):

Name: This field identifies the name of this object.

Date: This field indicates the date this object was created or last modified.

Source-Type: This field contains the type of NSF telemetry source: "NETWORK-NSF", "FIREWALL-NSF", "IDS-NSF", "IPSNSF", "PROXY-NSF or "OTHER-NSF".

NSF-Credentials: This field contains the user and password used to authenticate the NSF.

Collection-Interval: This field contains the time in milliseconds between each data collection. For example, a value of 5,000 means that data is streamed to the collector every 5 seconds. A value of zero means that data streaming is event-based.

Collection-Method: This field contains a collection method that is PUSH-based or PULL-based.

Heartbeat-Interval: This field contains the time in seconds that the source should transmit telemetry heartbeats.

QoS-Marking: This field contains the DSCP value source masked on the generated telemetry packet.

Telemetry-Destination

This object contains information related to the telemetry destination. The destination may be a collector that is part of an external system such as a security controller or SIEM.

This object contains some or all of the following information (fields):

Name: This field identifies the name of this object.

Date: This field indicates the date this object was created or last modified.

Collector-Source: This field contains information such as the IP address and protocol (UDP or TCP) port number for the destination of the collector.

Collector-Credentials: This field contains the username and password provided by the collector.

Data-Encoding: This field contains telemetry data encoding, which may be in schema form.

Data-Transport: This field contains a streaming telemetry data protocol, which may be a gRPC, a protocol buffer over UDP, or the like.

The information model described above provides a mechanism to protect the consumer-facing interface between the system administrator (eg, I2NSF user) and the security controller. One of the specific mechanisms can be used to protect corporate networks, data and all resources from external attackers. In addition, this information model specifies that the interface must have appropriate authentication and authorization with role-based access control in order to establish multi-tenancy requirements.

## Hereinafter, the data model for the consumer-facing interface of the I2NSF system will be described with reference to FIGS. 4 and 5. Specifically, the VoIP-VoLTE security service will be described as an example of the security service, and a comprehensive data model and a YANG data model for this VoIP-VoLTE security service will be described. First, security management for VoIP-VoLTE security service and VoIP-VoLTE security service will be described. Next, a comprehensive data model and a YANG data model for VoIP-VoLTE security services will be described.

VoIP-VoLTE Security Service

In the embodiment of Figures 4 and 5, VoIP-VoLTE security management is considered as an example of use for implementing the data model. Based on this, the security manager (VoIP-VoLTE security manager) acts as application logic for the VoIP-VoLTE security service and defines the security conditions. Based on the VoIP-VoLTE security management, the list of illegal device information may be stored in the VoIP-VoLTE database and updated manually or automatically by the VoIP-VoLTE security manager. To define a policy, information in the risk domain blacklist (eg IP address and source port), time management (eg access time and expiration time), user-agent (eg priority level) and illegal phone or authentication The SIP URI of a suspected Session Initiation Protocol (SIP) device may be published by the VoIP-VoLTE Security Manager. Thus, a list of illegal devices that are updated automatically (or manually) can be stored in the VoIP-VoLTE database. VoIP-VoLTE security managers can create new user-side security policies (e.g., block lists of illegal devices using IP addresses, source ports, etc.) to prevent the forwarding of packets to and from newly added VoIP-VoLTE attackers You can load the list periodically.

Security Management for VoIP-VoLTE Security Service

VoIP-VoLTE security management maintains and publishes IP addresses, blacklists of source ports, expiration times, user-agents, and SIP URIs of illegal phone or suspected SIP devices. In a comprehensive security management architecture, the VoIP-VoLTE security manager acts as the application logic for the VoIP-VoLTE security service of FIG.

Based on VoIP-VoLTE security management, the list of illegal device information can be updated manually or automatically by the VoIP-VoLTE security manager as application logic. In addition, the VoIP-VoLTE Security Manager creates new user perspective security policies and enforces low-level security policies in NSF to prevent the forwarding of packets to and from newly added VoIP-VoLTE attackers. The VoIP-VoLTE security manager sends the new user perspective security policy to the policy updater, which forwards it to the security controller.

When the NSF detects an abnormal message and a phone call delivered from the domain, domain information such as IP address, user-agent and expiration time value is sent by the NSF to the security controller via the NFI. The security controller passes it to the event collector. The event collector forwards the detected domain information to the VoIP-VoLTE security manager, which then updates the VoIP-VoLTE database.

VoIP VoLTE  Data for Security Service modelling (Data Modeling for VoIP-VoLTE Security Service)

4 illustrates a generic data model for a security service according to one embodiment of the invention. 4 illustrates a comprehensive data model, based on the information model for the consumer-facing interface of the I2NSF system of FIG. 3. In the embodiment of FIG. 4, the I2NSF system has the architecture of the I2NSF system described above in FIG. 1 or 2. In addition, in the embodiment of Fig. 4, it is assumed that the security service is the above-described VoIP-VoLTE security service. In FIG. 4, descriptions duplicated with those described above with reference to FIG. 3 will be omitted.

The data model for VoIP-VoLTE security service is derived from the I2NSF CFI Information Model. The main purpose of this data model is to completely transform this information model into a YANG data model that can be used to convey security policies to orchestrate control or management messages between components within the proposed security management architecture. will be.

The semantics of the data model require that the CFI's data model towards the security controller be aligned with the information model. That is, the meaning of each object / field of the data model for the CFI may correspond to the meaning of each object / field of the information model for the corresponding CFI. On the other hand, since the transformation of the information model for CFI is generally done by hand, certain changes must be made to reflect the fact that this is a YANG data model.

This data model is designed to support the I2NSF framework, which can be extended to meet security needs. In other words, model design is independent of the implementation and the content and semantics of a particular policy. 4 and 5, the VoIP / VoLTE security service is used as a use case of policy rule generation.

To implement this data model, the following three parameters are considered to define the user perspective policy: blacklisting countries, time interval specification and caller's priority levels.

If an administrator describes a new user perspective security policy, the I2NSF user's data model parser can interpret the policy and generate an XML file according to the YANG data model. In order to enable interaction between the I2NSF user and the security management system, a communication channel based on the RESCONF can be implemented. Basically, the data model is defined based on security policy requirements to detect suspicious phone numbers of VoIP / VoLTE services.

4 shows a comprehensive data model of VoIP / VoLTE security services. Referring to FIG. 4, the data model includes a policy (ieft-i2nsf-policy) node (field). The ieft-i2nsf-policy field contains a policy life cycle management (or policy life cycle) list (field), a policy rule list (field), and an action list (field). . In addition, the data model may further include an update list (field). Each field will be described below.

1) A policy-lifecycle-list specifies a set of expiration events and / or expiration times to determine the life of the policy itself. In an embodiment, the policy-lifecycle-list includes an expiration-event field and / or an expiration-time field. The expiration-event field may include event-id information identifying an expiration event and / or event-date information indicating a date when an event is generated. The expiration-time field may include time information indicating an expiration time.

2) A policy-rule-list represents specific information about the user perspective policy, such as service type, condition and valid time interval. In an embodiment, the policy-rule-list may include a policy-rule-container that includes at least one policy rule object. The policy-rule-container includes policy rule ID information (policy-rule-id), policy name information (policy-name), policy date information (policy-date), service information (service), and / or condition information (condition). It may include. Each information is described as follows.

The policy-rule-id information identifies a policy rule included in a policy rule container. The policy-name information identifies the name of the policy rule. The policy-date information indicates a date when a policy rule is created.

service information includes information on security services provided by NSF. For example, the service information may indicate a security service (eg, voip-handling or volte-handling service).

The condition information is identified by the condition ID information. In an embodiment, the condition information may include caller information, callee information and / or valid-time-interval. The caller information may include caller-id identifying the caller and / or caller-location indicating the caller's location (eg, country, city, etc.). The callee information may include callee ID information (callee-id) identifying a recipient and / or callee location information (callee-location) indicating a receiver's location (eg, country, city, etc.). The valid-time-interval information may include start time information indicating a start time of the policy and / or end time information indicating an end time of the policy.

3) The action-list specifies what action should be taken. For example, call traffic from a blacklisted caller location may be blocked at an abnormal time (included within a valid time interval) and both permit and mirror are assigned true. This phone traffic may be sequentially delivered to a predefined host for deep packet inspection (DPI).

In an embodiment, the action-list includes an action-container that includes at least one action object. The action-container may include an action date field (action-date) indicating a date when the action object is created and / or an action name field (action-name) indicating a name of the action object.

In an embodiment, the action-name field may include an action-name-ingress node (field) and an action-name-engress node (field) as a case node. In this case, the action-name-ingress field may indicate the name of the inflow action that is desired to be performed. Examples of this operation name may include a permit, a mirror, a log, and the like. In addition, the action-name field may include a redirection field. For example, the action-name-engress field may include a redirection field.

4) The update field (update-list) includes an update-container including at least one update object. Each update object may be identified by update ID information. As an embodiment, the update container includes an update event and / or an update time field indicating an update time. Each field is described as follows.

The update-event field contains update event ID information (update-event-id) that identifies the update event, update enable information that indicates whether the update is enabled, and update date for that update event. Update log information may include update event date information (update-event-date), and / or update log information including update log.

A security management system can be implemented to translate user perspective policies into a set of low level policies. After translating the user perspective security policy, the security management system creates a low level policy to specify the action from and / or to the IP address. The data model parser generates XML_le for the low level security policy and passes it to the appropriate NSF instance. The security management system also interprets security events generated by the NSF as user view log messages in the YANG data model and forwards them to the I2NSF user in the opposite direction.

In this case, a firewall application may be selected as the NSF instance to determine the caller's or receiver's location and call duration to determine whether the VoIP / VoLTE call is suspicious. If the phone has a suspicious behavior pattern, its network traffic can be efficiently blocked by the firewall application in accordance with a low level security policy. Results for firewall applications can be passed to the security management system through the RESTCONF protocol in the YANG data model. Depending on the particular situation, multiple NSF instances may be considered. For example, additional DPI can be used to analyze network traffic from suspicious calls.

YANG Data Model for VoIP / VoLTE Security Services

The following describes a YANG data model for VoIP / VoLTE security services, based on the CFI's information model towards a security controller.

5 illustrates a YANG data model for a security service according to an embodiment of the present invention. FIG. 5 illustrates the YANG data model, based on the information model for the consumer-facing interface of the I2NSF system of FIG. 3. In the embodiment of FIG. 5, the I2NSF system has the architecture of the I2NSF system described above in FIG. 1 or 2. In addition, in the embodiment of Fig. 5, it is assumed that the security service is the above-described VoIP-VoLET security service. In FIG. 5, descriptions duplicated with those described above with reference to FIGS. 3 and 4 will be omitted.

The information model described above with reference to FIG. 3 may be converted into a YANG data model as shown in FIG. 5 using a YANG data modeling language. In this case, the comprehensive data model of FIG. 4 may be used to convert the information model into a YANG data model.

Referring to FIG. 5, the YANG data model includes an ietf-i2nsf-consumer-facing-interface module, and the ietf-i2nsf-consumer-facing-interface module defines a YANG data module for a consumer-facing interface towards the security controller. do.

The YANG data model contains grouping policies. A policy is a grouping that contains a set of security rules according to certain logic, such as similarity or interrelationships. Network security policies can be applied to both one-way or two-way traffic across NSF.

1) The grouping policy may include a list policy-lifecycle including at least one policy lifecycle. Each policy lifecycle included in the list policy-lifecycle may be identified by a value of a policy-lifecycle-id field to be described later.

The list policy-lifecycle may include a policy-lifecycle-id node (field) as an entry node. In addition, the list policy-lifecycle may include an expiration event container and / or a container expiration-time. Here, the expiration event indicates an event that causes the policy to expire. The expiration time represents the time when the policy expires.

The policy-lifecycle-id field is a mandatory field and indicates an ID of a corresponding policy lifecycle. This ID must be unique.

In an embodiment, the container expiration-event leafs an enabled node (field), an event-id node (field) and / or an event-date node (field). Can be included as a node. The Enabled field is a mandatory field and indicates whether the policy is enabled or disabled. The event-id field is a mentor field and indicates an ID of an event. This ID must be unique. The event-date field is a mandatory field and indicates a date when an event is triggered.

As an embodiment, the container expiration-time may include an enabled node (field) and a time node (field) as leaf nodes. The Enabled field is a mandatory field and indicates whether the policy is enabled or disabled. The Time field is a mandatory field and indicates the time at which the policy is enabled.

2) The grouping policy may include a list policy-rule including at least one policy rule. Each policy rule included in the list policy-rule may be identified by a value of a policy-rule-id field. The policy-rule-id represents an ID of a policy rule. This is the key to the policy rule list. It must be unique.

list policy-rule leaves a policy-name node (field), a policy-rule-id node (field), and / or a policy-rule-date node (field). Can be included as a node. In addition, the list policy-rule may include a container service and / or a list condition.

The policy-name field is a mandatory field and may indicate the name of a policy. It must be unique. The policy-rule-date field is a mandatory field and may indicate a date and time at which a policy is created.

The container service represents a service that the NSF performs to manage security attacks. For example, a service may include voip-handling and volte-handling. This can be extended later.

The container service may include a voip-handling node (field) and a volte-handling node (field) as leaf nodes. The voip-handling field is a mandatory field and indicates whether the policy includes handling voip packet flows. The volte-handling field is a mandatory field that indicates whether the policy includes handling volte packet flows.

List conditions can be identified by condition IDs. The condition ID indicates the ID of the condition. It must be unique.

The list condition may include a caller container, a container callee, and / or a container valid-time-interval.

The container caller represents the caller of the VoIP-VoLTE call. The container caller may comprise a caller-id node (field) and / or a container caller-location. The caller-id field is a mandatory field and indicates the caller ID. It must be unique. container caller-location indicates the caller's location. The container caller-location may include country nodes (fields) and / or city nodes (fields) as leaf nodes. The Country field is a mandatory field and indicates the sender's country. The City field is a mandatory field and indicates the sender's city.

The container callee represents the recipient of the VoIP-VoLTE call. The container callee may include a callee-id node (field) and / or a container callee-location. The callee-id field is a mandatory field and indicates the ID of the receiver. It must be unique. container callee-location indicates the location of the receiver. The container callee-location may include country nodes (fields) and / or city nodes (fields) as leaf nodes. The Country field is a mandatory field and indicates the country of the receiver. The City field is a mandatory field and indicates the city of the receiver.

container valid-time-interval indicates the time at which the policy starts or ends validly. The container valid-time-interval may include a start-time node (field) and / or an end-time node (field) as leaf nodes. The start-time field is a mandatory field and indicates the time at which the policy is validly started. The end-time field indicates the time when the policy is to end effectively.

3) The grouping policy may include a container action. The container action may include an action-type node as a selection node. The action-type node is a network security function by which the flow-based NSF executes various actions, including at least ingress-action, egress-action, and advanced-action. To realize.

The action-type node may include an ingress-action node and / or an egress-type node as a case node.

The ingress-action field indicates that the inflow action consists of permit, mirror and / or log. Ingress-action nodes (fields) may include permit nodes (fields), mirror nodes (fields), and / or log nodes (fields) as leaf nodes. The permit field indicates that the packet flow is allowed or denied. The mirror node indicates that the packet flow is mirrored. The Log field indicates that packet flow is logged.

The egress-type node indicates that the egress behavior consists of redirection. An egress-type node may include a redirection node (field) as a leaf node. The redirection field indicates that the packet flow is redirected.

4) The grouping policy may include an update container. The container update contains events that cause the policy to expire. The container update may include an update-id node (field) and an update-event-id node (field) as leaf nodes. The update-id field represents a policy update ID for identifying each update. It must be unique. The update-event-id field represents an ID of an event. It must be unique. The update-event-id field may include an update-enabled node (field), an update-event-date node (field), and / or an update-event-date node (field). The update-enabled field indicates that the update is enabled or disabled. The update-event-date field represents a date when an update event is triggered. The update-event-date field contains information for logging the update and its description.

On the other hand, as described above, since the security management architecture is derived from the I2NSF framework, the security considerations of the I2NSF framework should also be included here. In particular, a suitable secure communication channel should be used for the transfer of control or management messages between components in the proposed architecture.

## Hereinafter, a data model and a YANG data model for a consumer-direct interface of a more generalized I2NSF system will be described with reference to FIGS. 6 to 8.

6 illustrates a generic data model for a security service according to another embodiment of the present invention. FIG. 6 illustrates a generic data model, based on the information model for the consumer-facing interface of the I2NSF system of FIG. 3. In the embodiment of FIG. 6, the I2NSF system has the architecture of the I2NSF system described above in FIG. 1 or 2. In the embodiment of FIG. 6, the security service may be various types of security services as well as the above-described VoIP-VoLTE security service. In FIG. 6, descriptions duplicated with those described above with reference to FIGS. 3 and 4 will be omitted.

Referring to FIG. 6, the data model may include a policy module (or a policy-general module). The policy-general module may include policy fields, multi-tenancy fields, end-group fields, threat-feed fields, and / or telemetry data. -data) field. As described above with reference to FIG. 3 for each field (information), detailed description thereof will be omitted.

1) The policy field may include a rule field identified by a rule ID. The rule field may include rule-id information, name information, date information, case information, event information, condition information, and / or policy-action information. Each information and sub information included in each information are described above with reference to FIG. 3, and thus a detailed description thereof will be omitted.

2) The multi-tenancy field is a policy-domain field identified by a policy-domain-id, a policy-role-id identified by a policy-role-id. role), the policy-user field identified by the policy-user-id, and / or the policy-mgnt-auth-method-id identified. It may include a policy-management-authentication-method field. Each field and the information included in each field will be omitted as described above with reference to FIG. 3.

3) The end-group field is identified by the metadata-source field identified by the metadata-source-id and the user-group-id. A user-group field, a device group identified by a device group ID (device-group-id), and an application group identified by an application group ID (application-group-id). location-group, identified by group and / or location-group-id. Each field and the information included in each field will be omitted as described above with reference to FIG. 3.

4) The threat-feed field includes threat feed information identified by the threat feed ID, custom list information identified by the custom list ID, and malware scan. By malware-scan-group event-map-group information identified by group-malware-scan-group-id, and / or by event-map-group-id It may include event-map-group information to be identified. Each information and sub-information included in each information have been described above with reference to FIG. 3, and thus a detailed description thereof will be omitted.

5) The telemetry-data field is identified by telemetry-data information identified by telemetry-data-id and telemetry-source-id. Telemetry-source information and / or telemetry-destination-identified by a telemetry-destination-id. Each information and sub-information included in each information have been described above with reference to FIG. 3, and thus a detailed description thereof will be omitted.

7 and 8 illustrate a YANG data model for a security service according to another embodiment of the invention. 7 and 8 illustrate a generalized YANG data model, based on the information model for the consumer-facing interface of the I2NSF system of FIG. 3. In the embodiment of FIG. 8, the I2NSF system has the architecture of the I2NSF system described above in FIG. 1 or 2. In addition, in the embodiments of FIGS. 7 and 8, the security service may be various kinds of security services as well as the above-described VoIP-VoLTE security service. In FIGS. 7 and 8, descriptions overlapping with those described above with reference to FIGS. 3, 4, and 6 will be omitted.

The information model described above with reference to FIG. 3 may be converted into a YANG data model as shown in FIGS. 7 to 8 using the YANG data modeling language. In this case, the comprehensive data model of FIG. 6 may be used to convert the information model into a YANG data model.

## Hereinafter, a data model and a YANG data model for a consumer-facing interface of an I2NSF system when the VoIP security service is applied to the generalized data model and the YANG data model described above with reference to FIGS. 6 to 8 will be described.

9 illustrates a generic data model for a security service according to another embodiment of the present invention. FIG. 9 illustrates a data model for a consumer-facing interface of an I2NSF system when VoIP security service is applied to the comprehensive data model of FIG. 6. In the embodiment of FIG. 9, the I2NSF system has the architecture of the I2NSF system described above in FIG. 1 or 2. In the embodiment of Figure 9, the security service may be the above-described VoIP security service. The objects / fields / information included in the comprehensive data model of FIG. 9 and the relationships therebetween may be described by the contents shown in FIG. 9 and the foregoing description. In FIG. 9, descriptions duplicated with those described above with reference to FIG. 6 will be omitted.

10 illustrates a YANG data model for a security service according to another embodiment of the present invention. FIG. 10 illustrates a YANG data model for a consumer-facing interface of an I2NSF system when the VoIP security service is applied to the generalized YANG data model of FIGS. 7 to 8. In the embodiment of FIG. 10, the I2NSF system has the architecture of the I2NSF system described above in FIG. 1 or 2. In addition, in the embodiment of FIG. 10, the security service may be the above-described VoIP security service. The objects / fields / information included in the YANG data model of FIG. 10 and the relationships therebetween may be described by the contents shown in FIG. 10 and the aforementioned contents. In FIG. 10, descriptions overlapping with those described above with reference to FIGS. 7 to 8 will be omitted.

11 illustrates XML output for a VoIP service according to one embodiment of the invention. In the embodiment of Fig. 11, it is assumed that a call received from a country having an IP of Africa classified as malicious is dropped. The elements / fields / information included in the YANG data model of FIG. 11 and the relationships therebetween may be described by the contents shown in FIG. 11 and the foregoing description. In FIG. 11, descriptions duplicated with those described above with reference to FIGS. 1 through 10 will be omitted.

Referring to FIG. 11, the policy message may include a <policy-voip> element for providing a VoIP policy. The <policy-voip> element may include as a sub element a <rule-voip> element that provides a VoIP policy rule. The <rule-voip> element is a <rule-voip-id> element, an <event-name> element, a <rule-voip-date> element indicating the date on which the VoIP rule was created, an <event> element, and a <condition> element. And / or <action> elements as sub-elements. Each element (field) and information included in each element (field) have been described above with reference to FIGS. 1 to 10.

12 illustrates a block diagram of a network device according to an embodiment of the present invention. The network device may correspond to the above-described I2NSF system or may be a device included in the I2NSF system. Examples of devices included in the I2NSF system may include the above-described I2NSF, security controller, developer management system, NSF, and the like.

Referring to FIG. 12, the network device 1200 includes a processor 1210, a memory 1220, and a communication module 1230.

The processor 1210 implements the functions, processes, and / or methods proposed in FIGS. 1 to 11. The memory 1220 is connected to the processor 1210 and stores various information for driving the processor 1210. The communication module 1230 is connected to the processor 1210 and transmits and / or receives a wired / wireless signal.

The memory 1220 may be inside or outside the processor 1210 and may be connected to the processor 1210 by various well-known means.

13 is a flowchart of a data communication method of a network device via a consumer-facing interface according to an embodiment of the present invention. In the embodiment of FIG. 13, the network device may be an I2NSF user (device) of FIG. 1 or 2.

Referring to FIG. 13, an I2NSF user device may encode security policy data for a security service. As an embodiment, the encoding of the security policy data may be performed using the YANG data modeling language (S1310).

The I2NSF user device may include transmitting the security policy data to the security controller through the consumer-facing interface (S1320).

In an embodiment, the security policy data may include a policy lifecycle field that includes the lifecycle of the security policy, a policy rule field that includes the rules of the security policy, and an action field that includes an action to be performed when the rules match. Can be.

In an embodiment, the policy lifecycle field may include policy lifecycle ID information identifying a policy lifecycle field, expiration event information indicating an event causing the security policy to expire, and expiration time information indicating a time when the security policy expires. It may include.

In an embodiment, the policy rule field may include policy rule ID information identifying a policy rule field, rule name information indicating a name of the rule, and policy date information indicating a date when a rule of the security policy is created. have.

As an embodiment, the policy rule field may further include service information indicating a service for performing a network security function (NSF) to manage a security attack.

In an embodiment, the policy rule field may further include condition information indicating an inspection condition to be applied to a packet or traffic by a network security function (NSF) for security inspection.

In an embodiment, the operation field may include inflow operation information indicating the configuration of the inflow operation and outflow operation information indicating the configuration of the outflow operation.

As an embodiment, the configuration of the inflow operation may include at least one of a permit, a mirror, or a log, and the configuration of the leakage operation may include redirection.

The embodiments described above are the components and features of the present invention are combined in a predetermined form. 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. In the case of a hardware implementation, 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.

In the case of implementation by firmware or software, an embodiment of the present invention may be implemented in the form of a module, procedure, function, etc. that performs the functions or operations described above. The software code may be stored in memory and driven by the processor. The memory may be located inside or outside the processor, and may exchange data with the processor by various known means.

It will be apparent to those skilled in the art that the present invention may be embodied in other specific forms without departing from the essential features of the present invention. Accordingly, the above detailed description should not be construed as limiting in all aspects and should be considered as illustrative. The scope of the invention should be determined by reasonable interpretation of the appended claims, and all changes within the equivalent scope of the invention are included in the scope of the invention.

The present invention can be applied to various systems for providing a security service.

Claims (16)

In the data communication method of the I2NSF user device, Encoding security policy data for the security service; And Passing the security policy data to a security controller via a consumer-facing interface, The security policy data, And a policy lifecycle field including a lifecycle of the security policy, a policy rule field including a rule of the security policy, and an action field including an action to be performed when the rule is matched. The method of claim 1, The policy life cycle field is Policy lifecycle ID information identifying the policy lifecycle field, expiration event information indicating an event that causes the security policy to expire, and expiration time information indicating a time when the security policy expires. The method of claim 1, The policy rule field is Policy rule ID information identifying the policy rule field, rule name information indicating a name of the rule, and policy date information indicating a date when a rule of the security policy is created. The method of claim 3, The policy rule field is And service information indicative of a service for which a network security function (NSF) performs management of a security attack. The method of claim 3, The policy rule field is Further comprising condition information indicating an inspection condition to be applied by the network security function (NSF) to the packet or traffic for security inspection. The method of claim 1, The operation field is, A data communication method comprising inflow operation information indicating a configuration of an inflow operation and outflow operation information indicating a configuration of an outflow operation. The method of claim 6, The configuration of the inflow operation includes at least one of a permit, a mirror or a log, The configuration of the leakage operation includes redirection. The method of claim 1, Encoding of the security policy data is performed using a YANG data modeling language. In an I2NSF user device, A communication module for communicating data; And A processor for controlling the communication module, The processor, Encode security policy data for the security service; And Delivering the security policy data to a security controller through a consumer-facing interface, The security policy data, A policy lifecycle field including a lifecycle of the security policy, a policy rule field including a rule of the security policy, and an action field including an action to be performed when the rule is matched. The method of claim 9, The policy life cycle field is Policy lifecycle ID information identifying the policy lifecycle field, expiration event information indicating an event that causes the security policy to expire, and expiration time information indicating when the security policy expires. The method of claim 9, The policy rule field is Policy rule ID information identifying the policy rule field, rule name information indicating a name of the rule, and policy date information indicating a date when a rule of the security policy is created. The method of claim 11, The policy rule field is Further comprising service information indicative of a service for which a network security function (NSF) performs management of a security attack. The method of claim 11, The policy rule field is I2NSF user device further comprising condition information indicating an inspection condition to be applied by the network security function (NSF) to the packet or traffic for security inspection. The method of claim 9, The operation field is, I2NSF user device comprising inflow operation information indicating the configuration of the inflow operation and outflow operation information indicating the configuration of the outflow operation. The method of claim 14, The configuration of the inflow operation includes at least one of a permit, a mirror or a log, The configuration of the leak action includes a redirection. The method of claim 9, The encoding of the security policy data is performed using a YANG data modeling language.

Images