KR102184114B1 - Method and apparatus for providing network security service - Google Patents

Abstract

In the present invention, a security management system for managing a network security function (NSF) through a registration interface is disclosed. Specifically, a method performed by a security controller includes the steps of transmitting an instantiation request message for NSF required for the security management system to a developer's management system; And receiving a registration message from the developer management system instructing registration of an NSF instance for the required NSF in response to the request message, wherein the NSF instance is a developer based on the instantiation request message. It can be created by the management system.

Description

Method for providing network security service and device for same {METHOD AND APPARATUS FOR PROVIDING NETWORK SECURITY SERVICE}

The present invention relates to a system, a method, and an apparatus for providing a network security service, and in more detail, an information model for a registration interface of Network Security Functions (NSF) in I2NSF (Interface to Network Security Functions) And a data model.

Today, various enterprises, such as telecommunications operators and Internet service providers, are widely adopting Network Functions Virtualization (NFV) technology to reduce operating costs and utilize resources in a more efficient and flexible way. In addition, the use of network functions and resources provided by third-party service providers is becoming increasingly popular. In order to protect their network systems and information assets, companies are starting to subscribe and use security features provided by third-party security vendors instead of operating security appliances directly.

This operating model offers a number of advantages. Companies can reduce capital outlays because they do not have to pay to purchase physical security equipment. In addition, an up-to-date database of various attack signatures can be maintained at all times.

However, since the security function is developed by a number of solution vendors and managed by a number of network operators, in order to successfully deploy an NFV-based security function, Efficient standardization is required.

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

In addition, an object of the present invention is to propose an information model required for a registration interface between a security controller and a developer management system in order to support NSF search, instantiation, and registration.

It is also an object of the present invention to propose a procedure based on an information model performed by a security controller and a developer management system through a registration interface.

In addition, an object of the present invention is to propose a YANG data model for an I2NSF registration interface between a security controller and a developer management system.

The technical problems to be achieved in the present invention are not limited to the technical problems mentioned above, and other technical problems that are not mentioned will be clearly understood by those of ordinary skill in the technical field to which the present invention belongs from the following description. I will be able to.

In one aspect of the present invention, in a security management system for managing a network security function (NSF) through a registration interface, a method performed by a security controller, the security management system Transmitting an instantiation request message for NSF required for the developer to a developer's management system; And receiving a registration message from the developer management system instructing registration of an NSF instance for the required NSF in response to the request message, wherein the NSF instance is a developer based on the instantiation request message. It can be created by the management system.

Preferably, it further comprises the step of recognizing the profile (Profile) or signature (signature) of the NSF required for the security management system, the instantiation request message may include the capability information or the signature.

Preferably, the NSF instance created by the developer management system may be characterized in that it matches the NSF based on the capability information or the signature and a preset information model.

Preferably, the security management system further comprises the step of transmitting a de-instantiation request message for an unnecessary NSF to the developer management system, the NSF instance corresponding to the de-instantiation request message to the developer management system It may be characterized in that it is deleted by.

Preferably, the registration message is based on NSF capability information indicating the security capability of the NSF instance, NSF access information used for network access to a new instance, or a role assigned to an entity. In order to determine whether to allow entity access to NSF, at least one of NSF role-based Access Control List (ACL) information specifying an access policy of NSF may be included.

Preferably, the NSF capability information includes at least one of a network security capability (Network-Security Capabilities) field, a content security capability (Content-Security Capabilities) field, an attack mitigation capability (Attack Mitigation Capabilities) field, or performance capabilities. Can include.

Preferably, the performance capability may include processing information and bandwidth information.

Preferably, the role-based access control list includes one or more role IDs used to identify a role of an entity, and the role ID may include one or more access types used to identify a specific type of access request.

Another aspect of the present invention is a security controller for managing a network security function (NSF) through a registration interface, comprising: a communication unit for wireless or wired communication with an external device; And a processor functionally connected to the communication unit, wherein the processor transmits an instantiation request message for NSF required for the security management system to a developer's management system, and the request message In response to, a registration message instructing registration of an NSF instance for the required NSF is received from the developer management system, but the NSF instance may be created by the developer management system based on the instantiation request message.

According to an embodiment of the present invention, the utilization of an Interface to Network Security Functions (I2NSF) registration interface can be further expanded.

In addition, according to an embodiment of the present invention, by defining an NSF capability information model, elements of the I2NSF framework can exchange an NSF capability set in a standardized manner.

The effects that can be obtained in the present invention are not limited to the above-mentioned effects, and other effects not mentioned will be clearly understood by those of ordinary skill in the art from the following description. .

BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are included as part of the detailed description to aid understanding of the present invention, provide embodiments of the present invention, and together with the detailed description, the technical features of the present invention will be described.
1 illustrates an Interface to Network Security Functions (I2NSF) system according to an embodiment of the present invention.
2 illustrates the architecture of an I2NSF system according to another embodiment of the present invention.
3 is a flowchart illustrating a method of registering an NSF instance through a registration interface as an embodiment to which the present invention is applied.
4 is a diagram illustrating an information model of a registration interface according to an embodiment of the present invention.
5 is a diagram illustrating an instance management sub-model according to an embodiment of the present invention.
6 is a diagram illustrating a registration sub-model according to an embodiment of the present invention.
7 is a diagram illustrating an NSF profile, according to an embodiment of the present invention.
FIG. 8 is a diagram schematically illustrating performance capability information according to an embodiment of the present invention.
9 and 10 are diagrams illustrating a role-based access control list (ACL) according to an embodiment of the present invention.
11 is a diagram illustrating a high-level YANG data model of a registration interface according to an embodiment of the present invention.
12 is a diagram illustrating a high-level YANG data model of a registration request according to an embodiment of the present invention.
13 is a diagram illustrating a high-level YANG data model of an instance management request according to an embodiment of the present invention.
14 is a diagram illustrating a high-level YANG data model of NSF capability information according to an embodiment of the present invention.
15 is a diagram illustrating a high-level YANG data model of NSF access information according to an embodiment of the present invention.
16 is a diagram illustrating a high-level YANG data model of NSF performance capability according to an embodiment of the present invention.
17 is a diagram illustrating a high-level YANG data model of a role-based ACL according to an embodiment of the present invention.
18 is a diagram illustrating a data model of an I2NSF registration interface according to an embodiment of the present invention.
19 is a diagram illustrating XML output for a registration interface according to an embodiment of the present invention.
20 illustrates a block diagram of a network device according to an embodiment of the present invention.

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

In some cases, in order to avoid obscuring the concept of the present invention, well-known structures and devices may be omitted, or may be shown in a block diagram form centering on core functions of each structure and device.

In addition, as for terms used in the present invention, general terms that are currently widely used are selected as far as possible, but specific cases will be described using terms arbitrarily selected by the applicant. In such a case, since the meaning of the term is clearly described in the detailed description of the corresponding part, it should not be interpreted simply by the name of the term used in the description of the present invention, and it should be clarified that the meaning of the term should be understood and interpreted. .

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

Throughout the specification, when a part is said to be "connected" to another part, this includes not only "directly connected" but also "electrically connected" with another element interposed therebetween. .

Throughout this specification, when a member is positioned “on” another member, this includes not only the case where a member is in contact with another member, but also the case where another member exists between the two members.

Throughout this specification, when a certain part "includes" a certain component, it means that other components may be further included rather than excluding other components unless otherwise stated. As used throughout the specification of the present application, the term "step (to)" or "step of" does not mean "step for".

Recently, a basic standard interface for an NFV (Network Functions Virtualization)-based security function has been developed by the I2NSF (Interface to Network Security Functions) 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(s) (NSF) provided by a number of security solution vendors.

In the I2NSF architecture, users do not need to consider in detail the management of NSF(s) (NSF management eventually requires the enforcement of security policies), and users are required to protect network resources in the user's network system. Protection policy can be defined. In addition, standardized interfaces from multiple vendors to NSF(s) can simplify the configuration and management of tasks for heterogeneous NSF(s).

This specification proposes an information model required for a registration interface between a security controller and a developer management system to support NSF search, instantiation, and registration. In addition, the present specification proposes a YANG data model for an Interface to Network Security Functions (I2NSF) registration interface. In addition, the present specification provides a YANG data model that defines data required for a registration interface between a security controller and a developer management system in order to dynamically operate an NSF instance pool.

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

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

Terms that can be used in the present specification are defined as follows.

-Application Logic: A component of a security management architecture that creates user-perspective security policies to block or mitigate security attacks.

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

-Security Policy Manager: A component that maps user perspective security policies received from the policy updater to lower level security policies and vice versa.

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

-Event Collector: A component that receives events from the security controller, used to update (or create) user perspective policies in application logic.

-Network security function (NSF): refers to a function or a device for the specific handling of a received packet. The NSF may operate at various layers (eg, a network layer or another Open System Interconnection (OSI) layer, etc.) of various protocol stacks.

For example, as an example of NSF, firewall, intrusion prevention system (IPS)/intrusion detection system (IDS), deep packet inspection (DPI), application visibility and Application Visibility and Control (AVC), Network Virus and Malware Scanning, Sandbox, Data Loss Prevention (DLP), Distribute Denial of Service (DDoS) mitigation, Transport layer security (TLS) proxy, anti-spoofing, etc. may be included.

The NSF according to an embodiment of the present invention may be implemented in any one of the above-described examples, and various types of NSF may be used. In addition, multiple NSFs of the same type may be implemented. In addition, the NSF according to the present invention may be implemented by combining any one or more of the above-described examples.

Hereinafter, the architecture/framework of the I2NSF system and each component of the I2NSF system will be described. In addition, how I2NSF facilitates the implementation of security functions in a technology- and vendor-independent manner in Software-Defined Networking (SDN) and Network Functions Virtualization (NFV) environments, while limiting the functionality of NFS's potential constraints. Explain whether or not) is avoided.

The I2NSF framework is for informing the I2NFS system which I2NSF function should be applied to which traffic (or traffic pattern) by the user of the I2NSF system (e.g., application, overlay or cloud network management system, or corporate network manager or management system). Requires a standard interface. The I2NSF system can recognize this standard interface as a set of security rules for monitoring and controlling the behavior of different traffic. The I2NSF framework also provides a standard interface for users to monitor flow-based security functions hosted and managed by different management domains.

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

Referring to FIG. 1, the I2NSF system includes an I2NSF user, a Network Operator Management System, a Developer's Management System, and/or at least one Network Security Function (NSF).

I2NSF users communicate with the network operation management system through the I2NSF Consumer-Facing Interface. The network operation management system communicates with the NSF(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 request information (e.g., NSF information) from other I2NSF components (e.g., network operation management system) and/or security services (e.g., network security) provided by other I2NSF components (e.g., developer management system) Service) is an I2NSF component. For example, the I2NSF user may be an overlay network management system, an enterprise network manager system, another network domain manager, or the like. I2NSF users may be referred to as I2NSF clients.

