KR20200045400A - Security Policy Translation in Interface to Network Security Functions - Google Patents

Abstract

The present invention relates to a method for translating a security policy of a policy translator for a network security function interface. The method includes: a step of receiving a first security policy of a high level from an interface to network security functions (I2NSF) user; a step of extracting data related to the first security policy based on the first security policy; a step of converting the data related to the first security policy into essential data for a network security function (NSF); and a step of searching for a target NSF based on the essential data and generating a second security policy of a low level related to the target NSF. The policy translator and the I2NSF user are connected by a user-facing interface and the policy translator and the NSF are capable of translating a security policy connected by an NSF-facing interface.

Description

Security Policy Translation in Interface to Network Security Functions

This specification relates to security policy translation, and more specifically, proposes a model of security policy translation in Interface to Network Security Functions (I2NSF).

Connecting the network around the world provides quick access to information regardless of geographic distance. The Internet is essentially a number of networks with different levels of hierarchy.

The Internet operates according to the Transmission Control Protocol / Internet Protocol (TCP / IP) published by the Internet Engineering Task Force (IETF), and TCP / IP can be found in Request For Comments (RFC) 703 and RFC 791 issued by the IETF. .

For the purposes of this specification, I2NSF (Interface to Network Security Functions) proposes a model of security policy translation.

In addition, this specification proposes a method for translating a high-level security policy including abstract data into a low-level security policy that can be used by Network Security Funtion (NSF).

The technical problems to be achieved in the present specification are not limited to the technical problems mentioned above, and other technical problems not mentioned will be clearly understood by a person having ordinary knowledge in the technical field to which this specification belongs from the following description. Will be able to.

An aspect of the present specification, in a method for translating a security policy of a policy translator for an interface to a network security function, includes a high-level first from an interface to network security functions (I2NSF) user Receiving a security policy; Extracting data related to the first security policy based on the first security policy; Converting data related to the first security policy into essential data for a network security function (NSF); And based on the essential data, searching for a target NSF and generating a low-level second security policy associated with the target NSF. Including, but the policy translator and the I2NSF user is connected to the user-facing interface, the policy translator and the NSF can translate the security policy connected to the NSF-facing interface.

In addition, generating data related to the second security policy; Further comprising, the data related to the second security policy includes a structure or content for the target NSF, and may be grouped through tags.

In addition, passing data related to the second security policy to the target NSF through the NSF-facing interface; It may further include.

In addition, based on the data associated with the second security policy, setting the target NSF; It may further include.

Also, the second security policy may include applied policy rules and basic operation information indicating operations for general security functions.

In addition, the policy rule includes policy information and rule information, wherein the policy information and the rule information include an event clause indicating a change of the system, a condition clause indicating an application condition of the policy rule, and An action clause indicating a security function performed when the event clause and the condition clause are satisfied may be included.

In addition, a step of extracting data related to the first security policy may be used Deterministic Finite Automation (DFA).

In addition, the step of converting the required data may be performed through mapping with data of the NSF database using an NSF database.

In addition, the target NSF may have the capability to cover all of the first security policy.

In addition, the policy translator can register all the functions of the NSF.

Another aspect of the present invention, in the policy translator (Policy Translator) for translating the security policy for the network security function interface, received from an Interface to Network Security Functions (I2NSF) user, high-level (High-Level) An extractor extracting data related to the first security policy based on a first security policy; A data converter for converting data related to the first security policy into essential data for a network security function (NSF); And a generator that searches for a target NSF based on the essential data and generates a low-level second security policy associated with the target NSF. Including, but the policy translator and the I2NSF user is connected to the user-facing interface, the policy translator and the NSF may be connected to the NSF-facing interface.

According to an embodiment of the present specification, a model for security policy translation may be designed in the Interface to Network Security Functions (I2NSF).

Further, according to an embodiment of the present specification, the present specification may translate a high-level security policy into a low-level security policy that can be used by a Network Security Funtion (NSF).

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

Included as part of the detailed description to aid understanding of the present specification, the accompanying drawings provide embodiments of the present specification and describe the technical features of the present specification together with the detailed description.
1 illustrates an I2NSF (Interface to Network Security Functions) system according to an embodiment of the present specification.
Figure 2 illustrates the architecture of the I2NSF system according to an embodiment of the present specification.
3 shows an example of a design of an entire I2NSF information model to which the present specification can be applied.
4 shows an example of an overview of a network security information sub-model to which the present specification can be applied.
5 shows an example of an extension of a network security information sub-model to which the present specification can be applied.
6 shows an example of an extension of a network security information sub-model event class to which the present specification can be applied.
7 shows an example of extension of a network security information sub-model condition class to which the present specification can be applied.
8 shows an example of an extension of a network security information sub-model action to which the present specification can be applied.
9 shows an example of a high-level model of the I2NSF security function to which the present specification can be applied.
10 shows an example of a network security function information model to which the present specification can be applied.
11 shows an example of an attack mitigation function information model to which the present specification can be applied.
12 illustrates a data model structure for network security policy identification according to an embodiment of the present specification.
13 illustrates a data model structure for event rules according to an embodiment of the present specification.
14A to 14D illustrate a data model structure for a condition rule according to an embodiment of the present specification.
15 illustrates a data model structure for an action rule according to an embodiment of the present specification.
16A to 18J illustrate a YANG data module of an I2NSF NSF-Facing Interface according to an embodiment of the present specification.
19A to 19J illustrate a data model for NSF monitoring according to an embodiment of the present specification.
20A to 21I illustrate a YANG data model for monitoring according to an embodiment of the present specification.
22 is an illustration of a high level extraction for a consumer-facing interface in which the present specification can operate.
22A to 22D are examples of a data model of a security policy for a consumer-facing interface according to an embodiment of the present specification.
23 is an illustration of a YANG data model for a security policy of a consumer-facing interface according to an embodiment of the present specification.
24 and 25 are examples of security policies to which the present specification can be applied.
26 is an example of a procedure for applying a policy to which the present specification can be applied.
27 is an example of a security policy translator model to which the present specification can be applied.
28 is a flowchart for security policy translation of a security policy translator to which the present specification can be applied.
29 is an example of an extractor model to which the present specification can be applied.
30 is an example of a data converter model that can be applied to the present specification.
31 is an example of policy provisioning to which the present specification can be applied.
32 is an example of a tree structure based on the NSF-face interface YANG data model to which the present specification can be applied.

Hereinafter, preferred embodiments according to the present specification will be described in detail with reference to the accompanying drawings. DETAILED DESCRIPTION The following detailed description, together with the accompanying drawings, is intended to describe exemplary embodiments of the present specification, and is not intended to represent the only embodiments in which the present specification may be practiced. The following detailed description includes specific details to provide a thorough understanding of the specification. However, one of ordinary skill in the art knows that the present specification may be practiced without these specific details.

In some cases, in order to avoid obscuring the concept of the present specification, well-known structures and devices may be omitted, or block diagrams centered on core functions of each structure and device may be illustrated.

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

Recently, a basic standard interface for Network Functions Virtualization (NFV) -based Security Function has been developed by the Interface to Network Security Functions (I2NSF) working group. It is part of an international Internet standards body called the Internet Engineering Task Force (IETF).

The purpose of I2NSF is to define a standardized interface for heterogeneous network security function (NSF) provided by multiple security solution vendors.

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

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

Referring to FIG. 1, the I2NSF system includes an I2NSF user, a network operator management system, a developer's management system (DMS), and / or at least one network security function (NSF). Includes.

The I2NSF user communicates with the network operation management system through the I2NSF Consumer-Facing Interface. The network operation management system communicates with the NFC (s) through the I2NSF NSF-Facing Interface. The developer management system communicates with the network operation 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 users

I2NSF users are I2NSF components that request information from other I2NSF components (e.g., network operations management systems) and / or use services (e.g., network security services) provided by other I2NSF components (e.g., developer management systems). . For example, the I2NSF user may be an overlay network management system, corporate network manager system, other network domain manager, or the like.

An object performing a role assigned to the I2NSF user component may be referred to as an I2NSF consumer. An example of an I2NSF consumer is the need to dynamically inform the Underlay Network to allow, rate-limit, or reject flows based on certain fields of the packet over a time span. Video-conference network managers, 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 an underlay network to block flows matching a set of specific conditions.

I2NSF users can create and deploy high-level security policies. Specifically, an I2NSF user needs to use a network security service to protect network traffic from various malicious attacks. To request this security service, the I2NSF user can create a high-level security policy for the security service he wants and inform the network operation management system.

On the other hand, in the process of preparing the high-level security policy, the I2NSF user does not consider the type of NSF (s) required to realize the security service or security policy rule configuration for each NSF (s). It may not.

In addition, the I2NSF user can be notified of security event (s) occurring within the underlying NSF (s) by the network operation management system. By analyzing their security event (s), I2NSF users can identify new attacks and update (or create) high-level security policies to counter new attacks. As such, I2NSF users can define, manage and monitor security policies.

Network operation management system

The network operation management system is a component that serves as a collection and distribution point for security provision, monitoring, and other operations. For example, the network operation management system may be a security controller. Such a network operation management system may be managed by a network security manager, or may be referred to as an I2NSF management system.

