+

WO2018169292A1 - Procédé et système pour fournir un service de sécurité et dispositif associé - Google Patents

Procédé et système pour fournir un service de sécurité et dispositif associé Download PDF

Info

Publication number
WO2018169292A1
WO2018169292A1 PCT/KR2018/002955 KR2018002955W WO2018169292A1 WO 2018169292 A1 WO2018169292 A1 WO 2018169292A1 KR 2018002955 W KR2018002955 W KR 2018002955W WO 2018169292 A1 WO2018169292 A1 WO 2018169292A1
Authority
WO
WIPO (PCT)
Prior art keywords
policy
security
field
rule
information
Prior art date
Application number
PCT/KR2018/002955
Other languages
English (en)
Korean (ko)
Inventor
정재훈
김형식
김은수
오상학
Original Assignee
성균관대학교 산학협력단
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 성균관대학교 산학협력단 filed Critical 성균관대학교 산학협력단
Publication of WO2018169292A1 publication Critical patent/WO2018169292A1/fr

Links

Images

Classifications

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

Definitions

  • the present invention relates to a system for providing a security service, and more particularly to an interface of a system for providing a security service.
  • NFV Network Functions Virtualization
  • An object of the present invention is to propose a data model for an interface of a system for providing a security service.
  • a data communication method of an I2NSF user device includes encoding security policy data for a security service; And forwarding the security policy data to a security controller via a consumer-facing interface, wherein the security policy data includes a policy lifecycle field that includes a lifecycle of the security policy, and a rule of the security policy. It may include a policy rule field and an action field including an action to be performed when the rule is matched.
  • the encoding of the security policy data may be performed using a YANG data modeling language.
  • an I2NSF user device includes a communication module for communicating data; And a processor for controlling the communication module, the processor encoding: security policy data for a security service; And transmitting the security policy data to a security controller through a consumer-facing interface, wherein the security policy data includes a policy lifecycle field including a lifecycle of the security policy, a policy rule field including a rule of the security policy, and It may include an action field including an action to be performed when the rule is matched.
  • the policy lifecycle field may include policy lifecycle ID information identifying the policy lifecycle field, expiration event information indicating an event that causes the security policy to expire, and an indication of when the security policy expires. Expiration time information may be included.
  • the policy rule field may include policy rule ID information identifying the policy rule field, rule name information indicating a name of the rule, and policy date information indicating a date when a rule of the security policy is created. can do.
  • the policy rule field may further include service information indicating a service for performing a network security function (NSF) to manage a security attack.
  • NSF network security function
  • the policy rule field may further include condition information indicating an inspection condition to be applied to a packet or traffic by a network security function (NSF) for security inspection.
  • NSF network security function
  • the operation field may include inflow operation information indicating a configuration of an inflow operation and outflow operation information indicating a configuration of an outflow operation.
  • the configuration of the inflow operation may include at least one of a permit, a mirror, or a log, and the configuration of the leakage operation may include redirection.
  • high-level security management can be provided by proposing a design of a generic security management architecture in order to support flexible and efficient security policies in NSF.
  • FIG 1 illustrates an I2NSF (Interface to Network Security Functions) system according to an embodiment of the present invention.
  • I2NSF Interface to Network Security Functions
  • FIG 2 illustrates the architecture of an I2NSF system in accordance with another embodiment of the present invention.
  • FIG. 3 illustrates a hairdressing model for a consumer-facing interface of an I2NSF system in accordance with an embodiment of the present invention.
  • FIG. 4 illustrates a generic data model for a security service according to one embodiment of the invention.
  • FIG. 5 illustrates a YANG data model for a security service according to an embodiment of the present invention.
  • FIG. 6 illustrates a generic data model for a security service according to another embodiment of the present invention.
  • FIG. 7 and 8 illustrate a YANG data model for a security service according to another embodiment of the invention.
  • FIG. 9 illustrates a generic data model for a security service according to another embodiment of the present invention.
  • FIG. 10 illustrates a YANG data model for a security service according to another embodiment of the present invention.
  • FIG. 11 illustrates XML output for a VoIP service according to one embodiment of the invention.
  • FIG. 12 illustrates a block diagram of a network device according to an embodiment of the present invention.
  • FIG. 12 illustrates a block diagram of a network device according to an embodiment of the present invention.
  • FIG. 13 is a flowchart of a data communication method of a network device via a consumer-facing interface according to an embodiment of the present invention.
  • I2NSF Interface to Network Security Functions
  • the purpose of the I2NSF is to define a standardized interface for heterogeneous network security function (NSF) provided by a number of security solution vendors.
  • NSF network security function
  • the present specification proposes a YANG data model for security management based on I2NSF using NFV (Network Function Virtualization).
  • NFV Network Function Virtualization
  • the present specification proposes a security management architecture based on the I2NSF framework.
  • the security management architecture may include instance (s) of NSF (s) of the lowest layer of the I2NSF user, Security Management System, and / or framework.
  • the security management system may include a security controller and a developer's management system.
  • the security controller may include a Security Policy Manager and an NSF Capability Manager.
  • the present specification proposes a data model for performing a mission for a security service (eg, VoIP-VoLTE) in an I2NSF security management system.
  • a security service eg, VoIP-VoLTE
  • the present invention has the following objects / effects.
  • Application Logic A component of the security management architecture that creates a user perspective security policy for blocking or mitigating security attacks.
  • Policy Updater A component that delivers a user perspective security policy to a security controller. User perspective policies are retrieved from the application logic.
  • Security Policy Manager A component that maps a user perspective security policy received from a policy updater to a low level security policy and vice versa.
  • NSF Capability Manager A component that stores NSF capabilities registered by the developer management system through a registration interface and shares them with the Security Policy Manager to create a corresponding low level security policy.
  • Event Collector A component that receives events from a security controller, which is used to update (or create) a user perspective policy in application logic.
  • Network Security Function Means a function or device for the specific handling of a received packet.
  • the NSF may operate at various layers of various protocol stacks (eg, network layer or other Open System Interconnection (OSI) layer, etc.).
  • OSI Open System Interconnection
  • NSFs For example, as examples of NSFs, firewalls, intrusion prevention systems (IPS) / intrusion detection systems (IDS), deep packet inspection (DPI), application visibility and Application Visibility and Control (AVC), Network Virus and Malware Scanning, Sandbox, Data Loss Prevention (DLP), Distribute Denial of Service (DDoS) mitigation, A transport layer security (TLS) proxy, anti-spoofing, and the like may be included.
  • IPS intrusion prevention systems
  • IDPS deep packet inspection
  • AVC application visibility and Application Visibility and Control
  • AVC Application Visibility and Control
  • DLP Data Loss Prevention
  • DLP Distribute Denial of Service
  • TLS transport layer security
  • anti-spoofing and the like
  • the NSF according to an embodiment of the present invention may be implemented in any of the above-described examples, and various types of NSF may be used. In addition, multiple NSFs of the same type may be implemented. In addition, the NSF according to the present invention may be implemented by combining any one or more
  • the I2NSF framework allows users of an I2NSF system (e.g., an application, overlay or cloud network management system, or enterprise network administrator or management system) to inform the I2NFS system which I2NSF functions should be applied to which traffic (or traffic patterns). Requires a standard interface.
  • the I2NSF system can recognize this standard interface as a set of security rules for monitoring and controlling the behavior of different traffic.
  • the I2NSF framework also provides a standard interface for monitoring flow-based security functions where users are hosted and managed by different administrative domains.
  • FIG 1 illustrates an I2NSF (Interface to Network Security Functions) system according to an embodiment of the present invention.
  • I2NSF Interface to Network Security Functions
  • FIG. 1 is a basic architecture / framework of an I2NSF system, which is illustrated in terms of a network operator management system. Thus, FIG. 1 does not assume any particular management architecture for NSFs or how NSFs are managed (at the developer side). In particular, the network operations management system does not participate in NSF data plane activity. In general, all I2NSF interfaces may require at least mutual authentication and authorization for use.
  • an I2NSF system includes an I2NSF user, a Network Operator Management System, a Developer's Management System, and / or at least one Network Security Function (NSF).
  • NSF Network Security Function
  • the I2NSF user communicates with the network operations management system via the I2NSF Consumer-Facing Interface.
  • the network operations management system communicates with the NSF (s) via an I2NSF NSF-Facing Interface.
  • the developer management system communicates with the network operations management system through the I2NSF Registration Interface.
  • each component (I2NSF component) and each interface (I2NSF interface) of the I2NSF system will be described.
  • An I2NSF user requests information (eg, information from NSF) from another I2NSF component (eg, network operations management system) and / or a security service (eg, network security) provided by another I2NSF component (eg, developer management system). Service) is an I2NSF component.
  • the I2NSF user may be an overlay network management system, an enterprise network administrator system, another network domain administrator, or the like. I2NSF users may be referred to as I2NSF clients.
  • the object performing the role assigned to this I2NSF user component may be referred to as an I2NSF consumer.
  • An example of an I2NSF consumer is the need to dynamically inform an underlay network to allow, rate-limit, or reject flow based on a particular field of a packet over a time span.
  • Video-conference network manager, enterprise network administrators and management systems that need to request provider networks to enforce specific I2NSF policies for specific flows,
  • An IoT management system may be included that sends a request to the underlay network to block flows that match a set of specific conditions.
  • I2NSF users can create and deploy high-level security policies. Specifically, the I2NSF user needs to use a network security service to protect network traffic from various malicious attacks. To request this security service, the I2NSF user can create a user perspective security policy for the security service he wants and notify the network operations management system.
  • the I2NSF user in preparing the user perspective security policy, the I2NSF user considers the types of NSF (s) required to realize a security service or security policy rule configuration for each NSF (s). You can't.
  • the I2NSF user may be informed of security event (s) occurring in the underlying NSF (s) by the network operations management system.
  • security event s
  • I2NSF users can identify new attacks and update (or create) user perspective security policies to cope with the new attacks.
  • I2NSF users can define, manage, and monitor security policies.
  • a network operations management system is a component that acts as a collection and distribution point for providing security, monitoring, and other operations.
  • the network operations management system may correspond to a security controller or may be a component including a security controller.
  • Such a network operations management system may be managed by a network operator and may be referred to as an I2NSF management system.
  • network operations management systems or security controllers
  • the network operations management system may receive the user perspective security policy from the I2NSF user and then first determine the type of NSF (s) required to enforce the policy required by the I2NSF user.
  • the network operations management system can then create a low-level security policy for each NSF (s) required.
  • the network operations management system may set the generated low level security policy to each NSF (s).
  • the network operations management system (or security controller) monitors the NSF (s) running in the I2NSF system, and provides various information about each NSF (s) (e.g., network access information and workloads). ), Etc.) can be maintained.
  • network operations management systems (or security controllers) can dynamically manage pools of NSF instances through dynamic life-cycle management of NSF instances with the help of developer management systems. have.
  • NSF is a logical entity or software component that provides security related services.
  • NFC eg, a firewall
  • the developer management system is an I2NSF component that sends information (eg, NSF's information) to other I2NSF components (eg, network operations management system) and / or provides security services (eg, network security services).
  • the developer management system may be referred to as Vendor's Management System.
  • An object performing a role assigned to such a developer management system may be referred to as an I2NSF producer.
  • the developer management system may be managed by a third-party security vendor that provides NSF (s) to network operators. There may be multiple developer management system (s) from various security vendors.
  • I2NSF consumer-facing interface (simply, consumer-facing interface (CFI))
  • the CFI is an interface to the user's I2NSF system, located between the I2NSF user and the network operations management system. By designing this, the I2NSF system can hide the details of the underlying NSF (s) and provide only an abstract view of the NSF (s) to the user.
  • This CFI can be used to allow different users of a given I2NSF system to define, manage, and monitor security policies for specific flows in an administrative domain.
  • User perspective security policies (or policy rules) created by I2NSF users may be communicated to the network operations management system via this CFI.
  • security alerts by the NSF (s) may be communicated from the network operations management system to the I2NSF user via this CFI.
  • NFI is an interface located between the network operations management system (or security controller) and the NSF (s).
  • NFI The main purpose of NFI is to provide a standardized interface for controlling and managing NSF (s) from various security solution vendors by decoupled security management techniques from NSF (s).
  • NFI is independent of the details of the NSF (s) (eg, vendor, form factor, etc.).
  • This NFI may be used to specify and monitor a flow-based security policy enforced by one or more NSFs.
  • the network operations management system may deliver a flow-based security policy to each flow-based NSF via an NFI interface in order to enforce a user perspective security policy by an I2NSF user.
  • flow-based NSF is an NSF that examines network flow according to a set of policies to enhance security characteristics.
  • This flow-based security by flow-based NSF means that packets are examined in the order in which they are received, and there is no modification to the packets according to the inspection process.
  • Interfaces for flow-based NSF can be classified as follows:
  • NSF Operational and Administrative Interface group of interfaces used by the I2NSF management system to program the operational state of the NSF; This interface group also includes administrative control functions. I2NSF policy rules represent one way of changing this interface group in a consistent manner. Since applications and I2NSF components need to dynamically control the behavior of the traffic they send and receive, much of the I2NSF effort is concentrated in this group of interfaces.
  • Monitoring Interface group of interfaces used by the I2NSF management system to obtain monitoring information from one or more selected NSFs; Each interface in this interface group can be a query or report based interface. The difference between the two is that the query based interface is used by the I2NSF management system to obtain the information, while the report based interface is used by the NSF to provide the information.
  • the functionality of this interface group can also be defined by other protocols such as SYSLOG and DOTS.
  • the I2NSF management system may take one or more actions based on the receipt of the information. This should be specified by the I2NSF policy rule. This interface group does not change the operational state of the NSF.
  • NFI may be developed using a flow-based paradigm.
  • a common trait of flow-based NSF is to process packets based on the content (eg header / payload) and / or context (eg session state and authentication state) of the received packet. This feature is one of the requirements for defining the behavior of an I2NSF system.
  • the I2NSF management system does not need to use all the functions of a given NSF, nor need to use all available NSFs.
  • this abstraction allows NSF features to be treated as building blocks by the NSF system.
  • developers are free to use the security features defined by NSF, which are vendor and technology independent.
  • I2NSF registration interface simple registration interface (RI)
  • RI is an interface located between the network operations management system and the developer management system. NSFs provided by different vendors may have different capabilities. Thus, in order to automate processes that take advantage of the different types of security capabilities offered by different vendors, it is necessary for vendors to have a dedicated interface for defining the functionality of their NSF. This dedicated interface may be referred to as an I2NSF Registration Interface (RI).
  • RI I2NSF Registration Interface
  • the NSF's capabilities can be preconfigured or dynamically retrieved through the I2NSF registration interface. If new features exposed to consumers are added to the NSF, the capabilities of those new features need to be registered in the I2NSF registry through this RI so that interested management and control entities know them. .
  • FIG. 2 illustrates the architecture of an I2NSF system in accordance with another embodiment of the present invention.
  • the I2NSF system of FIG. 2 illustrates the configuration of an I2NSF user and network operation management system more specifically than the I2NSF system of FIG. 1.
  • FIG. 2 descriptions overlapping with those described above in FIG. 1 will be omitted.
  • the I2NSF system includes an I2NSF user, a security management system, and an NSF instance layer.
  • the I2NSF user layer includes Application Logic, Policy Updater, and Event Collector as components.
  • the security management system layer includes a security controller and a developer management system.
  • the security controller of the security management system layer includes a security policy manager and an NSF capability manager as components.
  • the I2NSF user layer communicates with the security management system layer via a consumer-facing interface.
  • the policy updater and event collector of the I2NSF user layer communicate with the security controller of the security management system layer via a consumer-facing interface (CFI).
  • CFI consumer-facing interface
  • the security management system layer also communicates with the NFC instance layer via the NSF-Directional Interface (NFI).
  • NFI NSF-Directional Interface
  • the security controller of the security management system layer communicates with the NSF instance (s) of the NFC instance layer via an NSF-direct interface.
  • the developer management system of the security management system layer communicates with the security controller of the security management system layer through a registration interface (RI).
  • RI registration interface
  • the application logic can create a user perspective policy and send it to the security policy manager via CFI.
  • the security policy manager can map user perspective policies to multiple low-level policies at the security controller. After mapping, low level policy may be distributed to NSF (s) via NFI to be enforced at NSF (s). If an event occurs for the NSF to change the low level policy, the NSF may send an event to the security controller via the NFI.
  • the security controller then forwards the event through the CFI to the event collector.
  • the event collector sends the event to the application logic.
  • the application logic updates the current policy according to the event. The operation of each component will be described in detail below.
  • the I2NSF user layer of FIG. 2 the security controller component of the security management system layer, the developer management system component of the security management system layer, and the NSF instance layer are respectively the I2NSF user component, network operation management system component, and developer management system component of FIG. 1. And an NSF component.
  • the consumer-facing interface, the NSF-facing interface and the registration interface of FIG. 2 correspond to the consumer-facing interface, the NSF-facing interface and the registration interface of FIG. 1.
  • the I2NSF user layer includes three components: Application Logic, Policy Updater, and Event Collector. Each role and operation are described as follows.
  • Application logic is a component that creates a user perspective security policy.
  • the application logic receives an event for updating (or creating) a user perspective policy from an event collector and updates (or creates) a user perspective policy based on the collected event. After that, the user perspective policy is sent to the policy updater for distribution to the security controller.
  • the event collector receives the events sent by the security collector and sends them to the application logic. Based on this feedback, application logic can update (or create) a user perspective security policy.
  • each is a logical component, and may be implemented as one or a plurality of components in the I2NSF system.
  • it may be implemented by a single I2NSF user component as shown in FIG.
  • the security controller of the security management system layer includes two components: a security policy manager and an NSF capability manager. Each role and operation are described as follows.
  • the Security Policy Manager can receive user perspective policies from the policy updater through CFI and map these policies to multiple low-level policies. This low level policy relates to a given NSF capability registered with the NSF capability manager. In addition, the security policy manager may forward this policy to the NSF (s) via NFI.
  • the NSF capability manager can specify the capabilities of the NSF registered by the developer management system and share it with the security policy manager to create a low level policy associated with a given NSF capability. Each time a new NSF is registered, the NSF capability manager may request the developer management system to register the NSF's capabilities / capabilities in the management table of the NSF capability manager via the registration interface. The developer management system is another part of the security management system for registering new NSF capabilities as NSF capability managers.
  • each is a logical component, and may be implemented as one component in the I2NSF system.
  • the NSF instance layer includes NSFs. At this time, all NSFs are located in this NSF instance layer.
  • the security policy manager forwards the policy to the NSF (s) via NFI.
  • NFC can detect, block or mitigate malicious network traffic based on the received low level security policy.
  • the information model and data model can be used to define managed objects in network management. Despite the overlapped details, the information model and data model have different characteristics in terms of network management.
  • an information model In general, the main purpose of an information model is to model managed objects at the conceptual level, without relying on any particular implementation or protocol. To clarify the overall design, the information model must hide all protocol and implementation details that define the relationships between managed objects. Based on this, the information model can be implemented in different ways and can be mapped to different protocols. As such, the information model is protocol neutral. In general, an information model may be defined in an exemplary manner, using a natural language such as English. In addition, it may be desirable to use an object-oriented technique to describe the information model.
  • the data model is defined as a lower level of abstraction and provides many details.
  • the data model provides details on the specifications of the implementation and protocols, such as rules describing how managed objects are mapped to low-level protocol constructs. Because conceptual models can be implemented in a variety of ways, multiple data models can be derived from a single information model.
  • NFS such as a firewall, intrusion detection system (IDS), intrusion protection system (IPS), may also be provided as a virtual network function (VNF).
  • VNF virtual network function
  • This specification proposes an information model and a data model for implementing a security function based on NFV.
  • this specification proposes an information model and data model for an I2NSF consumer-facing interface (CFI), based on the I2NSF framework described above in FIGS. 1 and 2.
  • CFI I2NSF consumer-facing interface
  • the present specification proposes an information model and a data model for a security service in the security management architecture so that the security management architecture described above can support a flexible and effective security policy.
  • FIG. 3 illustrates a hairdressing model for a consumer-facing interface of an I2NSF system in accordance with an embodiment of the present invention.
  • the I2NSF system has the architecture of the I2NSF system described above in FIG. 1 or 2.
  • the uniform model of the embodiment of FIG. 3 provides an information model for the consumer-facing interface towards the security controller based on the requirements of the consumer-facing interface.
  • This information model defines the relationships between the various managed objects and those objects needed to build a consumer-facing interface.
  • This information model can be organized based on the “Event-Condition-Action” (ECA) policy model.
  • ECA policy model may be defined by the capability information model for I2NSF.
  • This capability information model corresponds to the security policy model of NSF-face interface and consumer-face interface.
  • I2NSF provides a consumer-facing interface that conveys user perspective security policy to the security controller for security enforcement in NSF.
  • This consumer-facing interface is created using a set of objects, each of which captures a unique set of information from the security manager (ie, I2NSF user) needed to express the security policy.
  • An object can have relationships with various other objects that represent a complete set of requirements.
  • the information model captures managed objects and the relationships between these objects.
  • the information model proposed in this document follows the requirements of the consumer-facing interface.
  • a data model representing an implementation of the proposed information model of a particular data representation language, is described separately below.
  • the policy model includes an event sub-model, a condition sub-model and an action sub-model. Each will be described below.
  • a policy object represents a mechanism for expressing a security policy by a security administrator (eg, an I2NSF user) using a consumer-facing interface forward to the security controller.
  • the policy will be implemented by the NSF.
  • the policy object contains some or all of the following information (fields):
  • This field identifies the name of the policy object.
  • Date This field indicates the date on which the policy object was created or last modified.
  • Multi-Tenancy Multi-tenancy environment information with a policy applied.
  • Rules within a policy may refer to sub-objects (eg, domains, tenants, roles, and users). This field may be either a reference to a multi-tenancy object defined elsewhere or a concrete object.
  • End-Group This field contains a list of logical entities in the business environment to which the security policy applies. This field may be referenced by condition objects (eg, source, destination, match) in the rule. This field may be either a reference to an end-group object or a concrete object defined elsewhere.
  • condition objects eg, source, destination, match
  • Threat-Feed This field indicates the threat feed, such as Botnet server, GeoIP, and malware signature. This information (field) may be referenced by the rule action object to directly execute threat mitigation.
  • Telemetry-Data This field indicates telemetry collection related information that the rule action object may refer to for collecting interest in telemetry information.
  • the telemetry collection related information may include what type of telemetry is collected, where the telemetry source is, where the telemetry information is transmitted, and the like.
  • Rule This field contains a list of rules. If the rule does not have user-defined precedence, any conflict must be resolved manually.
  • This field defines the owner of this policy. Only the owner has the authority to modify the contents of the policy.
  • a policy is a container of rules. To express a rule, the rule must have complete information such as where and when the policy will be applied. Rules are made by defining a set of managed objects and the relationships between them. Policy rules may relate to segmentation, threat mitigation, or the collection of telemetry data from NSFs in a network, which will be designated as a submodel of the policy model.
  • the rule object contains some or all of the following information (fields):
  • This field identifies the name of the rule object.
  • Date This field indicates the date on which the rule object was created or last modified.
  • Event This field contains information that determines whether or not a rule condition can be evaluated.
  • This field contains all the checking conditions to apply to the objective traffic.
  • Action This field identifies the action to be taken if a rule is matched. If no rule matches the traffic type, there is always an implicit action to drop the traffic.
  • This field identifies the priority assigned to this rule by the security administrator. This field helps in conflict resolution when two or more rules match a given traffic class.
  • the event object contains information related to scheduling the rule.
  • the rule may be activated based on a time calendar or security event that includes a threat level change.
  • the event object contains some or all of the following information (fields).
  • This field identifies the name of the event-map-group object.
  • Date This field indicates the date on which the event-map-group object was created or last modified.
  • Event-Type This field identifies whether the event that triggers policy enforcement is "ADMIN-ENFORCED", “TIME-ENFORCED” or "EVENT-ENFORCED”.
  • Time-Information This field repeats the time calendar for periodic enforcement or "BEGIN-TIME” and "END-Time” for one time enforcement. TIME) ".
  • Event-Map-Group This field contains a security event or threat map to determine when the policy needs to be activated. This may be a reference to an event-map-group object to be defined later.
  • This object represents an event map containing threat levels and security events used for dynamic policy enforcement.
  • the event-map-group object contains some or all of the following information (fields).
  • This field identifies the name of the event-map-group object.
  • Date This field indicates the date on which the event-map-group object was created or last modified.
  • Security-Events This field contains a list of security events used for the purpose of Security Policy definition.
  • Threat-map This field contains a list of threat levels used for security policy definition purposes.
  • This object represents the condition that the security manager wants to apply checks on traffic to determine whether a set of actions in a rule can be executed or not.
  • the condition object contains some or all of the following information (fields).
  • This field identifies the source of the traffic. This field may be a reference to one of the above-defined policy-endpoint-group, threat-feed or custom-list. This field may be a special object "all" that matches all traffic. This field may also be a telemetry-source for telemetry collection policy.
  • This field identifies the destination of the traffic. This may be a reference to one of the policy-endpoint-group, threat-feed, or custom-list defined above. This may be a special object "all" that matches all traffic. It may also be a telemetry-destination for the telemetry collection policy.
  • This field identifies the matching criteria used to evaluate whether the specified action needs to be performed. This may be one of a set of policy-endpoint-groups or traffic rules that identify a set of applications.
  • Match-Direction This field identifies the matching criteria used to evaluate whether the specified action needs to be done. This may be one of a set of policy-endpoint-groups or traffic rules that identify a set of applications.
  • This field identifies exception considerations when a rule is evaluated for a given communication. This may be a reference to a "policy-endpoint-group" object or a set of traffic matching criteria.
  • This object represents the action that the security manager wants to perform based on a particular traffic class.
  • the action object contains some or all of the following information (fields):
  • This field identifies the name of the action object.
  • Date This field indicates the date on which the action object was created or last modified.
  • Primary-Action This field identifies the action when the rule is matched by the NSF. Primary-Operations are "PERMIT”, “DENY”, “MIRROR”, “REDIRECT”, “RATE-LIMIT”, “TRAFFICCLASS” “,” AUTHENTICATE-SESSION “,” IPS “,” APP-FIREWALL “, or” COLLECT ".
  • the security administrator can also specify additional actions if the rules match.
  • the secondary-operation may be one of "LOG”, "SYSLOG” or "SESSION-LOG”.
  • Multi-tenancy is an important aspect of any application that enables multiple administrative domains to manage application resources.
  • An enterprise organization can have multiple tenants and departments, such as human resources (HR), finance and legal departments, and each tenant needs to manage its own security policy.
  • HR human resources
  • finance and legal departments each tenant needs to manage its own security policy.
  • Has To service providers tenants represent consumers who want to manage their own security policy.
  • This object defines a boundary within the security controller for policy management purposes. This object may vary depending on how the security controller is deployed and hosted. For example, if an enterprise hosts a security controller in their network, the domain may simply represent the enterprise. However, if a cloud service provider hosts a managed service, the domain may represent a single consumer of that provider. The multi-tenancy model can work in all these environments.
  • the policy-domain object contains some or all of the following information (fields):
  • This field identifies the name of the organization or customer that the policy-domain represents.
  • This field indicates the address of the organization or consumer.
  • This field indicates the contact information of the organization or consumer.
  • Date This field indicates the date on which this account was created or last modified.
  • Authentication-Method This field indicates the authentication method to be used for the policy-domain. This should be a reference to the 'Policy-Management-Authentication-Method' object.
  • This object defines an entity within an organization.
  • An entity can be a department or business unit within a corporate organization that wants to manage its own policy due to regulatory compliance or business reasons.
  • the policy-tenant object contains some or all of the following information (fields):
  • This field identifies the name of the department or division within the organization.
  • Date This field indicates the date on which this account was created or last modified.
  • This field identifies the domain to which the policy-tenant belongs. It must be a reference to a policy-domain object.
  • This object defines a set of permissions assigned to a user in an organization who wants to manage their own security policy. This object provides a convenient way of assigning policy users a set of permissions or job functions within an organization.
  • the policy-rule object contains some or all of the following information (fields):
  • This field identifies the name of the rule.
  • Date This field indicates the date this rule was created or last modified.
  • Access-Profile This field identifies the access profile for the role. Profiles may grant or deny access to a group of endpoints for policy management purposes, or restrict certain operations related to policy management.
  • Identity authenticates the security controller using credentials such as passwords or tokens to perform policy management.
  • the user can be an individual, system or application that requires access to the security controller.
  • the policy-user object contains some or all of the following information (fields):
  • This field identifies the user's name.
  • Date This field indicates the date this user was created or last modified.
  • Email This field indicates the user's email address.
  • Scope-Type This field identifies whether the user has domain-wide or tenant-wide privileges.
  • Scope-Reference This field must be a reference to either a policy-domain or a policy-tenant object.
  • Role This field must be a reference to a policy-role object that defines a specific permission.
  • This object represents the authentication schemes provided by the security controller.
  • This object contains some or all of the following information (fields):
  • This field identifies the name of this object.
  • Date This field indicates the date this object was created or last modified.
  • This field identifies the authentication method.
  • This authentication method may be password-based, token-based, certificate-based or single sign-on authentication.
  • Token-Server This field stores information about the server that validates the submitted token as a credential.
  • Certificate-Server This field stores information about the server that validates the submitted certificate as a credential.
  • This field stores information about the server that validates user credentials.
  • Policy endpoint groups are an important part of creating user configuration-based policies. Security administrators create and use this object to represent logical entities in their business environment to which the security policy applies.
  • This object represents the source of information for the tag.
  • Tags within a group must be mapped to corresponding contents in order to enforce the security policy.
  • the tag-source object contains some or all of the following information (fields):
  • This field identifies the name of this object.
  • Date This field indicates the date this object was created or last modified.
  • Tag-Type This field identifies the endpoint group type. This may be a user-group, an app-group, a device-group, or a location-group.
  • Tag-Source-Server This field identifies information related to the source of the tag, such as IP address and UDP / TCP port information.
  • Tag-Source-Application This field identifies the protocol used to communicate with the server, such as LDAP, Active Directory, or CMDB.
  • Tag-Source-Credentials This field identifies the credential information needed to access the server.
  • This object represents a group of users based on either tags or other information.
  • the user-group object contains some or all of the following information (fields):
  • This field identifies the name of this object.
  • Date This field indicates the date this object was created or last modified.
  • Group-Type This field identifies whether the user group is based on User-tag, User-names or IP-address.
  • Metadata-Server This field must be a reference to a metadata-source object.
  • Group-Member This field is a list of user-tags, user-names or IP addresses based on group-type.
  • Risk-Level This field indicates the importance or risk level of the endpoint to the security administrator for policy purposes.
  • the valid range may be 0 to 9.
  • This object represents a device group based on one of tags or other information.
  • the device group object contains some or all of the following information (fields):
  • This field identifies the name of this object.
  • Date This field indicates the date this object was created or last modified.
  • Group-Type This field identifies whether the device group is based on Device-tag, Device-names or IP-address.
  • Tag-Server This field must be a reference to a tag-source object.
  • Group-Member This field is a list of device-tags, device-names or IP addresses based on group-type.
  • Risk-Level This field indicates the importance or risk level of the endpoint to the security administrator for policy purposes.
  • the valid range may be 0 to 9.
  • This object represents a group of applications based on tags or other information.
  • the application-group object contains some or all of the following information (fields):
  • This field identifies the name of this object.
  • Date This field indicates the date this object was created or last modified.
  • Group-Type This field identifies whether the device group is based on App-tag, App-names or IP-address.
  • Tag-Server This field must be a reference to a tag-source object.
  • Group-Member This field is a list of app-tags, app-names or IP addresses based on group-type.
  • Risk-Level This field indicates the importance or risk level of the endpoint to the security administrator for policy purposes.
  • the valid range may be 0 to 9.
  • This object represents a group of locations based on either tags or other information.
  • the location-group object contains some or all of the following information (fields):
  • This field identifies the name of this object.
  • Date This field indicates the date this object was created or last modified.
  • Group-Type This field identifies whether the device group is based on Location-tag, Location-names or IP-address.
  • Tag-Server This field must be a reference to a tag-source object.
  • Group-Member This field is a list of location-tags, location-names or IP addresses based on group-type.
  • Risk-Level This field indicates the importance or risk level of the endpoint to the security administrator for policy purposes.
  • the valid range may be 0 to 9.
  • Threat protection plays an important role in overall security posture by reducing attack surfaces. This information may be provided in the form of threat feeds such as Botnet and GeoIP from third parties or external services.
  • This object represents threat servers such as Botnet servers and GeoIP.
  • the threat-feed object contains some or all of the following information (fields):
  • This field identifies the name of this object.
  • Date This field indicates the date this object was created or last modified.
  • Feed-Type This field identifies whether the feed type is IP address-based or URL-based.
  • Feed-Server This field identifies information about the feed provider, which may be an external server or a local server.
  • Feed-Priority This field indicates the feed priority level for resolving disputes when there are multiple feed sources.
  • the valid range can be 0 to 9.
  • This object represents a custom list created for the purpose of defining exceptions to threat feeds.
  • the organization may wish to allow certain exceptions to the list of threats obtained from third parties.
  • the custom-list object contains some or all of the following information (fields):
  • This field identifies the name of this object.
  • Date This field indicates the date this object was created or last modified.
  • List-Type This field identifies whether the list type is IP address-based or URL-based.
  • This field identifies a property of the list, such as a blacklist or whitelist.
  • List-Content This field contains content such as an IP address or URL name.
  • This object represents the information needed to detect malware.
  • This information may be provided from a local server or periodically uploaded from a third party.
  • This object contains some or all of the following information (fields):
  • This field identifies the name of this object.
  • Date This field indicates the date this object was created or last modified.
  • Signature-Server This field contains information about the server from which signatures can be downloaded periodically whenever an update is available.
  • File-Types This field contains a list of file types needed to scan for viruses.
  • Malware-Signatures This field contains a list of malware signatures or hash values.
  • Telemetry gives system administrators visibility of network activities that can be tapped for further security analysis, such as detecting potential vulnerabilities, malicious activities, and so on. provide visibility.
  • This object contains the information gathered for telemetry.
  • This object contains some or all of the following information (fields):
  • This field identifies the name of this object.
  • Date This field indicates the date this object was created or last modified.
  • Log-Data This field identifies whether log data needs to be collected.
  • Syslog-Data This field identifies whether Syslog data needs to be collected.
  • SNMP-Data This field identifies whether SNMP trap and alarm data need to be collected.
  • sFlow-Record This field identifies whether sFlow records need to be collected.
  • NetFlow-Record This field identifies whether NetFlow records need to be collected.
  • NSF-Stats This field identifies whether statistics need to be collected from the NSF dump.
  • This object contains information related to the telemetry source.
  • the source will be NSF in the network.
  • This object contains some or all of the following information (fields):
  • This field identifies the name of this object.
  • Date This field indicates the date this object was created or last modified.
  • Source-Type This field contains the type of NSF telemetry source: "NETWORK-NSF”, “FIREWALL-NSF”, “IDS-NSF”, “IPSNSF”, “PROXY-NSF or "OTHER-NSF”.
  • NSF-Credentials This field contains the user and password used to authenticate the NSF.
  • This field contains the time in milliseconds between each data collection. For example, a value of 5,000 means that data is streamed to the collector every 5 seconds. A value of zero means that data streaming is event-based.
  • Collection-Method This field contains a collection method that is PUSH-based or PULL-based.
  • Heartbeat-Interval This field contains the time in seconds that the source should transmit telemetry heartbeats.
  • QoS-Marking This field contains the DSCP value source masked on the generated telemetry packet.
  • the destination may be a collector that is part of an external system such as a security controller or SIEM.
  • This object contains some or all of the following information (fields):
  • This field identifies the name of this object.
  • Date This field indicates the date this object was created or last modified.
  • Collector-Source This field contains information such as the IP address and protocol (UDP or TCP) port number for the destination of the collector.
  • Collector-Credentials This field contains the username and password provided by the collector.
  • This field contains telemetry data encoding, which may be in schema form.
  • This field contains a streaming telemetry data protocol, which may be a gRPC, a protocol buffer over UDP, or the like.
  • the information model described above provides a mechanism to protect the consumer-facing interface between the system administrator (eg, I2NSF user) and the security controller.
  • the system administrator eg, I2NSF user
  • One of the specific mechanisms can be used to protect corporate networks, data and all resources from external attackers.
  • this information model specifies that the interface must have appropriate authentication and authorization with role-based access control in order to establish multi-tenancy requirements.
  • the data model for the consumer-facing interface of the I2NSF system will be described with reference to FIGS. 4 and 5.
  • the VoIP-VoLTE security service will be described as an example of the security service, and a comprehensive data model and a YANG data model for this VoIP-VoLTE security service will be described.
  • security management for VoIP-VoLTE security service and VoIP-VoLTE security service will be described.
  • a comprehensive data model and a YANG data model for VoIP-VoLTE security services will be described.
  • VoIP-VoLTE security management is considered as an example of use for implementing the data model.
  • the security manager acts as application logic for the VoIP-VoLTE security service and defines the security conditions.
  • the list of illegal device information may be stored in the VoIP-VoLTE database and updated manually or automatically by the VoIP-VoLTE security manager.
  • the SIP URI of a suspected Session Initiation Protocol (SIP) device may be published by the VoIP-VoLTE Security Manager.
  • SIP Session Initiation Protocol
  • VoIP-VoLTE security managers can create new user-side security policies (e.g., block lists of illegal devices using IP addresses, source ports, etc.) to prevent the forwarding of packets to and from newly added VoIP-VoLTE attackers You can load the list periodically.
  • VoIP-VoLTE security management maintains and publishes IP addresses, blacklists of source ports, expiration times, user-agents, and SIP URIs of illegal phone or suspected SIP devices.
  • the VoIP-VoLTE security manager acts as the application logic for the VoIP-VoLTE security service of FIG.
  • the list of illegal device information can be updated manually or automatically by the VoIP-VoLTE security manager as application logic.
  • the VoIP-VoLTE Security Manager creates new user perspective security policies and enforces low-level security policies in NSF to prevent the forwarding of packets to and from newly added VoIP-VoLTE attackers.
  • the VoIP-VoLTE security manager sends the new user perspective security policy to the policy updater, which forwards it to the security controller.
  • domain information such as IP address, user-agent and expiration time value is sent by the NSF to the security controller via the NFI.
  • the security controller passes it to the event collector.
  • the event collector forwards the detected domain information to the VoIP-VoLTE security manager, which then updates the VoIP-VoLTE database.
  • VoIP VoLTE Data for Security Service modelling (Data Modeling for VoIP-VoLTE Security Service)
  • FIG. 4 illustrates a generic data model for a security service according to one embodiment of the invention. 4 illustrates a comprehensive data model, based on the information model for the consumer-facing interface of the I2NSF system of FIG. 3.
  • the I2NSF system has the architecture of the I2NSF system described above in FIG. 1 or 2.
  • the security service is the above-described VoIP-VoLTE security service.
  • FIG. 4 descriptions duplicated with those described above with reference to FIG. 3 will be omitted.
  • the data model for VoIP-VoLTE security service is derived from the I2NSF CFI Information Model.
  • the main purpose of this data model is to completely transform this information model into a YANG data model that can be used to convey security policies to orchestrate control or management messages between components within the proposed security management architecture. will be.
  • the semantics of the data model require that the CFI's data model towards the security controller be aligned with the information model. That is, the meaning of each object / field of the data model for the CFI may correspond to the meaning of each object / field of the information model for the corresponding CFI.
  • the transformation of the information model for CFI is generally done by hand, certain changes must be made to reflect the fact that this is a YANG data model.
  • This data model is designed to support the I2NSF framework, which can be extended to meet security needs.
  • model design is independent of the implementation and the content and semantics of a particular policy. 4 and 5, the VoIP / VoLTE security service is used as a use case of policy rule generation.
  • the I2NSF user's data model parser can interpret the policy and generate an XML file according to the YANG data model.
  • a communication channel based on the RESCONF can be implemented. Basically, the data model is defined based on security policy requirements to detect suspicious phone numbers of VoIP / VoLTE services.
  • the data model includes a policy (ieft-i2nsf-policy) node (field).
  • the ieft-i2nsf-policy field contains a policy life cycle management (or policy life cycle) list (field), a policy rule list (field), and an action list (field).
  • the data model may further include an update list (field). Each field will be described below.
  • a policy-lifecycle-list specifies a set of expiration events and / or expiration times to determine the life of the policy itself.
  • the policy-lifecycle-list includes an expiration-event field and / or an expiration-time field.
  • the expiration-event field may include event-id information identifying an expiration event and / or event-date information indicating a date when an event is generated.
  • the expiration-time field may include time information indicating an expiration time.
  • a policy-rule-list represents specific information about the user perspective policy, such as service type, condition and valid time interval.
  • the policy-rule-list may include a policy-rule-container that includes at least one policy rule object.
  • the policy-rule-container includes policy rule ID information (policy-rule-id), policy name information (policy-name), policy date information (policy-date), service information (service), and / or condition information (condition). It may include.
  • policy rule ID information policy-rule-id
  • policy name information policy name information
  • policy date information policy date information
  • service service
  • the policy-rule-id information identifies a policy rule included in a policy rule container.
  • the policy-name information identifies the name of the policy rule.
  • the policy-date information indicates a date when a policy rule is created.
  • service information includes information on security services provided by NSF.
  • the service information may indicate a security service (eg, voip-handling or volte-handling service).
  • the condition information is identified by the condition ID information.
  • the condition information may include caller information, callee information and / or valid-time-interval.
  • the caller information may include caller-id identifying the caller and / or caller-location indicating the caller's location (eg, country, city, etc.).
  • the callee information may include callee ID information (callee-id) identifying a recipient and / or callee location information (callee-location) indicating a receiver's location (eg, country, city, etc.).
  • the valid-time-interval information may include start time information indicating a start time of the policy and / or end time information indicating an end time of the policy.
  • the action-list specifies what action should be taken. For example, call traffic from a blacklisted caller location may be blocked at an abnormal time (included within a valid time interval) and both permit and mirror are assigned true. This phone traffic may be sequentially delivered to a predefined host for deep packet inspection (DPI).
  • DPI deep packet inspection
  • the action-list includes an action-container that includes at least one action object.
  • the action-container may include an action date field (action-date) indicating a date when the action object is created and / or an action name field (action-name) indicating a name of the action object.
  • the action-name field may include an action-name-ingress node (field) and an action-name-engress node (field) as a case node.
  • the action-name-ingress field may indicate the name of the inflow action that is desired to be performed. Examples of this operation name may include a permit, a mirror, a log, and the like.
  • the action-name field may include a redirection field.
  • the action-name-engress field may include a redirection field.
  • the update field includes an update-container including at least one update object.
  • Each update object may be identified by update ID information.
  • the update container includes an update event and / or an update time field indicating an update time. Each field is described as follows.
  • the update-event field contains update event ID information (update-event-id) that identifies the update event, update enable information that indicates whether the update is enabled, and update date for that update event.
  • Update log information may include update event date information (update-event-date), and / or update log information including update log.
  • a security management system can be implemented to translate user perspective policies into a set of low level policies. After translating the user perspective security policy, the security management system creates a low level policy to specify the action from and / or to the IP address. The data model parser generates XML_le for the low level security policy and passes it to the appropriate NSF instance. The security management system also interprets security events generated by the NSF as user view log messages in the YANG data model and forwards them to the I2NSF user in the opposite direction.
  • a firewall application may be selected as the NSF instance to determine the caller's or receiver's location and call duration to determine whether the VoIP / VoLTE call is suspicious. If the phone has a suspicious behavior pattern, its network traffic can be efficiently blocked by the firewall application in accordance with a low level security policy. Results for firewall applications can be passed to the security management system through the RESTCONF protocol in the YANG data model. Depending on the particular situation, multiple NSF instances may be considered. For example, additional DPI can be used to analyze network traffic from suspicious calls.
  • the following describes a YANG data model for VoIP / VoLTE security services, based on the CFI's information model towards a security controller.
  • FIG. 5 illustrates a YANG data model for a security service according to an embodiment of the present invention.
  • FIG. 5 illustrates the YANG data model, based on the information model for the consumer-facing interface of the I2NSF system of FIG. 3.
  • the I2NSF system has the architecture of the I2NSF system described above in FIG. 1 or 2.
  • the security service is the above-described VoIP-VoLET security service.
  • FIG. 5 descriptions duplicated with those described above with reference to FIGS. 3 and 4 will be omitted.
  • the information model described above with reference to FIG. 3 may be converted into a YANG data model as shown in FIG. 5 using a YANG data modeling language.
  • the comprehensive data model of FIG. 4 may be used to convert the information model into a YANG data model.
  • the YANG data model includes an ietf-i2nsf-consumer-facing-interface module, and the ietf-i2nsf-consumer-facing-interface module defines a YANG data module for a consumer-facing interface towards the security controller. do.
  • the YANG data model contains grouping policies.
  • a policy is a grouping that contains a set of security rules according to certain logic, such as similarity or interrelationships. Network security policies can be applied to both one-way or two-way traffic across NSF.
  • the grouping policy may include a list policy-lifecycle including at least one policy lifecycle.
  • Each policy lifecycle included in the list policy-lifecycle may be identified by a value of a policy-lifecycle-id field to be described later.
  • the list policy-lifecycle may include a policy-lifecycle-id node (field) as an entry node.
  • the list policy-lifecycle may include an expiration event container and / or a container expiration-time.
  • the expiration event indicates an event that causes the policy to expire.
  • the expiration time represents the time when the policy expires.
  • the policy-lifecycle-id field is a mandatory field and indicates an ID of a corresponding policy lifecycle. This ID must be unique.
  • the Enabled field is a mandatory field and indicates whether the policy is enabled or disabled.
  • the event-id field is a mentor field and indicates an ID of an event. This ID must be unique.
  • the event-date field is a mandatory field and indicates a date when an event is triggered.
  • the container expiration-time may include an enabled node (field) and a time node (field) as leaf nodes.
  • the Enabled field is a mandatory field and indicates whether the policy is enabled or disabled.
  • the Time field is a mandatory field and indicates the time at which the policy is enabled.
  • the grouping policy may include a list policy-rule including at least one policy rule.
  • Each policy rule included in the list policy-rule may be identified by a value of a policy-rule-id field.
  • the policy-rule-id represents an ID of a policy rule. This is the key to the policy rule list. It must be unique.
  • list policy-rule leaves a policy-name node (field), a policy-rule-id node (field), and / or a policy-rule-date node (field). Can be included as a node.
  • the list policy-rule may include a container service and / or a list condition.
  • the policy-name field is a mandatory field and may indicate the name of a policy. It must be unique.
  • the policy-rule-date field is a mandatory field and may indicate a date and time at which a policy is created.
  • the container service represents a service that the NSF performs to manage security attacks.
  • a service may include voip-handling and volte-handling. This can be extended later.
  • the container service may include a voip-handling node (field) and a volte-handling node (field) as leaf nodes.
  • the voip-handling field is a mandatory field and indicates whether the policy includes handling voip packet flows.
  • the volte-handling field is a mandatory field that indicates whether the policy includes handling volte packet flows.
  • condition IDs can be identified by condition IDs.
  • the condition ID indicates the ID of the condition. It must be unique.
  • the list condition may include a caller container, a container callee, and / or a container valid-time-interval.
  • the container caller represents the caller of the VoIP-VoLTE call.
  • the container caller may comprise a caller-id node (field) and / or a container caller-location.
  • the caller-id field is a mandatory field and indicates the caller ID. It must be unique.
  • container caller-location indicates the caller's location.
  • the container caller-location may include country nodes (fields) and / or city nodes (fields) as leaf nodes.
  • the Country field is a mandatory field and indicates the sender's country.
  • the City field is a mandatory field and indicates the sender's city.
  • the container callee represents the recipient of the VoIP-VoLTE call.
  • the container callee may include a callee-id node (field) and / or a container callee-location.
  • the callee-id field is a mandatory field and indicates the ID of the receiver. It must be unique.
  • container callee-location indicates the location of the receiver.
  • the container callee-location may include country nodes (fields) and / or city nodes (fields) as leaf nodes.
  • the Country field is a mandatory field and indicates the country of the receiver.
  • the City field is a mandatory field and indicates the city of the receiver.
  • the container valid-time-interval indicates the time at which the policy starts or ends validly.
  • the container valid-time-interval may include a start-time node (field) and / or an end-time node (field) as leaf nodes.
  • the start-time field is a mandatory field and indicates the time at which the policy is validly started.
  • the end-time field indicates the time when the policy is to end effectively.
  • the grouping policy may include a container action.
  • the container action may include an action-type node as a selection node.
  • the action-type node is a network security function by which the flow-based NSF executes various actions, including at least ingress-action, egress-action, and advanced-action. To realize.
  • the action-type node may include an ingress-action node and / or an egress-type node as a case node.
  • the ingress-action field indicates that the inflow action consists of permit, mirror and / or log.
  • Ingress-action nodes may include permit nodes (fields), mirror nodes (fields), and / or log nodes (fields) as leaf nodes.
  • the permit field indicates that the packet flow is allowed or denied.
  • the mirror node indicates that the packet flow is mirrored.
  • the Log field indicates that packet flow is logged.
  • the egress-type node indicates that the egress behavior consists of redirection.
  • An egress-type node may include a redirection node (field) as a leaf node.
  • the redirection field indicates that the packet flow is redirected.
  • the grouping policy may include an update container.
  • the container update contains events that cause the policy to expire.
  • the container update may include an update-id node (field) and an update-event-id node (field) as leaf nodes.
  • the update-id field represents a policy update ID for identifying each update. It must be unique.
  • the update-event-id field represents an ID of an event. It must be unique.
  • the update-event-id field may include an update-enabled node (field), an update-event-date node (field), and / or an update-event-date node (field).
  • the update-enabled field indicates that the update is enabled or disabled.
  • the update-event-date field represents a date when an update event is triggered.
  • the update-event-date field contains information for logging the update and its description.
  • the security management architecture is derived from the I2NSF framework
  • the security considerations of the I2NSF framework should also be included here.
  • a suitable secure communication channel should be used for the transfer of control or management messages between components in the proposed architecture.
  • FIG. 6 illustrates a generic data model for a security service according to another embodiment of the present invention.
  • FIG. 6 illustrates a generic data model, based on the information model for the consumer-facing interface of the I2NSF system of FIG. 3.
  • the I2NSF system has the architecture of the I2NSF system described above in FIG. 1 or 2.
  • the security service may be various types of security services as well as the above-described VoIP-VoLTE security service.
  • descriptions duplicated with those described above with reference to FIGS. 3 and 4 will be omitted.
  • the data model may include a policy module (or a policy-general module).
  • the policy-general module may include policy fields, multi-tenancy fields, end-group fields, threat-feed fields, and / or telemetry data. -data) field. As described above with reference to FIG. 3 for each field (information), detailed description thereof will be omitted.
  • the policy field may include a rule field identified by a rule ID.
  • the rule field may include rule-id information, name information, date information, case information, event information, condition information, and / or policy-action information. Each information and sub information included in each information are described above with reference to FIG. 3, and thus a detailed description thereof will be omitted.
  • the multi-tenancy field is a policy-domain field identified by a policy-domain-id, a policy-role-id identified by a policy-role-id. role), the policy-user field identified by the policy-user-id, and / or the policy-mgnt-auth-method-id identified. It may include a policy-management-authentication-method field.
  • Each field and the information included in each field will be omitted as described above with reference to FIG. 3.
  • the end-group field is identified by the metadata-source field identified by the metadata-source-id and the user-group-id.
  • a user-group field a device group identified by a device group ID (device-group-id), and an application group identified by an application group ID (application-group-id).
  • location-group identified by group and / or location-group-id.
  • the threat-feed field includes threat feed information identified by the threat feed ID, custom list information identified by the custom list ID, and malware scan.
  • threat feed information identified by the threat feed ID
  • custom list information identified by the custom list ID
  • malware scan By malware-scan-group event-map-group information identified by group-malware-scan-group-id, and / or by event-map-group-id It may include event-map-group information to be identified.
  • the telemetry-data field is identified by telemetry-data information identified by telemetry-data-id and telemetry-source-id. Telemetry-source information and / or telemetry-destination-identified by a telemetry-destination-id. Each information and sub-information included in each information have been described above with reference to FIG. 3, and thus a detailed description thereof will be omitted.
  • FIGS. 7 and 8 illustrate a YANG data model for a security service according to another embodiment of the invention.
  • 7 and 8 illustrate a generalized YANG data model, based on the information model for the consumer-facing interface of the I2NSF system of FIG. 3.
  • the I2NSF system has the architecture of the I2NSF system described above in FIG. 1 or 2.
  • the security service may be various kinds of security services as well as the above-described VoIP-VoLTE security service.
  • FIGS. 7 and 8 descriptions overlapping with those described above with reference to FIGS. 3, 4, and 6 will be omitted.
  • the information model described above with reference to FIG. 3 may be converted into a YANG data model as shown in FIGS. 7 to 8 using the YANG data modeling language.
  • the comprehensive data model of FIG. 6 may be used to convert the information model into a YANG data model.
  • FIG. 9 illustrates a generic data model for a security service according to another embodiment of the present invention.
  • FIG. 9 illustrates a data model for a consumer-facing interface of an I2NSF system when VoIP security service is applied to the comprehensive data model of FIG. 6.
  • the I2NSF system has the architecture of the I2NSF system described above in FIG. 1 or 2.
  • the security service may be the above-described VoIP security service.
  • the objects / fields / information included in the comprehensive data model of FIG. 9 and the relationships therebetween may be described by the contents shown in FIG. 9 and the foregoing description. In FIG. 9, descriptions duplicated with those described above with reference to FIG. 6 will be omitted.
  • FIG. 10 illustrates a YANG data model for a security service according to another embodiment of the present invention.
  • FIG. 10 illustrates a YANG data model for a consumer-facing interface of an I2NSF system when the VoIP security service is applied to the generalized YANG data model of FIGS. 7 to 8.
  • the I2NSF system has the architecture of the I2NSF system described above in FIG. 1 or 2.
  • the security service may be the above-described VoIP security service.
  • the objects / fields / information included in the YANG data model of FIG. 10 and the relationships therebetween may be described by the contents shown in FIG. 10 and the aforementioned contents. In FIG. 10, descriptions overlapping with those described above with reference to FIGS. 7 to 8 will be omitted.
  • FIG. 11 illustrates XML output for a VoIP service according to one embodiment of the invention.
  • a call received from a country having an IP of Africa classified as malicious is dropped.
  • the elements / fields / information included in the YANG data model of FIG. 11 and the relationships therebetween may be described by the contents shown in FIG. 11 and the foregoing description.
  • descriptions duplicated with those described above with reference to FIGS. 1 through 10 will be omitted.
  • the policy message may include a ⁇ policy-voip> element for providing a VoIP policy.
  • the ⁇ policy-voip> element may include as a sub element a ⁇ rule-voip> element that provides a VoIP policy rule.
  • the ⁇ rule-voip> element is a ⁇ rule-voip-id> element, an ⁇ event-name> element, a ⁇ rule-voip-date> element indicating the date on which the VoIP rule was created, an ⁇ event> element, and a ⁇ condition> element.
  • And / or ⁇ action> elements as sub-elements.
  • Each element (field) and information included in each element (field) have been described above with reference to FIGS. 1 to 10.
  • the network device may correspond to the above-described I2NSF system or may be a device included in the I2NSF system.
  • Examples of devices included in the I2NSF system may include the above-described I2NSF, security controller, developer management system, NSF, and the like.
  • the network device 1200 includes a processor 1210, a memory 1220, and a communication module 1230.
  • the processor 1210 implements the functions, processes, and / or methods proposed in FIGS. 1 to 11.
  • the memory 1220 is connected to the processor 1210 and stores various information for driving the processor 1210.
  • the communication module 1230 is connected to the processor 1210 and transmits and / or receives a wired / wireless signal.
  • the memory 1220 may be inside or outside the processor 1210 and may be connected to the processor 1210 by various well-known means.
  • FIG. 13 is a flowchart of a data communication method of a network device via a consumer-facing interface according to an embodiment of the present invention.
  • the network device may be an I2NSF user (device) of FIG. 1 or 2.
  • an I2NSF user device may encode security policy data for a security service.
  • the encoding of the security policy data may be performed using the YANG data modeling language (S1310).
  • the I2NSF user device may include transmitting the security policy data to the security controller through the consumer-facing interface (S1320).
  • the security policy data may include a policy lifecycle field that includes the lifecycle of the security policy, a policy rule field that includes the rules of the security policy, and an action field that includes an action to be performed when the rules match. Can be.
  • the policy lifecycle field may include policy lifecycle ID information identifying a policy lifecycle field, expiration event information indicating an event causing the security policy to expire, and expiration time information indicating a time when the security policy expires. It may include.
  • the policy rule field may include policy rule ID information identifying a policy rule field, rule name information indicating a name of the rule, and policy date information indicating a date when a rule of the security policy is created. have.
  • the policy rule field may further include service information indicating a service for performing a network security function (NSF) to manage a security attack.
  • NSF network security function
  • the policy rule field may further include condition information indicating an inspection condition to be applied to a packet or traffic by a network security function (NSF) for security inspection.
  • NSF network security function
  • the operation field may include inflow operation information indicating the configuration of the inflow operation and outflow operation information indicating the configuration of the outflow operation.
  • the configuration of the inflow operation may include at least one of a permit, a mirror, or a log, and the configuration of the leakage operation may include redirection.
  • each component or feature is to be considered optional unless stated otherwise.
  • Each component or feature may be embodied in a form that is not combined with other components or features. It is also possible to combine some of the components and / or features to form an embodiment of the invention.
  • the order of the operations described in the embodiments of the present invention may be changed. Some components or features of one embodiment may be included in another embodiment or may be replaced with corresponding components or features of another embodiment. It is obvious that the claims may be combined to form an embodiment by combining claims that do not have an explicit citation relationship in the claims or as new claims by post-application correction.
  • Embodiments according to the present invention may be implemented by various means, for example, hardware, firmware, software, or a combination thereof.
  • an embodiment of the present invention may include one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), FPGAs ( field programmable gate arrays), processors, controllers, microcontrollers, microprocessors, and the like.
  • ASICs application specific integrated circuits
  • DSPs digital signal processors
  • DSPDs digital signal processing devices
  • PLDs programmable logic devices
  • FPGAs field programmable gate arrays
  • processors controllers, microcontrollers, microprocessors, and the like.
  • an embodiment of the present invention may be implemented in the form of a module, procedure, function, etc. that performs the functions or operations described above.
  • the software code may be stored in memory and driven by the processor.
  • the memory may be located inside or outside the processor, and may exchange data with the processor by various known means.
  • the present invention can be applied to various systems for providing a security service.