A target performing a role assigned to such an I2NSF user component may be referred to as an I2NSF consumer. An example of an I2NSF consumer is the need to dynamically notify the underlay network to allow, rate-limit, or deny flow based on a specific field of the packet over a time span. Video-conference network managers, Enterprise network administrators and management systems who need to request provider networks to enforce specific I2NSF policies for specific flows, An IoT management system may be included that sends a request to the underlay network to block flows that match a set of specific conditions.

I2NSF users can create and distribute high-level security policies. Specifically, I2NSF users need to use a network security service to protect network traffic from various malicious attacks. To request this security service, I2NSF users can create a high-level security policy for the security service they want and notify the network operation management system.

Meanwhile, in the process of preparing a high-level security policy, I2NSF users consider the type of NSF(s) required to realize a security service or security policy rule configuration for each NSF(s). I can't.

In addition, the I2NSF user may 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) higher level security policies to cope with the 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 correspond to a security controller or may be a component including a security controller. Such a network operation management system may be managed by a network operator, and may be referred to as an I2NSF management system.

One of the primary roles of 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). ). 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. In addition, the network operation management system (or security controller) may create a low-level security policy for each required NSF(s). Eventually, 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 NSF(s) running in the I2NSF system, and various information about each NSF(s) (e.g., network access information and workload ) State, etc.) can be maintained. In addition, the network operation management system (or security controller) can dynamically manage the pool of NSF instances through dynamic life-cycle management of NSF instances with the help of the developer management system. have.

NSF

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

Developer management system

The developer management system is an I2NSF component that sends information (eg, information of NSF) to another I2NSF component (eg, network operation management system), and/or provides security services (eg, network security service). The developer management system may also be referred to as a vendor's management system. An object that performs a role assigned to this developer management system may be referred to as an I2NSF producer.

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

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

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

This CFI can be used to enable different users of a given I2NSF system to define, manage and monitor security policies for specific flows within the management domain. High-level security policies (or policy rules) created by I2NSF users can be delivered to the network operation management system through this CFI. In addition, security alerts by NSF(s) can be delivered from the network operation management system to the I2NSF user through this CFI.

I2NSF NSF-facing interface (briefly, NSF-facing interface (NFI))

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

The main purpose of NFI is to provide a standardized interface for controlling and managing NSF(s) of various security solution vendors by decouple security management techniques from NSF(s). The NFI is independent of the details of the NSF(s) (eg vendor, form factor, etc.). Therefore, when setting security policy rules to NSF, the network operation management system does not need to take into account vendor specific differences and/or NSF form factors. This NFI can be used to specify and monitor flow-based security policies enforced by one or more NSFs. For example, the network operation management system may deliver a flow-based security policy to each flow-based NSF through an NFI interface in order to enforce a high-level security policy by an I2NSF user. Here, the flow-based NSF is an NSF that examines network flow according to a set of policies to enhance security characteristics. The flow-based security by this flow-based NSF means that packets are inspected in the order they are received, and there is no modification to the packet according to the inspection process. Interfaces to flow-based NSFs can be classified as follows:

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

-Monitoring Interface: An interface group 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 the information. The functionality of this interface group can also be defined by other protocols such as SYSLOG and DOTS. The I2NSF management system may take one or more actions based on receipt of the information. This must be specified by the I2NSF policy rules. This interface group does not change the NSF's operational state.

As such, NFI can be developed using a flow-based paradigm. A common trait of flow-based NSF is to process the packet 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 to define the operation of the I2NSF system.

On the other hand, the I2NSF management system does not need to use all 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 (briefly, registration interface (RI))

RI is an interface located between the network operation management system and the developer management system. NSFs offered by different vendors may have different capabilities. Thus, in order to automate the process of using the different types of security capabilities provided by different vendors, vendors need to have dedicated interfaces to define the functionality of their NSF. This dedicated interface may be referred to as an I2NSF registration interface (RI).

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

2 illustrates the architecture of an I2NSF system according to another embodiment of the present invention. 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 those described above in FIG. 1 are omitted.