One of the main roles of the network operations management system (or security controller) is to translate high-level security policies (or policy rules) from I2NSF users into low-level security policy rules for specific NSF (s). will be. After receiving the high-level security policy from the I2NSF user, the network operation management system (or security controller) may first determine the type of NSF (s) required to enforce the policy required by the I2NSF user. And, the network operation management system (or security controller) may generate a low-level (Low-level) security policy for each NSF (s) required. As a result, the network operation management system (or security controller) can set the generated low-level security policy to each NSF (s).

In addition, the network operation management system (or security controller) monitors the running NSF (s) in the system, and various information about each NSF (s) (eg, network access information and workload) State, etc.). In addition, the network operation management system (or security controller) can dynamically manage a pool of NSF instances through dynamic life-cycle management of NSF instances with the help of a developer management system. have.

NSF

NSF is a logical entity or software component that provides security-related services. For example, NFC can receive low-level security policies, detect malicious network traffic based on it, and block or mitigate it. Through this, the integrity and confidentiality of the network communication stream can be ensured.

Developer management system

The developer management system is an I2NSF component that sends information to other I2NSF components (eg, I2NSF users, network operations management systems), and / or provides services (eg, network security services). The developer management system may also be referred to as a Vendor's Management System. An object performing a role assigned to the developer management system may be referred to as an I2NSF producer.

The developer management system may be managed by a third-party security vendor providing NSF (s) to the network operation management system. There may be multiple developer management system (s) from various security vendors.

I2NSF consumer-facing interface (simply, consumer-facing interface (CFI))

The CFI is the user's interface to the I2NSF system, located between the I2NSF user and the network operation management system. By being designed in this way, it hides the details of the underlying NSF (s) and provides the user with only an abstract view of the NSF (s).

This CFI can be used to enable different users of a given I2NSF system to define, manage and monitor security policies for specific flows in the management domain. High-level security policies (or policy rules) created by I2NSF users can be delivered to the network operations management system via this CFI.

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

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

NFI can be used to specify and monitor flow-based security policies enforced by one or more NSFs. For example, the I2NSF system can use flow-based NSF. Here, the flow-based NSF is an NSF that checks network flow according to a set of policies to enhance security characteristics. The flow-based security by the flow-based NSF means that the packets are inspected in the order received, and there is no modification to the packets according to the inspection process. Interfaces to flow-based NSF can be classified as follows:

-NSF Operational and Administrative Interface: a group of interfaces used by the I2NSF management system to program the operating state of the NSF; This interface group also includes management control functions. The I2NSF policy rule represents one way to change this interface group in a consistent way. Since the application and I2NSF components need to dynamically control the behavior of the traffic they send and receive, most of the I2NSF effort is focused on this interface group.

-Monitoring Interface: a 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 information, whereas the report-based interface is used by NSF to provide information. The functionality of this interface group can also be defined by other protocols such as SYSLOG and DOTS. The I2NSF management system can take one or more actions based on the reception of information. It must be specified by I2NSF policy rules. This interface group does not change the operational status of the NSF.

As such, NFI can be developed using a flow-based paradigm. The 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 operation of the I2NSF system.

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

I2NSF registration interface (simply, registration interface (RI))

RI is an interface located between a network operation management system and a developer management system. NSFs provided by different vendors may have different capabilities. Thus, in order to automate the process of using different types of security functions provided by different vendors, it is necessary for vendors to have dedicated interfaces for defining the functionality of their NSFs. Such a dedicated interface may be referred to as an I2NSF registration interface (RI).

The functionality of the NSF can be pre-configured or dynamically retrieved through the I2NSF registration interface. If new features exposed to consumers are added to the NSF, the capabilities of the new features need to be registered in the I2NSF registry through the I2NSF registration interface so that interested management and control entities can know them. have.

2 illustrates the architecture of an I2NSF system according to one embodiment of the present specification. The I2NSF system of FIG. 2 shows the configuration of the I2NSF user and network operation management system in more detail than the I2NSF system of FIG. 1. In FIG. 2, descriptions overlapping with the descriptions in FIG. 1 are 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 through a consumer-facing interface. For example, the policy updater and event collector of the I2NSF user layer communicates with the security controller of the security management system layer through a consumer-facing interface. In addition, the security management system layer communicates with the NSF instance layer through the NSF-facing interface. For example, the security controller of the security management system layer communicates with the NSF instance (s) of the NSF instance layer via the NSF-facing 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.

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 the I2NSF user component, the network operation management system component, the developer management system component, and the NSF of FIG. 1, respectively. Corresponds to the component. In addition, the consumer-facing interface, NSF-facing interface and registration interface of FIG. 2 correspond to the consumer-facing interface, NSF-facing interface and registration interface of FIG. 1. Hereinafter, newly defined components included in each layer will be described.

I2NSF users

As described above, the I2NSF user layer includes the following three components: Application Logic, Policy Updater, and Event Collector. Each role and operation are as follows.

Application logic is a component that creates high-level security policies. To this end, the application logic receives an event for updating (or generating) a high level policy from the event collector, and updates (or creates) a high level policy based on the collected event. After that, the high-level policy is sent to the policy updater for distribution to the security controller. To update (or create) high-level policies, the event collector receives events sent by the security collector and sends them to the application logic. Based on this feedback, the application logic can update (or create) a high level security policy.

In FIG. 2, the application logic, the policy updater, and the event collector are respectively illustrated in separate configurations, but are not limited thereto. In other words, each is a logical component, and may be implemented as one or two components in an I2NSF system.

Security management system

As described above, the security controller of the security management system layer includes two components such as a security policy manager and an NSF capability manager.

Security policy managers can receive high-level policies from the policy updater through the CFI and map them to several low-level policies. This low-level policy relates to a given NSF function registered with the NSF function manager. In addition, the security policy manager may forward this policy to the NSF (s) via NFI.

The NSF function manager can specify the functions of the NSF registered by the developer management system and share it with the security policy manager to create a low-level policy related to a given NSF function. Whenever a new NSF is registered, the NSF function manager can request the developer management system to register the NSF function in the NSF function manager's management table through the registration interface. The developer management system is the other part of the security management system for registering new NSF functions as NSF function managers.

In FIG. 2, the security policy manager and the NSF function manager are respectively 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 Figure 2, the NSF instance layer includes NSFs. At this time, all NSFs are located in this NSF instance layer. Meanwhile, after mapping the high-level policy to the low-level policy, the security policy manager delivers the policy to the NSF (s) through the NFI. In this case, the NSF can detect malicious network traffic based on the received low-level security policy and block or mitigate it.

Rapid development of virtualized systems requires advanced security features in a variety of scenarios (for example, network devices in an enterprise network, user equipment in a mobile network, devices in the Internet, or resident access users).

NSF, produced by multiple security vendors, can provide a variety of security features to customers. That is, NSF can provide security services for a given network traffic by combining several NSFs regardless of whether they are implemented as physical or virtual functions.

Security function refers to a function related to security of a series of networks that can be used for the purpose of enforcing security policies. The security function is independent of the actual security control mechanism implemented, and all NSFs are registered with a set of functions that the NSF can provide.

The security capability provides a capability specification that can define custom security protection by unambiguously describing the security functions provided by a specific NSF. In addition, the security function can be described in a vendor-neutral way of the security function.

That is, when designing a network, it is not necessary to mention a specific product, and features may be considered for each function.

As described above, there are two types of I2NSF interfaces that can be used to provide security policies.

I2NSF Interface between user and application and security controller (Consumer-Facing Interface): A consumer-oriented interface that provides a communication channel between NSF data and service users and a network operation management system (or security controller).

The I2NSF Consumer-Facing Interface can be used to exchange security information between various security applications (eg OpenStack or various BSS / OSS components) and security controllers. The design goal of the Consumer-Facing Interface is to separate the specification of the security service from the implementation.

-Interfaces between NSFs (e.g. firewall, intrusion prevention or anti-virus) and security controllers (NSF-Facing Interface): NSF-Facing Interface is used to separate the security management scheme from the NSF set and various implementations, and implemented by NSF It is independent in the way (eg: virtual machine or real appliances).

Hereinafter, an object-oriented information model for network security, content security, and attack mitigation functions together with associated I2NSF policy objects will be described.

In this specification, terms used in the information model may be defined as follows.

AAA: Access control, Authorization, Authentication

ACL: Access Control List

(D) DoD: (Distributed) Denial of Service (attack)

ECA: Event-Condition-Action

FMR: First Matching Rule (resolution strategy)

FW: Firewall

GNSF: Generic Network Security Function

HTTP: HyperText Transfer Protocol

I2NSF: Interface to Network Security Functions

IPS: Intrusion Prevention System

LMR: Last Matching Rule (resolution strategy)

MIME: Multipurpose Internet Mail Extensions

NAT: Network Address Translation

NSF: Network Security Function

RPC: Remote Procedure Call

SMA: String Matching Algorithm

URL: Uniform Resource Locator

VPN: Virtual Private Network

Information Model Design

The starting point of the design of the Capability Information Model is to classify the types of security functions. For example, classifying the types of security functions such as "IPS", "anti-virus" and "VPN concentrator".