Landscapes

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

Abstract

L'invention concerne un procédé de communication de données pour un dispositif utilisateur I2NSF qui comprend les étapes consistant à : coder des données de politique de sécurité par rapport à un service de sécurité ; et transmettre les données de politique de sécurité à un contrôleur de sécurité au moyen d'une interface de contact-utilisateur, les données de politique de sécurité pouvant comprendre un champ de cycle de vie de politique comprenant le cycle de vie de la politique de sécurité, un champ de règle de politique comprenant la règle de la politique de sécurité et un champ de fonctionnement comprenant une opération à exécuter si la règle est mise en correspondance.
PCT/KR2018/002955 2017-03-13 2018-03-13 Procédé et système pour fournir un service de sécurité et dispositif associé WO2018169292A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR20170031423 2017-03-13
KR10-2017-0031423 2017-03-13

Publications (1)

Publication Number Publication Date
WO2018169292A1 true WO2018169292A1 (fr) 2018-09-20

Family

ID=63522433

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2018/002955 WO2018169292A1 (fr) 2017-03-13 2018-03-13 Procédé et système pour fournir un service de sécurité et dispositif associé

Country Status (1)

Country Link
WO (1) WO2018169292A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112789836A (zh) * 2018-09-28 2021-05-11 奥兰治 保护客户端域的方法、对应客户端节点、服务器和计算机程序

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030014644A1 (en) * 2001-05-02 2003-01-16 Burns James E. Method and system for security policy management
US20040042609A1 (en) * 2002-09-04 2004-03-04 Tekelec Methods and systems for enhancing network security in a telecommunications signaling network
US20060242685A1 (en) * 2002-09-23 2006-10-26 Credant Technologies, Inc. System and method for distribution of security policies for mobile devices
US20150207813A1 (en) * 2012-02-01 2015-07-23 Vorstack, Inc. Techniques for sharing network security event information
US20160036855A1 (en) * 2014-07-31 2016-02-04 Zscaler, Inc. Cloud application control using man-in-the-middle identity brokerage

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030014644A1 (en) * 2001-05-02 2003-01-16 Burns James E. Method and system for security policy management
US20040042609A1 (en) * 2002-09-04 2004-03-04 Tekelec Methods and systems for enhancing network security in a telecommunications signaling network
US20060242685A1 (en) * 2002-09-23 2006-10-26 Credant Technologies, Inc. System and method for distribution of security policies for mobile devices
US20150207813A1 (en) * 2012-02-01 2015-07-23 Vorstack, Inc. Techniques for sharing network security event information
US20160036855A1 (en) * 2014-07-31 2016-02-04 Zscaler, Inc. Cloud application control using man-in-the-middle identity brokerage

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112789836A (zh) * 2018-09-28 2021-05-11 奥兰治 保护客户端域的方法、对应客户端节点、服务器和计算机程序
CN112789836B (zh) * 2018-09-28 2023-06-23 奥兰治 保护客户端域的方法、对应客户端节点、服务器和计算机程序