Referring to Figure 2, the I2NSF system includes an I2NSF user, a security management system (Security Management System), and NSF instance (instances) layer. I2NSF user layer includes an application logic (Application Logic), a policy updater (Policy Updater), and an event collector (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 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 at the I2NSF user layer communicate with the security controller at 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 at the security management system layer communicates with the NSF instance(s) at the NSF instance layer through 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 the 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 respectively the I2NSF user component, the network operation management system component, the developer management system component, and the NSF of FIG. Corresponds to the component. In addition, the consumer-facing interface, the NSF-facing interface and the registration interface of FIG. 2 correspond to the consumer-facing interface, the NSF-facing interface and the registration interface of FIG. 1. Hereinafter, newly defined components included in each layer will be described.

I2NSF users

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

Application logic is a component that creates a high-level security policy. To this end, the application logic receives an event for updating (or generating) a high-level policy from the event collector, and updates (or generates) the high-level policy based on the collected event. After that, the higher level policy is sent to the policy updater for distribution to the security controller. To update (or create) a high level policy, 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 higher level security policy.

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

Security management system

As mentioned above, the security controller of the security management system layer includes two components: a security policy manager and an NSF capability manager. Each role and operation will be described as follows.

Security policy managers can receive high-level policies from the policy updater through CFI, and map these policies to multiple low-level policies. This low-level policy relates to a given NSF capability registered with the NSF capability manager. In addition, the security policy manager can communicate this policy to the NSF(s) through the NFI.

The NSF Capability Manager can specify the capabilities of the NSF registered by the Developer Management System, and share it with the Security Policy Manager, in order to create a low-level policy related to a given NSF capability. Whenever a new NSF is registered, the NSF Capability Manager can request the developer management system to register the NSF's function/capability in the NSF Capability Manager's management table through the registration interface. The developer management system is another part of the security management system for registering new NSF capabilities as NSF capability managers.

In FIG. 2, the security policy manager and the NSF capability manager are shown in separate configurations, but the present invention is 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 contains NSFs. At this time, all NSFs are located in this NSF instance layer. Meanwhile, after translating the high-level policy to the low-level policy, the security policy manager passes the policy to the NSF(s) through the NFI. In this case, the NSF can detect malicious network traffic and block or mitigate it based on the received low-level security policy.

Hereinafter, information and data models for I2NSF will be described. In particular, the information and data model (YANG data model) on the registration interface in the I2NSF system will be described. According to an embodiment of the present invention, it is possible to support NSF discovery, instantiation, and registration according to required security capabilities through the I2NSF registration interface.

To this end, first, the basic concepts of the information model and data model will be described.

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

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

In general, the data model is defined as a lower level abstraction, and provides many details. The data model provides details of the implementation and specifications of the protocol, e.g., rules that describe how to map managed objects into lower-level protocol constructs. Since the conceptual model can be implemented in various ways, multiple data models can be derived from a single information model. The data model is required for NSF instance registration and dynamic lifecycle management of NSF instances.

Hereinafter, an information model for an I2NSF registration interface between a security controller and a developer's management system will be described.

Multiple virtual NSF instances usually exist in the I2NSF framework. Since these NSF instances can have different security functions, it is important to register them with the security controller after the security functions of each NSF instance are created. In addition, NSFs of some security functions must be instantiated if necessary. For example, if additional security features are required to meet the new security requirements required by I2NSF users, the security controller should be able to request the developer management system to instantiate the NSF with the required security features.

In the present invention, an information model and a YANG data model for an I2NSF registration interface between a security controller and a developer management system that support NSF search, instantiation, and registration according to required security capabilities are proposed. In addition, the present invention proposes a procedure performed in the security controller and the developer management system through the registration interface using the defined model.

In addition, the present invention proposes a procedure based on a capability information model performed by a security controller and a developer management system through a registration interface.

The existing I2NSF registration interface was used only when registering a new NSF instance in the security controller. On the other hand, in the present invention, if necessary, in order to support NSF instantiation/deinstantiation, the usability thereof is extended and information to be exchanged through a registration interface for function is proposed. In addition, in the present invention, in the case of the registration interface, because the NSF capability information (i.e., the capability of the NSF) must be clarified so that the components of the I2NSF framework can exchange the set of capabilities in a standardized manner, the NSF information model for this Defines

In this specification, a network security function (NSF) refers to a function in charge of specific processing of a received packet. NSF can operate at various layers of the protocol stack (eg, the network layer or other Open Systems Interconnection (OSI) layers).

In addition, in this specification, NSF (or network security service function) is, for example, a firewall, intrusion prevention system / intrusion detection system (IPS: Intrusion Prevention System / IDS: Intrusion Detection System), deep packet inspection (DPI: Deep Packet Inspection), Application Visibility and Control (AVC), Network Virus and Malware Scanning, Sandbox, Data Loss Prevention (DLP), DDoS: Distributed Denial of Service) mitigation and transport layer security (TLS) may indicate (or provide) services such as proxy.

In addition, in this specification, Advanced Inspection/Action may indicate that, like the I2NSF information model for the NSF facing interface, the security function calls other security functions for further inspection based on the self-test result. have.

In addition, in this specification, the NSF capability information (or NSF profile) indicates the ability to perform a check of the associated NSF instance. Each NSF instance has its own NSF capability information that specifies the type of security service it provides and resource capacity.

In addition, in this specification, a data model refers to an expression of a concept of interest to an environment in a form dependent on a data store, a data definition language, a query language, an implementation language, and a protocol.

In addition, in the present specification, the information model refers to an expression of a concept of interest in the environment in a form independent of a data storage, a data definition language, a query language, an implementation language, and a protocol.

In an embodiment of the present invention, an NSF instance may be registered through a registration interface between the security controller and the developer management system. In other words, depending on the security requirements of the system, NSF may be required. The security controller requests registration of the required NSF instance, and the developer management system can create/register the NSF instance and notify the security controller through the registration interface. It will be described with reference to the drawings below.

3 is a flowchart illustrating a method of registering an NSF instance through a registration interface as an embodiment to which the present invention is applied.

Referring to FIG. 3, the security controller transmits an instantiation request message to the developer management system (S301). The security controller and developer management system represent the components of the I2NSF framework described in FIG. 2 above.

Upon receiving the instantiation request message from the security controller, the developer management system can create an NSF instance for the requested NSF. For example, prior to step S301, the security controller may recognize a set of capabilities (ie, NSF capability information or NSF profile) required in the current system or a signature of a specific NSF. In addition, the security controller may transmit an instantiation request message including the recognized information to the developer management system. The developer management system may match the received information with the NSF based on the information model definition, and create an NSF instance that matches the received information.

Alternatively, the security controller may transmit a de-instantiation request message to the developer management system. Upon receiving the de-instantiation request message from the security controller, the developer management system can remove the NSF instance.