Alternatively, the "packet filter" may be classified as a storage device that can allow or deny packet delivery according to various conditions (for example: source and destination IP addresses, source and destination ports, and IP protocol type fields, etc.).

However, more information is needed for other devices such as stateful firewalls or application layer filters. These devices filter packets or communications, but differ in the state of categorizing and maintaining packets and communications.

Analog considerations can be considered in channel protection protocols. Here, the channel protection protocols can protect packets through a symmetric algorithm that can be negotiated with an asymmetric cipher, and can operate at different layers and support different algorithms and protocols.

For secure protection, these protocols should be subject to integrity, optionally confidentiality, anti-reply protection and peer authentication.

Capability Information Model Overview

The functional information model defines a security functional model that provides the basis for the automatic management of the NSF. The functional information model also includes allowing the security controller to properly identify and manage the NSF, and to allow NSF to properly declare the features to be used in the right way.

Here are some basic design principles for security and the systems that need to manage them.

-Independence: Each security function should be an independent function with minimal overlap or dependency on other functions. Through this, each security function can be freely used and combined. More importantly, changes to one function do not affect the other.

It follows the Single Responsibility Principle [Martin] [OODSRP].

-Abstraction: Each function should be defined in a vendor-independent manner and should be connected to a well-known interface to provide a standardized function to describe and report processing results. Thus, interoperability with multiple supply vendors can be improved.

-Automation: The system should be able to auto-discover, auto-negotiate and auto-update security functions (ie, without user intervention). This automation capability is especially useful for managing multiple NSFs.

It is essential to add smart services (eg: analysis, refinement, functional inference and optimization) to the adopted security system. These features are supported by many design patterns such as Observer Pattern [OODOP], Mediator Pattern [OODMP] and Message Exchange Patterns [Hohpe].

-Scalability: Management system should have scale up / down or scale in / out function. Therefore, due to this scalability, it is possible to meet various performance requirements derived from changeable network traffic or service requests. In addition, security features affected by scalability can help determine whether scaling calls must be made to support statistical reporting to the security controller.

Based on the above principles, a set of abstract and vendor neutral functions with standard interfaces can be defined. It provides a Capability model that allows you to use the set of NSFs you need at any given time, and an unambiguous definition of the security provided by the NSF set used.

The security controller compares the user and application requirements to the currently available feature set and selects the NSF required to meet those requirements.

 In addition, when threats unknown by NSF (eg, zero-day exploits and unknown malware) are reported, new features may be created and / or existing features may be updated (eg, their By updating signatures and algorithms). As a result, existing NSFs are strengthened (and / or new NSFs are created) to counter new threats.

The new functionality can be sent and stored in a central repository or individually stored in the vendor's local repository. In both cases, the standard interface makes the update process easy.

ECA Policy Model Overview

The "Event-Condition-Action" (ECA) policy model is used as the basis for the design of I2NSF policy rules. At this time, terms related to the I2NSF policy may be defined as follows (see [I-D.draft-ietf-i2nsf-terminology]):

-Events: Events occur when a managed system changes and / or at an important point in the managed system's environment. The event can be used to determine whether the condition clause of the I2NSF policy rule can be evaluated when used in the context of the I2NSF policy rule. Examples of I2NSF events may include time and user actions (eg: logon, log off and ACL violations).

-Condition: A condition is defined as a set of attributes, functions, and / or values to be compared to a set of known attributes, features, and / or values, and may or may not enforce its (imperative) I2NSF policy rules. Examples of I2NSF conditions may include comparing the matching attributes of a packet or flow to the desired state of the NSF's internal state.

-Action: Action is used to control and monitor aspects of the flow-based NSF when the event and condition clauses are met. NSF provides security by executing various actions. Examples of I2NSF operations may include intrusion detection and / or protection, web and flow filtering, and providing deep packet inspection for packets and flows.

The I2NSF policy rule consists of three Boolean clauses: Event clause, Condition clause, and Action clause.

A Boolean clause means a logical statement that evaluates to TRUE or FALSE, and can consist of one or more terms.

If there is more than one term, the Boolean clause uses logical linking elements (that is, AND, OR, and NOT) to link the terms. At this time, the logical connection element may have the meaning shown in Table 1 below.

Technically, the "policy rule" can actually act as a container that aggregates the "events", "actions" and "conditions" described above, as well as metadata.

The ECA policy model described above is very generic and easily extensible and avoids potential constraints that may limit the implementation of common security features.

Relationship with external information models

3 shows an example of a design of an entire I2NSF information model to which the present specification can be applied.

I2NSF NSF-Facing Interface selects and manages NSF using the functions of NSF, which is performed using the following approach.

1) Each NSF registers a function in the management system when "joining", so the function can be used in the management system.

2) The security controller selects the set of functions needed to meet the requirements of the security service from all available NSFs it manages.

3) The security controller uses the Capability information model to match selected functions to a vendor-independent NSF.

4) The security controller manages the NSF by taking the above information and creating or using one or more data models of the functional information model.

5) Control and monitoring can be started.

This approach can assume that the external information model is used to define the concept of ECA policy rules and their components (eg: events, conditions and action objects, etc.). This allows I2NSF policy rules to be subclassed from external information models (see I-D.draft-ietf-i2nsf-terminology).

In the present specification, the data model represents the concept of interest in the environment in a format dependent on the storage of data, data definition language, query language, implementation language, and protocol.

In addition, the information model represents the concept of interest in the environment in a form independent of data storage, data definition language, query language, implementation language, and protocol.

Functions can be defined as classes (for example: a set of objects representing a common set of properties and behaviors) (see I-D.draft-ietf-supa-generic-policy-info-model).

Each function can consist of one or more model elements (eg: attributes, methods or relationships) that are distinct from all other objects in the system. A function is usually some kind of metadata (ie information describing and / or prescribing the behavior of an object).

Thus, each function can be used by the external information model to define the metadata (the form of class hierarchy is preferred). Accordingly, functions can be classified as subclasses in the external metadata model.

The functional sub-model is used to advertise, create, select and manage a specific set of security features that are independent of the vendor and type of device containing the NSF.

That is, users of the NSF-Facing Interface do not consider whether NFC is virtualized or hosted, who the NSF provider is, and the set of entities (eg firewall or IPS) with which the NSF communicates.

Instead, the user only considers a set of features, such as packet filtering or deep packet inspection, that NSF has.

The design of the entire ISNSF information model is shown in FIG. 3.

All of the external models shown in FIG. 3 may be based on the SUPA information model (see I-D.draft-ietf-supa-generic-policy-info-model). The class of the functional sub-model inherits the set of metadata aggregation (AggregatesMetadata) from the external metadata information model.

The external ECA information model shown in FIG. 3 provides a minimum set of classes representing general ECA policy rules and a set of classes representing events, conditions and actions that can be aggregated by general ECA policy rules.

Through this, I2NSF can reuse these general models for other purposes as well as create new subclasses or add properties and relationships to express I2NSF related concepts.

In this specification, it is assumed that the external ECA information model has a function of collecting metadata. The functions can be categorized as subclasses from the appropriate class of the external metadata information model.

This allows the ECA entity to add metadata to the appropriate ECA entity using metadata and existing aggregations.

Hereinafter, each part of the information model will be described.

I2NSF Capability Information Model: Theory of Operation

Functions are commonly used to represent NSF functions that can be called. Since functions are objects, they can be used in sections that describe events, conditions, and / or actions of I2NSF ECA policy rules.

The I2NSF functional information model embodies a predefined metadata model. The application of the I2NSF function can be performed by modifying the predefined ECA policy rule information model that defines how to use, manage or manipulate the function set. In this approach, the I2NSF policy rule can act as a container consisting of three sections: the event clause, the condition clause, and the operation clause.

When the I2NSF policy engine receives a series of events, it matches the events of the active ECA policy rules. If the event matches, trigger the evaluation of the conditional clause of the matching I2NSF policy rule. The condition clause is evaluated, and if it matches, a series of actions in the matching I2NSF policy rule can be executed.

Initial NSFs Capability Categories

Hereinafter, three general functions of network security, content security, and attack mitigation will be described. The number of categories and the type of functions in a specific category, which are described in this specification, can all be extended.

Network Security Capabilities

Network security is a category that describes how to inspect and process network traffic using predefined security policies.

The inspection portion may be a packet processing engine that inspects packets passing through the network, either directly or in the context of the flow with which the packets are associated. From the perspective of packet processing, the contents of packet headers and / or payloads that can be implemented, various flows and context states that can be maintained, and actions applicable to packets or flows may vary depending on the implementation.

Content Security Capabilities

Content security is another category of security features applied at the application layer. For example, it is possible to identify various security functions required by analyzing the content of traffic delivered from the application layer and using the content security function.

This may include defense against intrusions, virus scanning, filtering malicious URLs or junk mail, blocking illegal web access or preventing malicious data retrieval.

In general, each threat type in content security has its own set of attributes and must be handled using a set of methods unique to that type of content. Therefore, these functions are characterized by unique security functions for each content.

Attack Mitigation Capabilities

Attack mitigation is used to detect and mitigate various types of network attacks. A typical network attack today can be defined as:

-DDoS attack:

Network layer DDoS attacks: SYN flood, UDP flood, ICMP flood, IP fragment flood, IPv6 routing header attack and IPv6 duplicate address detection attacks.

Application layer DDoS attacks: HTTP flood, https flood, cache bypass HTTP floods, WordPress XML RPC floods and SSL DDoS for example.

-Single packet attack:

Scanning and sniffing attacks: IP sweep, port scanning, etc.

Bad packet attacks: Ping of Death, Teardrop, etc.

Special packet attack: Extra large ICMP, Tracert, IP time stamp option packet, etc.

Each type of network attack has its own network behavior and packet / flow characteristics. Therefore, each type of attack requires a special security feature that informs the feature set for detection and mitigation. The implementation and management of these security categories mitigation control functions can be very similar to the content security control categories.

Information Sub-Model for Network Security Capabilities

The purpose of the functional information sub-model is to define the concept of a function and allow the functions to be aggregated into appropriate objects. Hereinafter, a sub-model for network security, content security, and attack mitigation will be described.

Information Sub-Model for Network Security

4 shows an example of an overview of a network security information sub-model to which the present specification can be applied.

The purpose of the network security information sub-model is to define how to define network traffic and to determine whether one or more network security functions should be applied to the traffic.

In FIG. 4, ECA policy rules are defined in an external ECA information model together with events, conditions and action objects. The Network Security submodel can extend all of these objects to define extensions to security-related ECA policy rules and (general) event, condition, and action objects.

The I2NSF policy rule is a special type of policy rule in the form of Event Condition Action (ECA). It can consist of policy rules, components of policy rules (for example: events, conditions, action and resolution policies, some extensions such as default actions and external data), and optionally metadata, one-way and two-way traffic through NSF Can be applied to all.

Network Security Policy Rule Extensions

5 shows an example of an extension of a network security information sub-model to which the present specification can be applied.

5 shows an example of a more detailed design of the ECA policy rule subclass included in the network security information submodel. This shows how more specific network security policies are transferred and extended in the SecurityECAPolicyRule class.

According to the class design of the following pattern, a new kind of specific network security policy can be created.

SecurityECAPolicyRule is located at the top of the I2NSF ECA policy rule hierarchy. This rule is transferred from (external) general ECA policy rules and represents the specialization of these general ECA policy rules for adding security related ECA policy rules.

SecurityECAPolicyRule contains all the attributes, methods, and relationships defined in the superclass and adds additional concepts needed for network security.

The six SecurityECAPolicyRule subclasses extend the SecurityECAPolicyRule class to represent six types of Network Security ECA Policy Rules. (External) General ECAPolicyRule class can define basic information in the form of properties such as unique object ID as well as description and other necessary information.

Network Security Policy Rule Operation

The network security policy consists of one or more ECA policy rules that are composed of the information model described above. In the simple case where the event and condition clauses have not changed, the actions of one policy rule can invoke additional network security actions from another policy rule. The network security policy inspects traffic and performs basic processing as follows.

1. The NSF evaluates the event clause of a given SecurityECAPolicyRule (which can be general or specific to security, as shown in Figure 3). The security event object can be used to perform all or part of the evaluation described below.

If the Event clause evaluates to TRUE, the condition clause of this SecurityECAPolicyRule is evaluated. Otherwise, the execution of the SecurityECAPolicyRule is stopped and the next SecurityECAPolicyRule can be evaluated.

2. Thereafter, the condition clause can be evaluated. Using the security requirements object, all or part of the evaluation described below can be performed. If the condition clause evaluates to TRUE, it is defined as "matching" the SecurityECAPolicyRule. Otherwise, the execution of the SecurityECAPolicyRule is stopped and the next SecurityECAPolicyRule can be evaluated.

3. A series of tasks to be executed is retrieved, and a solution strategy is used to define the order of execution. In step 3), the process may include the use of optional external data related to the SecurityECAPolicyRule.

4. The execution takes one of three forms:

      a. When more than one action is selected, NSF can perform the actions defined by the resolution strategy. For example, a resolution strategy may allow only a single action (eg FMR or LMR) to be executed or all actions to be executed (optionally or in a specific order).

In cases other than these, the NSF function must clearly define how to implement it.

You can use security action objects to perform all or part of the execution described below. If the default action is permission or mirror, NSF first performs the function and then checks whether a specific security function is referenced in the rule. If “Yes”, go to Step 5. If No, traffic is allowed.

b. If there is no selected action and there is a default action, the default action may be performed. Otherwise, nothing is done.

c. Otherwise, traffic is rejected.

5.If other security functions (eg: antivirus or IPS profile NSF implied conditions and / or actions) are referenced in the SecurityECAPolicyRule's action set, the NSF can be configured to use the referenced security function (eg For example: check condition or action enforcement).

Thereafter, execution may end.

Network Security Event Sub-Model

6 shows an example of an extension of a network security information sub-model event class to which the present specification can be applied.

6 shows an example of the design of an event subclass included in the network security information submodel.

The four Event classes in FIG. 6 extend (general) general Event classes to represent important events in network security. (External) It can be assumed that the general Event class defines basic event information in the form of a property such as a unique event ID, description, and date and time the event occurred.

Network Security Condition Sub-Model

7 shows an example of extension of a network security information sub-model condition class to which the present specification can be applied.

7 shows a more detailed design of the condition subclass included in the network security information submodel.

The six condition classes shown in FIG. 7 extend (general) general condition classes to indicate conditions related to network security. It is assumed that data model optimization can be defined because the (external) general condition class is abstract.

It is assumed that the general condition class defines basic condition information in the form of attributes, such as a unique object ID, a description, and a mechanism to link zero or more metadata objects.

Network Security Action Sub-Model

8 shows an example of an extension of a network security information sub-model action to which the present specification can be applied.

8 shows a more detailed design of the action subclass included in the network security information sub-model. The four operation classes in FIG. 8 represent operations for extending the (external) general operation class to perform a network security control function.

The three operation classes in FIG. 8 represent operations related to network security by extending the (external) general operation class. (External) Generic Action class is abstract, so data model optimization can be defined.

It is assumed that the generic action class defines basic action information in the form of attributes, such as a unique object ID, a description, and a mechanism to attach zero or more metadata objects.

Information Model for I2NSF Capabilities

9 shows an example of a high-level model of the I2NSF security function to which the present specification can be applied.

As shown in FIG. 9, the I2NSF function model is composed of many functions representing various content security and attack mitigation functions. Each feature protects against certain types of threats at the application layer.

9 shows a general I2NSF security function class called SecurityCapability. This allows common properties, relationships, and behaviors to be added to this class without affecting the design of the external metadata information model. All I2NSF security functions are subclassed in the SecuritCapability class.

Information Model for Content Security Capabilities

10 shows an example of a network security function information model to which the present specification can be applied.

10 shows exemplary types of content security Generic Network Security Function (GNSF).

As shown in FIG. 10, content security may be composed of various unique security functions. Each of these features can protect content from certain types of threats at the application layer.

Content security may be of the Generic Network Security Function (GNSF) type as shown in FIG. 10.

Information Model for Attack Mitigation Capabilities

11 shows an example of an attack mitigation function information model to which the present specification can be applied.

As illustrated in FIG. 11, attack mitigation may be composed of several GNSFs. Each protects content from certain types of network attacks. Acknowledgment mitigation security is a type of GNSF that summarizes well-defined security features.

Structure and purpose of I2NSF security policy

One. I2NSF Security Policy Rule

The I2NSF security policy rules represent policy rules for general network security functions. The object of the policy rule may be defined as policy information and rule information. This can include ECA policy rules such as Event Clause Objects, Condition Clause Objects, Action Clause Objects, Resolution Strategy and Default Action.

2. Event Clause

Events can occur when a managed system changes, and / or at an important point in the managed system's environment, as discussed above.

Event Clause Objects, when used in the context of I2NSF policy rules, can be used to determine whether the condition clauses of I2NSF policy rules can be evaluated. The target of the event section can be defined as user security event, device security event, system security event, and time security event. The subject of the event provisions can be extended to specific vendor event capabilities.

3. Condition Clause

Conditions are defined as a set of attributes, functions and / or values to be compared to a set of known attributes, features and / or values, as discussed above, to enable or disable the (imperative) I2NSF policy rule.

These objects can be defined as packet security conditions, packet payload security conditions, target security conditions, user security conditions, context conditions, and general context conditions.

Objects of the Action clause can be extended according to specific vendor terms and conditions.

4. Action Clause

Actions are used to control and monitor aspects of the flow-based NSF when the event and condition clauses are met. NSF provides security by executing various actions. Objects in the action section may be defined as input actions, transmission actions, and application profile actions, and the action section objects may be extended according to specific vendor action functions.

Data model structure

Hereinafter, the data model proposed in this specification will be described.

The structure of the data model proposed in this specification was considered as follows.

-Consideration of ECA policy model by aggregation of Event, Condition, and Action clauses

-Consideration of the number of functions.

-Consider NSF functional categories (eg network security, content security and attack mitigation).

-Definition of network security event class, network security condition class and network security work class.

12 illustrates a data model structure for network security policy identification according to an embodiment of the present specification.