Similar Documents

Publication Publication Date Title
WO2021060857A1 (fr) Système de gestion de flux de commande de nœud à base de code d'exécution à distance et procédé associé
WO2013085281A1 (fr) Procédé et dispositif de sécurité dans un service informatique en nuage
WO2016167536A1 (fr) Procédé et appareil de gestion d'un profil d'un terminal dans un système de communication sans fil
WO2020226454A1 (fr) Appareil et procédé pour fournir des services informatiques mobile edge dans un système de communication sans fil
WO2019098678A1 (fr) Procédé permettant de fournir un service de sécurité et dispositif associé
EP3284274A1 (fr) Procédé et appareil de gestion d'un profil d'un terminal dans un système de communication sans fil
WO2016013846A1 (fr) Procédé de traitement de message de demande dans un système de communications sans fil, et appareil associé
WO2014186986A1 (fr) Procédé, dispositif et système de retransmission de flux
CN105723648A (zh) 一种密钥配置方法、系统和装置
WO2020171672A1 (fr) Procédé d'interfonctionnement entre un processus de téléchargement de faisceau et un processus de téléchargement de profil esim par un terminal ssp
WO2021206519A1 (fr) Appareil et procédé de transmission d'informations de gestion de pont dans un système de communication sans fil
WO2019001110A1 (fr) Procédé, système et dispositif d'authentification d'autorité, et support d'informations lisible par ordinateur
WO2020130320A1 (fr) Dispositif de relais de paquets de réseau de convergence filaire/sans fil et son procédé d'attribution d'horodatage de paquets
WO2021133092A1 (fr) Procédé et appareil permettant de gérer une procédure de transfert intercellulaire dans un système de communication sans fil
WO2020080909A1 (fr) Procédé et appareil de traitement d'exception de gestion de profils à distance
WO2013115565A2 (fr) Procédé de gestion de machine virtuelle et dispositif s'y rapportant
WO2019107876A1 (fr) Procédé et appareil de gestion d'événement dans un système de communication
WO2021060892A1 (fr) Procédé et système de gestion de communications de données critiques de mission (mcdonnées) à l'aide d'une session préétablie
WO2020060231A1 (fr) Procédé de surveillance de la sécurité d'un réseau, dispositif de surveillance de la sécurité d'un réseau et système
WO2020149617A1 (fr) Procédé de sécurisation d'une communication de message de monodiffusion dans des réseaux sans fil basés sur 3gpp
WO2023158111A1 (fr) Système de gestion de cybersécurité pour navire de surface autonome maritime
WO2019088671A1 (fr) Procédé de fourniture de service de sécurité de réseau et appareil pour cela
WO2021201644A1 (fr) Procédé et appareil de gestion d'événement pour plate-forme sécurisée intelligente
EP3854115A1 (fr) Procédé et appareil de traitement d'exception de gestion de profils à distance
WO2014171711A1 (fr) Procédé pour favoriser la politique de restriction des changements de prestataires de services pour l'abonné dans les communications mobiles et appareil associé

Legal Events

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

Ref document number: 18767060

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18767060

Country of ref document: EP

Kind code of ref document: A1

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载