For example, prior to step S301, the security controller may recognize a set of unnecessary capabilities (ie, NSF access (or access) information) or a signature of a specific NSF in the current system. The security controller may transmit a de-instantiation request message including the recognized information to the developer management system. The developer management system may match the received information with the NSF based on the capability information model definition, and remove the NSF instance that matches the received information.

The security controller receives a registration message for registering an NSF instance from the developer management system (S302). In this case, the security controller can add the NSF instance to the system's list of available NSF instances after receiving the registration message.

If the security controller transmits a de-instantiation request message rather than an instantiation request message in step S301, the security controller may receive a deletion message from the developer management system. In this case, the security controller can remove the NSF instance from the system's list of available NSF instances.

Also, in one embodiment, the developer management system may register an NSF instance. Specifically, some NSFs may be required by default depending on the security requirements of the system. In this case, the developer management system can create these default NSF instances without the request of the security controller. After creating the NSF instances, the developer management system can notify the security controller of the NSF instance (or information related to the NSF instance) through the registration interface.

In addition, in one embodiment, a request for an NSF instance with necessary security functions may be performed through the registration interface. For example, an NSF instance can be created that provides advanced checks/actions triggered by other NSFs through the registration interface. That is, in the I2NSF framework, the NSF can trigger another type of NSF for advanced security inspection of traffic. At this time, the next NSF may be determined by the current NSF's test result and the I2NSF user policy. However, if there is no NSF instance that can provide advanced checks/actions triggered by the previous NSF, the security controller can create an NSF instance by making a request to the developer management system through the registration interface.

In addition, in an embodiment, the I2NSF user may request a security policy from a security controller and require a series of security functions to enforce the security policy. In addition, if the NSF triggers other types of NSFs for advanced security checks on certain traffic, you may also need some security features required to perform advanced security checks. If the security controller does not have an NSF instance registered with the requested function, the security controller can request a new NSF instance that can provide the required functionality to the developer management system. Upon receiving such a request, the developer management system can first retrieve an inventory of NSF instances with the required functionality. If the developer management system does not find an NSF instance, it can create a new NSF instance using the necessary security functions and register the created NSF instance with the security controller.

In addition, in an embodiment, a necessary NSF instance may be created to enforce a security policy rule received from an I2NSF user. That is, in the I2NSF framework, the I2NSF user can determine the security services required for the system. If there is no NSF instance to enforce the security policy requested by the I2NSF user, the security controller can create the necessary NSF instance by making a request to the developer management system through the registration interface.

Also, in one embodiment, NSF instances that are no longer needed may be deleted. That is, in the I2NSF framework, users can determine unnecessary security services in the system. Alternatively, various types of NSF instances may be executed in the I2NSF framework, and some types of NSF instances may no longer be required according to dynamic changes in security policies to be performed in the system. In this case, the security controller can delete the existing instance by requesting the developer management system to destroy the NSF instance through the registration interface.

Also, in one embodiment, the NSF instance may be updated. After the NSF instance is registered in the I2NSF framework, the function of the NSF instance can be changed. These changes must be communicated to the security controller. To do this, the developer management system can update some NSF instances and notify the security controller of the update through the registration interface.

4 is a diagram illustrating an information model of a registration interface according to an embodiment of the present invention.

The conventional I2NSF registration interface was used only when registering a new NSF instance in the security controller. However, in an embodiment of the present invention, to support NSF instantiation/de-instantiation at any time, an information model capable of extending its utilization is proposed.

The information model proposed in this embodiment describes information to be exchanged through a registration interface for functionality. In particular, in the registration interface, the NSF profile (i.e., the capability of the NSF) must be clarified so that the components of the I2NSF framework can exchange function sets in a standardized manner, so in this embodiment, the information model of the NSF profile is define.

Specifically, referring to FIG. 4, the information model of the registration interface may include an instance management sub-model (or sub-model) and/or a registration sub-model. Instance management functions and/or registration functions may use NSF profiles to achieve their objectives. Here, the NSF profile represents a capability object that describes and/or defines the inspection capability that an NSF instance can provide.

That is, the creation/removal of the NSF instance may be performed based on the instance management submodel among the registration interface information models, and detailed information constituting the NSF profile may be defined based on the registration submodel.

NSF Instance Management Mechanism

5 is a diagram illustrating an instance management sub-model according to an embodiment of the present invention.

5, the security controller of the I2NSF framework may perform an instantiation/re-instantiation request and/or a deinstantiation request for instance management of NSF.

Referring to FIG. 5A, the security controller may transmit an instantiation/re-instantiation request message to the developer management system if necessary. In this case, the instantiation/re-instantiation request message may include NSF capability information. Upon receiving a request from the security controller, the developer management system may create a corresponding NSF instance based on the NSF capability information, and transmit a response message including information related to the processing result to the security controller.

Referring to FIG. 5B, the security controller may transmit a de-instantiation request message to the developer management system if necessary. In this case, the de-instantiation request message may include NSF access information. Upon receiving the request from the security controller, the developer management system may remove the NSF instance based on the NSF access information and send a response message including information related to the processing result to the security controller.

NSF Registration Mechanism

6 is a diagram illustrating a registration sub-model according to an embodiment of the present invention.

Referring to FIG. 6, the developer management system may transmit (or create) a registration message (or NSF registration message, NSF instance registration message) to the security controller in order to register a new NSF instance. In this case, the registration message may include at least one of NSF capability information, NSF access information, and NSF role-based access control list (ACL).