The data model for identifying the network security policy may be configured with a structure as shown in FIG. 12.

The data model for identifying the network security policy may be composed of a security policy, an event clause container, a condition clause container, and an action clause container.

The data field of the security policy may consist of a policy name, rules, resolution strategy, fixed action, and rule group.

Rules are names to identify rules, description to describe rules, priority, enable, session-aging-time, long-connection, policy-event-clause-agg-ptr *, policy-condition-clause-agg-ptr *, policy-action-clause-agg-ptr * and time-zone.

The long-connection may include enable and during so that the duration to which the rule can be applied can be set.

In addition, the time-zone may include absolute-time-zone and periodic-time-zone so that a periodic time can be set in addition to the absolute time of the applied rule.

absolute-time-zone is the start-time ?, end-time? to set the start time and end time to set the absolute time or date to which the rule applies. And absolute-date * for setting the date.

The periodic-time-zone may include day and month for setting the periodic time to which the rule is applied.

Resolution-strategy is (resolution-strategy-type) to set the type of strategy to set the resolution strategy for the rule, first-matching-rule to set the first matching rule? And last-matching-rule? For setting the last matched rule.

The default-action is a field for setting an action that can be performed when no action is selected, and the type of action can be set.

The rule-group is composed of groups in which rules can be grouped and managed, and a data field for each group includes group-name, rule-range, enable, and description.

The event-clause-container, condition-clause-container, and action-clause-container can be used to aggregate policy events “events”, “actions” and “conditions”.

13 illustrates a data model structure for event rules according to an embodiment of the present specification.

As described above, an event means an event that occurs when a managed system is changed and / or at an important point in the environment of the managed system.

Objects for the event clause shown in FIG. 13 may be defined as a user security event, a device security event, a system security event, and a time security event. These objects can be extended according to specific vendor event functions, and additional event objects for more general network security functions can be added.

14A to 14D illustrate a data model structure for a condition rule according to an embodiment of the present specification.

Conditions are defined as a set of attributes, functions and / or values to be compared to a set of known attributes, features and / or values, as discussed above, to enable or disable the (imperative) I2NSF policy rule.

Objects for the condition rule may be defined as packet security conditions, packet payload security conditions, target security conditions, user security conditions, context conditions, and general context conditions.

Objects for these condition rules can be extended according to specific vendor condition functions, and condition objects for more general network security functions can be added.

Also, as shown in FIG. 14C, the data model structure for the condition rule is pkt-sec-cond-tcp-src-port *, pkt-sec-cond-tcp-dest-port *, pkt-sec-cond-udp Rules related to port numbers can be set through -src-port * and pkt-sec-cond-udp-dest-port *.

In FIG. 14D, in order to manage the state of an application to which a rule can be applied, the data field of application-condition includes application-description ?, application-object *, application-group *, application-label *, category.

In addition, rules can be set whether or not to be applied according to a URL (Uniform Resource Locator), and for this, data fields of url-category-condition include pre-defined-category * and user-defined-category *.

15 illustrates a data model structure for an action rule according to an embodiment of the present specification.

Actions are used to control and monitor aspects of the flow-based NSF when the event and condition clauses are met.

These entities can be defined as receive actions, send actions and apply profile actions. These objects can be extended according to specific vendor operation functions, and action objects for more general network security functions can be added.

Since the container structure is used for the structure of the data model for the condition rule and the action rule shown in FIGS. 14A to 15, multiple conditions can be applied.

16A to 19J illustrate a YANG data module of an I2NSF NSF-Facing Interface according to an embodiment of the present specification.

16A to 19J, a YANG data model for an information model of network security functions may be set using the data model described with reference to FIGS. 12A to 15B.

The modules shown in FIGS. 16A-19J can be defined as both data modules for network security functions.

Hereinafter, an information model for monitoring NSF will be described.

To configure the security functions, monitor the NSF and monitor the NSF with the interface provided by the NSF (for example: FW, IPS, Anti-DDOS or Anti-Virus function) to the management entity (for example: NMS, security controller). This is called "I2NSF NSF-Facing Interface" (see ID.ietf-i2nsf-terminology).

The monitoring part means obtaining important information about the NSF. Notifications, events, records and counters. When done in a timely and comprehensive manner, NSF monitoring plays a very important role in the overall security framework. The monitoring information generated by the NSF may be an early indication of malicious activity or abnormal behavior or potential signs of denial of service attacks.

NSF monitoring data can be used in the following situations.

As described above, monitoring plays a very important role in the overall security framework. Monitoring the NSF provides critical information to the security controller in maintaining a defined security state. In addition to this, there are other reasons for monitoring NSF as shown below.

-Security administrators can configure policies triggered by specific events that have occurred in NSF or network. The security controller monitors the specified event and configures additional security functions according to the policy when the event occurs.

-Events triggered by NSF as a result of security policy violations can be used by SIEM to detect suspicious activity.

-NSF's event and activity logs can be used to build advanced analytics, such as behavior and prediction, to improve security.

-Security controllers can use NSF's events to achieve high availability. Corrective actions can be taken, such as a failed NSF restart or NSF horizontal expansion.

-NSF's event and activity logs can help debug operational problems and analyze the root cause.

-NSF's activity records can be used to create historical data for operational and business reasons.

Classification of NSF monitoring data

To maintain a strong security posture, NSF security policies must be configured, as well as continual monitoring of the NSF by consuming observable information. This allows security managers to assess what is happening on the network in a timely manner.

It is impossible to block all internal and external threats based on static security status. Achieving this goal requires a very dynamic posture with constant visibility. This specification can define a set of information elements (and their scope) that can be obtained from NSF and used as monitoring information.

   In essence, this type of monitoring information can be utilized to support continuous visibility into multiple levels of granularity and can be consumed by that function.

Hereinafter, a basic information model for all monitoring data will be described.

Basic Information Model for All Monitoring Data

-message_version: Represents the version of the data type, a 2-digit decimal number starting from 01.

-message_type: event, warning, alarm, log, counter, etc.

-time_stamp: indicates the time the message was created.

-vendor_name: Name of the NSF vendor.

-NSF_name: The name (or IP) of the NSF generating the message.

-Module_name: the name of the module that outputs the message

-Severity: Log level. There are a total of 8 levels (0 to 7), and the smaller the number, the higher the severity.

Extended Information Model for Monitoring Data

The extended information model is only used for structured data such as alarms. Unstructured data is specified only as a basic information model.

System Alarm

Memory Alarm

The following information should be included in the memory alarm.

-event_name: 'MEM_USAGE_ALARM'

-module_name: indicates the NSF module responsible for generating the alarm.

-usage: Specifies the amount of memory used.

-Threshold: Threshold that triggers the alarm

-Severity: Risk level (eg: risk level, high, medium, low)

-Message: Outputs a message such as 'Memory usage has exceeded the threshold'.

CPU Alarm

The following information may be included in the CPU alarm.

-event_name: 'CPU_USAGE_ALARM'

-usage: Specifies the amount of CPU used.

-threshold: threshold value that triggers the event

-Severity: Risk level (eg: risk level, high, medium, low)

-Message: 'CPU usage has exceeded the threshold.' Prints out a message like

Disk Alarm

The following information may be included in the disk alarm.

-event_name: 'DISK_USAGE_ALARM'

-usage: Specifies the amount of disk space used.

-threshold: threshold value that triggers the event

-Severity: Risk level (eg: risk level, high, medium, low)

-Message: 'Disk usage has exceeded the threshold.' Prints out a message like

Hardware Alarm

The following information may be included in the hardware alarm.

-event_name: 'HW_FAILURE_ALARM'

-component_name: Represents the HW component that generates this alarm.

-Threshold: Threshold that triggers the alarm

-Severity: Risk level (eg: risk level, high, medium, low)

-Message: A message such as 'Hardware component is broken or performance is degraded' is output.

Interface Alarm

The following information may be included in the interface alarm.

-event_name: 'IFNET_STATE_ALARM'

-interface_Name: Interface name

-interface_state: 'UP', 'DOWN', 'CONGESTED'

-threshold: threshold value that triggers the event

-Severity: Risk level (eg: risk level, high, medium, low)

-Message: 'Current interface status' is printed.

System Events

Access Violation

The following information may be included in the event.

-event_name: 'ACCESS_DENIED'

-user: user name

-group: the group to which the user belongs

-login_ip_address: user's login IP address

-authentication_mode: User authentication mode. Examples: Local authentication, third-party server authentication, authentication exemption, SSO authentication

-Message: 'Access is denied.' Prints out a message like

Configuration Change

The following information may be included in the event.

-event_name: 'CONFIG_CHANGE'

-user: user name

-group: the group to which the user belongs

-login_ip_address: user's login IP address

-authentication_mode: User authentication mode. Examples: Local authentication, third-party server authentication, authentication exemption, SSO authentication

-Message: Outputs a message such as 'The configuration has been modified'.

System Log

Access Logs

The access log records the administrator's login, logout, and device activity, and can be analyzed to identify security vulnerabilities. The operational report may include the following information.

-Administrator: Administrator working on the device

-login_ip_address: IP address used by the administrator to log in

-login_mode: Specifies the administrator login mode (for example: root, user).