The NSF capability information indicates the capability of testing a new NSF instance. And, the NSF access information represents information that enables network access to a new instance of another component. The NSF role-based ACL information specifies the NSF's access policy to determine whether to allow or deny access to the NSF entity according to the role assigned to the entity. The detailed information model of NSF capability information, NSF access information, and NSF role-based ACL information will be described in detail later.

After the above registration process, the I2NSF capability interface can control and monitor newly registered NSF instances.

NSF Access Information

NSF access information represents information required to perform communication with the NSF. In one embodiment of the present invention, the NSF access information is an Internet Protocol version 4 (IPv4) address, an Internet Protocol version 6 (IPv6) address, a port number, and/or a supported transport protocol. It may include.

The transport protocols supported here are, for example, Virtual Extensible LAN (VXLAN), Generic Protocol Extension (VXLAN-GPE), Generic Route Encapsulation (GRE), It may include Ethernet and the like.

The NSF access information represents the signature (or unique identifier) of the NSF instance within the overall system (or NSF instance list). NSF access information can be used to identify a specific NSF instance.

NSF Capability Information (or the capability of an NSF instance)

7 is a diagram illustrating an NSF profile, according to an embodiment of the present invention.

Referring to FIG. 7, an NSF profile (or NSF capability information) indicating the inspection capability of an NSF instance may include capability objects of various NSF instances.

Specifically, the NSF profile (or NSF capability object) is at least one of network security capabilities (Network-Security Capabilities), content security capabilities (Content-Security Capabilities), attack mitigation capabilities (Attack Mitigation Capabilities), and performance capabilities. It may include.

Here, the network security capability refers to the ability to inspect and process network traffic using a predefined security policy. Content Security Capability Represents the capability to analyze the content of traffic transmitted from the application layer. In addition, the attack mitigation ability indicates the ability to detect and mitigate various types of network attacks.

Performance capabilities and role-based ACLs are described in detail below.

Performance Capabilities

FIG. 8 is a diagram schematically illustrating performance capability information according to an embodiment of the present invention.

Referring to FIG. 8, performance capability (or performance capability) information may include a Processing and/or Bandwidth field (or information). Here, the performance capability information indicates the processing capability of the NSF.

The performance capability information may be used to determine whether the NSF is in a congestion state by comparing the information with the workload currently in charge of the NSF. In addition, the performance capability information can be used to specify the available amount of each type of resource, such as the capability available in NSF.

In addition, the processing information indicates the usable processing power of the NSF. Bandwidth indicates information on the amount of available network in two cases: outbound and inbound. The processing information and bandwidth information can be used to request an NSF instance (or instantiation) by the security controller.

The registration interface proposed in the present specification can control the use and restriction of the created instance, and can make an appropriate request according to the status.

Role-based Access Control List (ACL)

The role-based ACL information may specify the access policy of the NSF to determine whether to allow or deny access to the NSF entity according to the role assigned to the entity. Each NSF can be associated with a role-based ACL to determine whether to allow or deny an entity's access request.

9 and 10 are diagrams illustrating a role-based access control list (ACL) according to an embodiment of the present invention.

9, a role-based ACL may include one or more role IDs. Here, the role ID represents information used to identify the role of an entity (eg, administrator, developer, etc.).

Referring to FIG. 10, each role ID included in the role-based ACL may include access types classified as allow/deny. That is, the role-based ACL may be composed of a set of access types allowed or denied by each role ID. Here, the access type may be used to identify a specific type of access request, such as NSF rule configuration, NSF rule update, and/or NSF monitoring.

Hereinafter, a YANG data model for the I2NSF registration interface between the security controller and the developer management system will be described. In this specification, a simplified graphical representation of the data model is used. The meaning of symbols in these diagrams is as follows.

-Square brackets "[" and "]" enclose the list key.

-Among the abbreviations in front of the data node name, "rw" means read-write configuration and "ro" means read-only status data.

-Among the symbols following the data node name, "?" means an optional node, and "*" means a list and/or a leaf-list.

-Parentheses enclose choice and case nodes, and case nodes are indicated by colons (":").

-Ellipses ("...") indicate the contents of subtrees that are not displayed.

Registration Interface

11 is a diagram illustrating a high-level YANG data model of a registration interface according to an embodiment of the present invention.

Referring to FIG. 11, the high-level YANG data model of the I2NSF registration interface may include a registration request field (or object, information) and an instance management request field (or object, information). In this embodiment, the I2NSF system has the architecture of the I2NSF system described above in FIG. 1 or 2. In addition, the object/field/information included in the YANG data model shown in FIG. 11 and the relationship therebetween may be described by the content shown in FIG. 11 and/or the content described above with reference to FIGS. 3 to 10. In FIGS. 1 to 10, descriptions overlapping with those described above will be omitted.

Registration Request

12 is a diagram illustrating a high-level YANG data model of a registration request according to an embodiment of the present invention.

In an embodiment of the present invention, the registration request field of FIG. 11 described above may be extended as shown in FIG. 12. Looking at, the registration request (or registration request object/field/information) may include capability information of a newly created NSF to inform the security controller of its capability. In addition, the registration request may also include network access information allowing the security controller to access the NSF.

In this embodiment, the I2NSF system has the architecture of the I2NSF system described above in FIG. 1 or 2. In addition, the object/field/information included in the YANG data model shown in FIG. 12 and the relationship therebetween may be described by the content shown in FIG. 12 and/or the content described above with reference to FIGS. 3 to 10. In FIGS. 1 to 10, descriptions overlapping with those described above will be omitted.

Instance Management Request