-operation_type: type of operation performed by the administrator (for example: login, logout, configuration, etc.)

-Result: Command execution result

-content: Actions performed by the administrator after login.

Resource Utilization Logs

The running report records the running status of the device system, which is useful for device monitoring. The action report may include the following information.

-system_status: current system running status

-CPU_usage: Specifies the CPU usage.

-memory_usage: Specifies the memory usage.

-disk_usage: Specifies the disk usage.

-disk_left: Specifies the available disk space.

-session_number: Specifies the total number of concurrent sessions.

-process_number: Specifies the total number of system processes.

-in_traffic_rate: Total inbound traffic rate (pps)

-out_traffic_rate: Total outbound traffic rate (pps)

-in_traffic_speed: Total inbound traffic speed (bps)

-out_traffic_speed: Total outbound traffic speed (bps)

User Activity Logs

User activity records provide the user's online history (login time, online / lockout period and login IP address) and visibility into what the user is doing. User activity reports are useful for identifying exceptions during user login and network access activities.

-group: the group to which the user belongs

-login_ip_address: user's login IP address

-authentication_mode: User authentication mode. Examples: Local authentication, third-party server authentication, authentication exemption, SSO authentication

-access_mode: User access mode. For example: PPP, SVN, LOCAL

-online_duration: online period

-lockout_duration: lockout period

-Type: User activity. Successful user login, failed login attempt, user logout, successful user password change, failed user password change, user lock, unlock user, unknown

-Cause: User action failed.

System Counter

Interface counters

Interface counters provide visibility into traffic going into and out of NSF and bandwidth usage.

-interface_name: Network interface name configured in NSF

-in_total_traffic_pkts: All inbound packets

-out_total_traffic_pkts: total outbound packets

-in_total_traffic_bytes: Total inbound bytes

-out_total_traffic_bytes: total outbound bytes

-in_drop_traffic_pkts: Total inbound drop packets

-out_drop_traffic_pkts: total outbound drop packets

-in_drop_traffic_bytes: Total inbound drop bytes

-out_drop_traffic_bytes: Total outbound drop bytes

-in_traffic_ave_rate: Average rate of inbound traffic (pps)

-in_traffic_peak_rate: Peak rate of inbound traffic (pps)

-in_traffic_ave_speed: Average inbound traffic speed (bps)

-in_traffic_peak_speed: Maximum inbound traffic speed (bps)

-out_traffic_ave_rate: average outbound traffic rate (pps)

-out_traffic_peak_rate: Outbound traffic peak rate (pps)

-out_traffic_ave_speed: average outbound traffic speed (bps)

-out_traffic_peak_speed: Outbound traffic peak speed (bps)

NSF Events

The DDos event may include the following information.

-event_name: 'SEC_EVENT_DDoS'

-sub_attack_type: Syn flood, ACK flood, SYN-ACK flood, FIN / RST flood, TCP connection flood, UDP flood, Icmp flood, HTTPS flood, HTTP flood, DNS query flood, DNS reply flood, SIP flood, etc.

-dst_ip: IP address of the victum under attack

-dst_port: The port number targeting the traffic.

-start_time: timestamp indicating when the attack started

-end_time: Timestamp indicating when the attack ended. If the attack continues to occur when sending alerts, this field may be empty.

-attack_rate: PPS of attack traffic

-attack_speed: bps of attack traffic

-rule_id: ID of the rule to be triggered.

-rule_name: the name of the rule to be triggered

-Profile: Security profile with matching traffic.

Session Table Event

The following information may be included in the session table event.

-event_name: 'SESSION_USAGE_HIGH'

-current: number of concurrent sessions

-max: the maximum number of sessions the session table can support

-threshold: the threshold value that triggers the event

-Message: 'The number of session tables has exceeded the threshold.'

Virus Event

The following information may be included in the virus event.

-event_Name: 'SEC_EVENT_VIRUS'

-virus_type: Virus type (eg Trojan, worm, macro) Virus type, virus name

-dst_ip: Destination IP address of the packet where the virus was found

-src_ip: Source IP address of the packet where the virus was found

-src_port: Source port of the packet where the virus was found

-dst_port: Destination port of the packet where the virus was found

-src_zone: Source security zone of the packet where the virus was found

-dst_zone: Target security zone of the packet where the virus was found

-file_type: The type of the file where the virus is hidden

-file_name: The name of the file where the virus is hidden

-virus_info: brief introduction of viruses

-raw_info: Information describing the packet that triggers the event.

-rule_id: ID of the rule to be triggered.

-rule_name: The name of the rule to be triggered

-Profile: Security profile with matching traffic.

Intrusion Event

-The Intrustion Event must contain the following information.

-event_name: Event name: 'SEC_EVENT_Intrusion'

-sub_attack_type: attack type, e.g. brutal force, buffer overflow

-src_ip: source IP address of the packet

-dst_ip: destination IP address of the packet

-src_port: source port number of the packet

-dst_port: destination port number of the packet

-src_zone: source security zone of the packet

-dst_zone: Target security zone of the packet

-Protocol: transport layer protocol used, e.g. TCP, UDP

-app: adopted application layer protocol (eg: HTTP, FTP)

-rule_id: ID of the rule to be triggered.

-rule_name: the name of the rule to be triggered

-Profile: Security profile with matching traffic

-intrusion_info: brief description of the intrusion

-raw_info: Information describing the packet that triggers the event.

Botnet Event

The following information may be included in the botnet event.

-event_name: Event name: 'SEC_EVENT_Botnet'

-botnet_name: The name of the detected botnet

-src_ip: the source IP address of the packet

-dst_ip: destination IP address of the packet

-src_port: source port number of the packet

-dst_port: destination port number of the packet

-src_zone: Source security zone of the packet

-dst_zone: Target security zone of the packet

-Protocol: transport layer protocol used, e.g. TCP, UDP

-app: adopted application layer protocol (e.g. HTTP, FTP)

-Role: The role of the communication party in the botnet:

  1. Packets from zombie host to attacker

  2. Packet from attacker to zombie host

  3. Packet from IRC / WEB server to zombie host

  4. Packets sent from zombie host to IRC / WEB server

  5. Packet sent from the attacker to the IRC / WEB server

  6. Packets from IRC / WEB server to attacker

  7. Packets from zombie host to victim

-botnet_info: Brief description of Botnet

-rule_id: ID of the rule to be triggered.

-rule_name: The name of the rule to be triggered

-Profile: Security profile with matching traffic

-raw_info: information describing the packet that triggers the event

Web Attack Event

The following information may be included in the web attack event.

-event_name: Event name: 'SEC_EVENT_WebAttack'

-sub_attack_type: specific web attack type (eg sql injection, command injection, XSS, CSRF)

-src_ip: the source IP address of the packet

-dst_ip: destination IP address of the packet

-src_port: source port number of the packet

-dst_port: destination port number of the packet

-src_zone: Source security zone of the packet

-dst_zone: Target security zone of the packet

-req_method: method of requirement. For example 'PUT' or 'GET' in HTTP

-req_url: requested URL

-url_category: matching URL category

-filtering_type: blacklist, whitelist, custom, predefined, malicious categories, unknown URL filtering type

-rule_id: ID of the rule to be triggered.

-rule_name: The name of the rule to be triggered

-Profile: Security profile with matching traffic.

NSF Logs

DDoS Logs

In addition to the fields of the DDoS alert, the following information may be included in the DDoS log in addition to the fields.

-Attack type: DDoS

-attack_ave_rate: average pps of attack traffic within recorded time

-attack_ave_speed: average bps of attack traffic within the recorded time

-attack_pkt_num: Number of attack packets within the recorded time

-attack_src_ip: Source IP address of attack traffic. If you have a large number of IP addresses, select a certain number of resources according to different rules.

-Actions: Actions on DDoS attacks (eg: allow, warning, block, discard, declare, block IP, block service).

Virus Logs

In addition to the fields of virus alerts, the following information may be included in the virus log.

-Attack type: Virus

-Protocol: Transport layer protocol

-app: name of the application layer protocol

-times: Virus detection time

-Actions: Actions dealing with viruses (eg warning, blocking)

-os: OS affected by the virus (e.g. all, android, ios, unix, windows).

Intrusion Logs

In addition to the intrusion alert field, the following information may also be included in the intrusion log.

-Attack type: Intrusion

-Time: Intrusion time occurred at the recorded time.

-os: OS that affects the intrusion (eg all, android, ios, unix, windows).

-Actions: Actions dealing with intrusions, such as allow, warning, block, discard, declare, block -IP, block-Service

-attack_rate: pps NUM of attack traffic

-attack_speed: bps of NUM attack traffic

Botnet Logs

In addition to the fields of the Botnet Alarm, the following information can be included in the botnet log.

-attack_type: Botnet

-botnet_pkt_num: The number of packets sent or received by the detected botnet

-Action: Action to process the detected packet (eg, allow, warning, block, discard, declare, block IP, block service, etc.

-os: Any OS targeted for attack, for example, android, ios, unix, windows, etc.

DPI Logs

DPI logs provide statistics on uploaded and downloaded files and data, emails sent and received, and can warn and block records on websites.

 -Type: DPI work type. Examples: file blocking, data filtering, application behavior control

-file_name: File name

-file_type: File type

-src_zone: Traffic source security zone

-dst_zone: Target security zone of traffic

-src_region: traffic source region

-dst_region: target area of traffic

-src_ip: traffic source IP address

-src_user: user who generated traffic

-dst_ip: target IP address of traffic

-src_port: traffic source port

-dst_port: Destination port of traffic

-Protocol: Protocol type of traffic

-App: Application type of traffic

-policy_id: Security policy ID with matching traffic

-policy_name: Security policy name with matching traffic

-Action: This is the action defined in the file blocking rule, data filtering rule, or application action control rule with matching traffic.

Vulnerabillity Search Log

In the vulnerability search log, the host and related vulnerability information should be recorded. The following information should be included in the report.

-victim_ip: IP address of the victim's vulnerable host

-Vulnerability ID: Vulnerability ID

-vulnerability_level: Vulnerability level. Example: high, low, low

-Operating system: Operating system of the target host

-Service: Service vulnerable to victim host

-protocol: Protocol type. Example: TCP, UDP

-port: Port number

-vulnerability_info: Information about vulnerability

-fix_suggestion: Suggested fix for vulnerability.

-8.6.7. Web attack log

-In addition to the fields of the web attack alert, the following information should be included in the web attack report.

-attack_type: Web attack

-rsp_code: response code

-req_clientapp: client application

-req_cookies: cookies

-req_host: Domain name of the requested host

-raw_info: Information describing the packet that triggers the event.

NSF Counter

Firewall Counters

Firewall counters provide traffic signing, bandwidth usage, and visibility into how configured security and bandwidth policies have been applied.

-src_zone: Traffic source security zone

-dst_zone: Target security zone of traffic

-src_region: traffic source region

-dst_region: target area of traffic

-src_ip: traffic source IP address

-src_user: user who generated traffic

-dst_ip: target IP address of traffic

-src_port: traffic source port

-dst_port: Destination port of traffic

-Protocol: Protocol type of traffic

-App: Application type of traffic

-policy_id: Security policy ID with matching traffic

-policy_name: Security policy name with matching traffic

-in_interface: Inbound interface of traffic

-out_interface: outbound interface of traffic

-total_traffic: total traffic volume

-in_traffic_ave_rate: Average rate of inbound traffic (pps)

-in_traffic_peak_rate: Peak rate of inbound traffic (pps)

-in_traffic_ave_speed: Average inbound traffic speed (bps)

-in_traffic_peak_speed: Maximum inbound traffic speed (bps)

-out_traffic_ave_rate: average outbound traffic rate (pps)

-out_traffic_peak_rate: Outbound traffic peak rate (pps)

-out_traffic_ave_speed: average outbound traffic speed (bps)

Policy Hit Counters

 The policy hit counter records the number of hits and security policies that match traffic. You can verify that the policy configuration is correct.

-src_zone: Traffic source security zone

-dst_zone: Target security zone of traffic

-src_region: traffic source region

-dst_region: target area of traffic

-src_ip: traffic source IP address

-src_user: user who generated traffic

-dst_ip: target IP address of traffic

-src_port: traffic source port

-dst_port: Destination port of traffic

-Protocol: Protocol type of traffic

-App: Application type of traffic

-policy_id: Security policy ID with matching traffic

-policy_name: Security policy name with matching traffic

-hit_times: The number of times the security policy matches the specified traffic.

20A to 20J illustrate a data model for NSF monitoring according to an embodiment of the present specification.

20A to 20J, a data model can be designed using the information model for monitoring the NSF described above.

21A to 22I illustrate a YANG data model for monitoring according to an embodiment of the present specification.

When NSF monitoring is performed in a comprehensive manner, it is possible to detect signs of malicious activity, abnormal behavior, or potential denial-of-service attacks in a timely manner. These monitoring functions are based on the monitoring information generated by the NSF discussed earlier.

Accordingly, this specification proposes a method of designing a corresponding YANG data model for NSF monitoring as well as a data model structure tree specifying an information model for NSF monitoring.

21A to 22I, the YANG data model can be designed using the information model and data model for NSF monitoring as described above.

Data Model of Security Policy for Consumer-facing Interface

The purpose of the data model of the security policy for the consumer-facing interface is the YANG data model that can be used to convey control and management messages through the consumer-facing interface between the I2NSF user and the security controller for the high-level security policy of the I2NSF user. It is to transform the information model (client-facing-inf-im).

Therefore, this data model must match the information model of the consumer-facing interface. YANG data model for efficient delivery of control or management messages. The information model can be converted.

The data model is designed to support the I2NSF system that can be expanded according to security requirements. That is, the design of the data model is independent of specific policies and implementation methods.

22 is an illustration of a high level extraction for a consumer-facing interface in which the present specification can operate.

Referring to FIG. 22, multi-tenancy may allow multiple management domains for managing application resources. Enterprise groups can include multiple tenants or departments such as HR, finance and law. Therefore, an object is required to define a set of permissions that can be assigned to users of an organization who wants to manage its own security policy. This may refer to the task of assigning a set of task functions or privileges within the organization to users of the policy. The object of the policy-role includes the name, date and access profile to grant or deny security policy management authority.

22A-22D illustrate a data model of a security policy for a consumer-facing interface according to one embodiment of the present specification. 32A to 32D, a data model of a security policy for the aforementioned consumer-facing interface can be designed.

23 illustrates a YANG data model for a security policy of a consumer-facing interface according to an embodiment of the present specification. Referring to FIG. 23, a YANG data model for the security policy of the aforementioned consumer-facing interface can be designed.

In addition, this specification proposes the design of a security policy converter in an Interface to Network Security Functions (I2NSF) system.

I2NSF users should be able to use NSF without having an overall knowledge of Network Security Functions (NSF). In general, policies generated from I2NSF users contain abstract data because the user does not consider the properties of NSF when creating policies. Therefore, in the I2NSF system, when the security controller receives a security policy from a user, the NSF required for the policy is automatically found and a translator is translated for the selected NSF. In this specification, we propose a model to modularize the translator through the theory of Automata. In more detail, this specification allows users to create high-level security policies through I2NSF, deliver them to the security controller, and the security controller translator of the security controller searches for the target NSF and converts it to a lower-level policy corresponding to each of the searched NSFs. , We propose a model to set all work functions related to I2NSF.

Through this, the present specification can provide convenience of using network security functions to both I2NSF users and system administrators, and I2NSF users do not need to know the functions of NSF, and system administrators can flexibly manage the policy conversion process. have.

The need for a policy translator

24 and 25 are examples of security policies to which the present specification can be applied.

For example, as a policy to block certain malicious websites,

- Blocking the son's computer from malicious websites (FIG. 24)

- Drop packets from IP addresses 10.0.0.1 and 10.0.0.3 to www.malicious.com and www.illegal.com (Figure 25)

If there is a policy, the two policies require the same action, but at least the source-IP address and the website address are required for the operation of the web filter NSF supporting the website blocking function, so the NSF is suitable for the first policy. Operation is impossible.

On the other hand, it is possible only if the general user knows that the web filter NSF for policy setting is used to create the second policy, and the source-IP address and the website address must be delivered to the NSF. Therefore, the general user must have a professional understanding of NSF.

Therefore, the normal user creates the first policy, while the NSF will need the second policy. In the present specification, a policy that includes abstract data and does not require special knowledge of the NSF is referred to as a high-level security policy (or high-level policy). On the other hand, a policy that includes detailed data required by the NSF and can set all functions necessary for network operation is called a low-level security policy (low-level policy).

Therefore, the I2NSF system must be able to convert a high-level security policy to a low-level security policy, and the I2NSF system must be able to automatically find an appropriate NSF to apply the high-level security policy.

Process of applying policy

26 is an example of a procedure for applying a policy to which the present specification can be applied.

The developer management system registers all NSF functions provided in the I2NSF system in a security controller (S2610).

The I2NSF user creates a high-level security policy, and the I2NSF user delivers a high-level security policy to the security controller using a consumer-facing interface (S2620).

The security controller compares the capabilities of the registered NSF, and searches for a target NSF that can cover the high-level security policy (S2630).

The security controller converts the high-level security policy to the low-level security policy for the searched target NSF and transmits it to the target NSF through the NSF-facing interface (S2640). More specifically, data related to low-level security policies can be generated and delivered to the target NSF.

The security controller sets the target NSF according to the low-level security policy (S2650). More specifically, target NSFs can be established based on data related to low-level security policies.

The operation of the security controller may be performed by an operation of a security policy translator, which will be described later, according to a user's setting or design.

Security policy translator

27 is an example of a security policy translator model to which the present specification can be applied, and FIG. 28 is a flowchart for security policy translation of a security policy translator to which the present specification can be applied.

Referring to Figure 27, the security policy translator includes an extractor, a data converter and a generator. In addition, a security policy translator can be included in the security controller.

When an I2NSF user creates a high-level policy and delivers it to the security controller, the security controller can retrieve the target NSF and convert it to a low-level policy for the target NSF. Referring to FIG. 28, a method for translating security policy will be described in detail as follows.

When a high-level policy is received from the I2NSF user, the extractor of the policy translator extracts the high-level policy data through deterministic finite automation (DFA) (S2810).

The data converter of the policy translator converts the extracted data into NSF Required Data (S2820). The conversion to NSF essential data can be performed by comparing the data with NSF database. In more detail, the extracted abstract data can be converted into NSF essential data through the mapping process and data in the NSF database. The NSF database contains essential data for the NSF to function, and when the NSF is added or deleted, the NSF database can be updated. Through this, the high-level policy in I2NSF can be converted into essential data for a suitable NSF, and even if various NSFs are added or deleted, the high-level policy translation can be performed through the same algorithm through the NSF database.

The generator of the policy translator uses the NSF essential data to search for the target NSF, and generates a low-level policy corresponding to the target NSF (S2830). More specifically, data for a low-level policy may be generated, and data for a low-level policy may include a structure or content for a target NSF, and may be grouped through tags.

Extractor

29 is an example of an extractor model to which the present specification can be applied. More specifically, FIG. 29 is an illustration of an extractor model based on DFA.

DFA can receive a string as a Finite State Machine and create a task for state transition. When the security controller receives the high-level policy, the extractor may extract data by state transition based on the Extensible Markup Language (XML) tag. When the state transition of the high-level policy is made, all data can be automatically extracted from the high-level policy.

Since the DFA structure of the extractor follows the hierarchy of the consumer-facing data model, the I2NSF management system can easily generate the DFA by referring to the data model of the consumer-facing interface. If the data model of the consumer-facing interface is modified, the management system can apply the modified data model by changing only the DFA of the extractor.

Data Converter

30 is an example of a data converter model that can be applied to the present specification. Data converters can specify data to be compatible with NSF capabilities. If the user enters a policy with unspecified data in NSF, the NSF cannot recognize the data normally. For example, if data from the "son computer" is sent to the NSF, it is not specified by the IP address or similar, so the NSF cannot recognize it. In order for NSF to understand, in general, abstract data must be transformed into designated data suitable for NSF capabilities. To this end, the data converter needs to be converted to equivalent data by comparing it with data from a database that contains NSF capabilities. 30 illustrates a data conversion process based on comparison with data in such a database. Referring to FIG. 30, the abstract data 'Son' may be mapped to a specific IP address [10.0.0.1, 10.0.0.3] through comparison with the IP list of the user database. Through the data converter, all data in a high-level policy can be converted into equivalent designated data compatible with NSF capabilities.

Generator

The generator can automatically discover target NSFs and create low-level policies for each target NSF.

First, the generator can search for NSFs that can cover all the features of a high-level policy. The generator searches the target NSF by comparing the NSF functions registered in the developer management system. This process can be called by a provisioned policy, since the generator uses only the policy to find the appropriate NSF. If the target NSF is found using other data not included in the user policy, this may mean that the user knows knowledge of the NSF of the I2SNF system. 31 is an example of policy provisioning to which the present specification can be applied. Referring to FIG. 31, the generator selects a firewall NSF and a web-filter NSF to cover the functions of the policy.

Next, the generator can use the extracted data to create a low-level policy for each target NSF. The generator can be constructed using Context-free Grammar. Context-free syntax refers to a set of production rules that can describe any possible string in a given formal language. Low-level policies can also have their own language based on the YANG data model of the NSF-facing interface. Therefore, these productions can be constructed based on the YANG data model. The production includes "content production" and "structural production". "Content production" is intended to include data in appropriate XML tags. “Structure production” is for grouping different tags. Referring to FIG. 25, it can be seen that the low-level policy is mainly composed of two types of tags. Tags that contain data can be made into content production, and tags that tie other tags into structured production.

Content production may be expressed as Table 2, for example.

Referring to Table 2, square brackets indicate states. More specifically, in the absence of square brackets, it means that the string is completely generated. If tag duplication is allowed, you can add the first production (1) to the production rule. This is an optional production, so if you do not need to allow replication, it can be omitted. Production (2) is the main production of “Content Production”. Tags containing data can be created through production (2). Production 3 is for injecting data into the tag. When the data for the NSF is changed, the I2NSF management system requires only the production (3) change for data mapping for each NSF. For example, if the low-level policy for the source-IP address is to be expressed in FIG. 25, “content production” may be configured as shown in Table 3 below.

“Structure production” can be represented, for example, as in Table 4 below.

Production (7) means grouping different tags with their own tag names. And production (8) represents the transfer of various states bound to production (7) to a structure state or content state. For example, in order to express a low-level policy for the I2NSF tag in FIG. 25, “structural production” may be configured as shown in Table 5.

32 is an example of a tree structure based on the NSF-face interface YANG data model to which the present specification can be applied. When the I2NSF management system constructs a generator based on the context-free syntax, each target NSF can receive a low-level policy that includes all the data required for the target NSF.

The information model, data model, and YANG data model described with reference to FIGS. 1 to 32 may be selectively used in combination.

The embodiments described above are those in which components and features of the present specification are combined in a predetermined form. Each component or feature should be considered optional unless stated otherwise. Each component or feature may be implemented in a form that is not combined with other components or features. In addition, it is also possible to configure an embodiment of the present specification by combining some components and / or features. The order of the operations described in the embodiments of the present specification may be changed. Some configurations or features of one embodiment may be included in other embodiments, or may be replaced with corresponding configurations or features of other embodiments. It is apparent that claims that do not have an explicit citation relationship in the claims can be combined to form an embodiment or included as a new claim by correction after filing.

Embodiments according to the present specification may be implemented by various means, for example, hardware, firmware, software, or a combination thereof. For implementation by hardware, one embodiment of the present specification includes 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 specification may be implemented in the form of a module, procedure, function, etc. that performs the functions or operations described above. The software code can be stored in memory and driven by a processor. The memory is located inside or outside the processor, and can exchange data with the processor by various known means.

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

This specification can be applied to various security management systems.

Claims (20)

In the method for translating the security policy of the policy translator for the network security function interface,
Receiving a high-level first security policy from an Interface to Network Security Functions (I2NSF) user;
Extracting data related to the first security policy based on the first security policy;
Converting data related to the first security policy into essential data for a network security function (NSF); And
Retrieving a target NSF based on the essential data, and generating a low-level second security policy associated with the target NSF;
Including,
The policy translator and the I2NSF user are connected by a user-facing interface, and the policy translator and the NSF are a method for translating a security policy connected by an NSF-facing interface.
According to claim 1,
Generating data related to the second security policy;
Further comprising,
The data related to the second security policy includes a structure or content for the target NSF, and is grouped through tags.
According to claim 2,
Transmitting data related to the second security policy to the target NSF through the NSF-facing interface;
How to include more.
According to claim 3,
Setting the target NSF based on data related to the second security policy;
How to include more.
According to claim 1,
The second security policy
How to include applied policy rules and basic action information that indicates actions for general security functions.
The method of claim 5,
The above policy rules
Includes policy information and rule information,
The policy information and the rule information include an event clause indicating a change in the system, a condition clause indicating an application condition of the policy rule, and a security function performed when the event clause and the condition clause are satisfied. A method comprising an indicated Action Clause.
According to claim 1,
The step of extracting data related to the first security policy
Method using Deterministic Finite Automation (DFA).
According to claim 1,
The step of converting the essential data
A method, performed using NSF database, through mapping and data of the NSF database.
According to claim 1,
The target NSF is
And having the capability to cover all of the first security policy.
According to claim 1,
The above policy translator
A method in which all the functions of the NSF have been registered.
A policy translator for translating security policies for network security function interfaces,
An extractor extracting data related to the first security policy based on a high-level first security policy received from an interface to network security functions (I2NSF) user;
A data converter for converting data related to the first security policy into essential data for a network security function (NSF); And
A generator for retrieving a target NSF based on the essential data, and generating a low-level second security policy associated with the target NSF;
Including,
The policy translator and the I2NSF user are connected by a user-facing interface, and the policy translator and the NSF are connected by an NSF-facing interface.
The method of claim 11,
The generator
Create data related to the second security policy,
The data related to the second security policy includes a structure or content for the target NSF, and is a policy translator grouped through tags.
The method of claim 12,
The data related to the second security policy
A policy translator delivered to the target NSF via the NSF-facing interface.
The method of claim 13,
The target NSF is
A policy translator set based on data related to the second security policy.
The method of claim 11,
The second security policy
A policy translator that contains policy rules that apply, and basic action information that indicates actions for general security functions. The method of claim 15,
The above policy rules
Includes policy information and rule information,
The policy information and the rule information include an event clause indicating a change in the system, a condition clause indicating an application condition of the policy rule, and a security function performed when the event clause and the condition clause are satisfied. A policy translator that includes an Action Clause to indicate.
The method of claim 11,
The extractor
A policy translator that extracts data related to the first security policy using DFA (Deterministic Finite Automation).
The method of claim 11,
The data converter
A policy converter that converts data related to the first security policy into essential data for a network security function (NSF) through mapping with data of the NSF database using an NSF database.
The method of claim 11,
The target NSF is
A policy translator having the capability to cover all of the first security policy.
The method of claim 11,
The above policy translator
Policy translator with all the NSF features registered.

Images