13 is a diagram illustrating a high-level YANG data model of an instance management request according to an embodiment of the present invention.

In an embodiment of the present invention, the instance management request field of FIG. 11 described above may be extended as shown in FIG. 13. Looking at, the instance management request field may include an instantiation request, a deinstanciation request, and/or an updating request field (or object, information). The instantiation request can be used to request the creation of a new NSF instance using NSF capability information specifying the required NSF capability information. The de-instantiation request can be used to remove an existing NSF using NSF access information. The update NSF request can be used to update existing NSf information with NSF capabilities.

In this embodiment, the I2NSF system has the architecture of the I2NSF system described above in FIG. 1 or 2. In addition, the object/field/information included in the YANG data model shown in FIG. 13 and the relationship therebetween may be explained by the content shown in FIG. 13 and/or the content described in FIGS. 3 to 10 above. In FIGS. 1 to 10, descriptions overlapping with those described above will be omitted.

NSF Capability Information

14 is a diagram illustrating a high-level YANG data model of NSF capability information according to an embodiment of the present invention.

In an embodiment of the present invention, the NSF capability information field (or object, information) of FIGS. 12 and 13 described above may be extended as shown in FIG. 14. Looking at, the NSF capability information field may include an I2NSF capability field (or object, information), and a performance capability field (or object, information).

In this embodiment, the I2NSF system has the architecture of the I2NSF system described above in FIG. 1 or 2. In addition, the object/field/information included in the YANG data model shown in FIG. 14 and the relationship therebetween may be explained by the content shown in FIG. 14 and/or the content described in FIGS. 3 to 10 above. In FIGS. 1 to 10, descriptions overlapping with those described above will be omitted.

NSF Access Information

15 is a diagram illustrating a high-level YANG data model of NSF access information according to an embodiment of the present invention.

In an embodiment of the present invention, the NSF access information field (or object, information) of FIGS. 12 and 13 described above may be extended as shown in FIG. 15. Looking at, the NSF access information field may include an NSF address field (or object, information), and an NSF port address field (or object, information).

In this embodiment, the I2NSF system has the architecture of the I2NSF system described above in FIG. 1 or 2. In addition, the object/field/information included in the YANG data model shown in FIG. 15 and the relationship therebetween may be described by the content shown in FIG. 15 and/or the content described with reference to FIGS. 3 to 10 above. In FIGS. 1 to 10, descriptions overlapping with those described above will be omitted.

NSF Performance Capability

16 is a diagram illustrating a high-level YANG data model of NSF performance capability according to an embodiment of the present invention.

In an embodiment of the present invention, the NSF performance capability field (or object, information) of FIG. 14 described above may be extended as shown in FIG. 15. Looking at, the NSF performance capability field may include a processing field (or object, information), and a bandwidth field (or object, information). When the security controller requests the developer management system to create a new NSF instance, the performance capability can be used to specify the performance requirements of the new instance.

In this embodiment, the I2NSF system has the architecture of the I2NSF system described above in FIG. 1 or 2. In addition, the object/field/information included in the YANG data model shown in FIG. 16 and the relationship therebetween may be described by the content shown in FIG. 16 and/or the content described above with reference to FIGS. 3 to 10. In FIGS. 1 to 10, descriptions overlapping with those described above will be omitted.

Role-Based Access Control List (ACL)

17 is a diagram illustrating a high-level YANG data model of a role-based ACL according to an embodiment of the present invention.

In an embodiment of the present invention, the high-level YANG data model of the registration interface may include a role-based ACL as shown in FIG. 17.

In this embodiment, the I2NSF system has the architecture of the I2NSF system described above in FIG. 1 or 2. In addition, the object/field/information included in the YANG data model shown in FIG. 17 and the relationship between them may be described by the content shown in FIG. 17 and/or the content described in FIGS. 3 to 10 above. In FIGS. 1 to 10, descriptions overlapping with those described above will be omitted.

YANG module

18 is a diagram illustrating a data model of an I2NSF registration interface according to an embodiment of the present invention.

In an embodiment of the present invention, a YANG module for an information model of data required for a registration interface between a security controller and a developer management system may be as shown in FIG. 17.

In this embodiment, the I2NSF system has the architecture of the I2NSF system described above in FIG. 1 or 2. In addition, the object/field/information included in the YANG module shown in FIG. 18 and the relationship therebetween may be described by the content shown in FIG. 18 and/or the content described above with reference to FIGS. 3 to 10. In FIGS. 1 to 10, descriptions overlapping with those described above will be omitted.

XML example of registration interface data model

19 is a diagram illustrating XML output for a registration interface according to an embodiment of the present invention.

Referring to FIG. 19, an IDS NSF may be registered using a VoIP/VoLTE security capability through a registration interface. The configuration XML for the above-described registration interface is as shown in FIG. 19.

In this embodiment, the I2NSF system has the architecture of the I2NSF system described above in FIG. 1 or 2. In addition, the object/field/information included in the YANG module shown in FIG. 19 and the relationship therebetween may be described by the content shown in FIG. 19 and/or the content described above with reference to FIGS. 3 to 10. In FIGS. 1 to 10, descriptions overlapping with those described above will be omitted.

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

Referring to FIG. 20, the network device 2000 includes a processor (processor, 2010), a memory (memory, 2020), and a communication module (communication module, 2030).

The processor 2010 implements the functions, processes and/or methods proposed in FIGS. 1 to 19 above. The memory 2020 is connected to the processor 2010 and stores various pieces of information for driving the processor 2010. The communication module 2030 is connected to the processor 2010 and transmits and/or receives a wired/wireless signal.

The memory 2020 may be inside or outside the processor 2010, and may be connected to the processor 2010 by various well-known means.

The embodiments described above are those in which components and features of the present invention are combined in a predetermined form. Each component or feature should be considered optional unless explicitly 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 constitute an embodiment of the present invention by combining some components and/or features. The order of operations described in the embodiments of the present invention 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 obvious that the embodiments may be configured by combining claims that do not have an explicit citation relationship in the claims or may be included as new claims by amendment after filing.

The embodiment according to the present invention may be implemented by various means, for example, hardware, firmware, software, or a combination thereof. In the case of implementation by hardware, an embodiment of the present invention is one or more ASICs (application specific integrated circuits), DSPs (digital signal processors), DSPDs (digital signal processing devices), PLDs (programmable logic devices), FPGAs ( field programmable gate arrays), processors, controllers, microcontrollers, microprocessors, etc.

In addition, in the case of implementation by firmware or software, an embodiment of the present invention is implemented in the form of modules, procedures, functions, etc. that perform the functions or operations described above, and is stored in a recording medium that can be read through various computer means. Can be recorded. Here, the recording medium may include a program command, a data file, a data structure, or the like alone or in combination. The program instructions recorded on the recording medium may be specially designed and configured for the present invention, or may be known and usable to those skilled in computer software. For example, the recording medium is a magnetic medium such as a hard disk, a floppy disk, and a magnetic tape, an optical medium such as a compact disk read only memory (CD-ROM), a digital video disk (DVD), and a floppy disk. Magnetic-Optical Media such as a floptical disk, and a hardware device specially configured to store and execute program instructions such as ROM, RAM, flash memory, and the like. Examples of the program instructions may include not only machine language codes such as those produced by a compiler but also high-level language codes that can be executed by a computer using an interpreter or the like. Such a hardware device may be configured to operate as one or more software modules to perform the operation of the present invention, and vice versa.

In addition, the device or terminal according to the present invention may be driven by a command that causes one or more processors to perform the functions and processes described above. For example, such commands may include interpreted commands such as script commands such as JavaScript or ECMAScript commands, executable code, or other commands stored in a computer-readable medium. Further, the device according to the present invention may be implemented in a distributed manner over a network, such as a server farm, or may be implemented in a single computer device.

In addition, a computer program (also known as a program, software, software application, script, or code) mounted on the device according to the present invention and executing the method according to the present invention includes a compiled or interpreted language or a priori or procedural language. It can be written in any form of programming language, and can be deployed in any form, including standalone programs, modules, components, subroutines, or other units suitable for use in a computer environment. Computer programs do not necessarily correspond to files in the file system. A program may be in a single file provided to the requested program, or in multiple interactive files (e.g., files that store one or more modules, subprograms, or portions of code), or part of a file that holds other programs or data. (Eg, one or more scripts stored within a markup language document). The computer program may be deployed to run on one computer or multiple computers located at one site or distributed across a plurality of sites and interconnected by a communication network.

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

Above, the above-described preferred embodiments of the present invention are disclosed for the purpose of illustration, and those skilled in the art improve and change various other embodiments within the technical spirit and scope of the present invention disclosed in the appended claims below. , Substitution or addition may be possible.

Claims (9)

In a security management system that manages a network security function (NSF) through a registration interface, a method performed by a security controller is:
A first request message for requesting instantiation of a first NSF performing a security function requested by the security management system is transmitted to a developer's management system, and the first request message Contains a profile or signature of the first NSF;
Receiving a registration message from the developer management system instructing registration of an NSF instance corresponding to the first NSF in response to the first request message; And
Based on the registration message, registering an NSF instance for the first NSF in a list of NSF instances allowed in the security management system; including,
The NSF instance is generated by corresponding NSF information through an information model preset in a developer management system, based on the profile or the signature.
delete delete The method of claim 1,
Transmitting a second request message for de-instantiation of a second NSF for performing a security function not required in the security management system to the developer management system,
According to the second request message, the method characterized in that the NSF instance corresponding to the second NSF is deleted from the list of NSF instances allowed in the security management system. The method of claim 1,
The registration message is provided to the NSF according to NSF capability information indicating the security capability of the NSF instance, NSF access information used for network access to a new instance, or a role assigned to an entity. A method including at least one of NSF role-based access control list (ACL) information specifying an access policy of NSF in order to determine whether to allow access to the entity. The method of claim 5,
The NSF capability information includes at least one of a network-security capability field, a content-security capability field, an attack mitigation capability field, or a performance capability. . The method of claim 6,
The method of claim 1, wherein the performance capability includes processing information and bandwidth information. The method of claim 7,
The role-based ACL information includes one or more role IDs used for role identification of the entity,
The role ID includes one or more access types used to identify a specific type of access request. In the security controller (Security Controller) for controlling a security management system that manages a network security function (NSF) through a registration interface (Registration Interface),
A communication unit for wireless or wired communication; And
Including a processor functionally connected to the communication unit,
The processor,
A first request message for requesting instantiation of a first NSF performing a security function requested by the security management system is transmitted to a developer's management system, and the first request message Contains a profile or signature of the first NSF,
In response to the first request message, a registration message instructing registration of an NSF instance corresponding to the first NSF is received from the developer management system,
Based on the registration message, the NSF instance for the first NSF is registered in the list of NSF instances allowable in the security management system,
The NSF instance is generated by corresponding NSF information through an information model preset in a developer management system, based on the profile or the signature.

Images