[go: up one dir, main page]

WO2019098678A1 - Procédé permettant de fournir un service de sécurité et dispositif associé - Google Patents

Procédé permettant de fournir un service de sécurité et dispositif associé Download PDF

Info

Publication number
WO2019098678A1
WO2019098678A1 PCT/KR2018/013923 KR2018013923W WO2019098678A1 WO 2019098678 A1 WO2019098678 A1 WO 2019098678A1 KR 2018013923 W KR2018013923 W KR 2018013923W WO 2019098678 A1 WO2019098678 A1 WO 2019098678A1
Authority
WO
WIPO (PCT)
Prior art keywords
field
policy
security
group
i2nsf
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/KR2018/013923
Other languages
English (en)
Korean (ko)
Inventor
정재훈
김은수
김형식
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sungkyunkwan University
Original Assignee
Sungkyunkwan University
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 Sungkyunkwan University filed Critical Sungkyunkwan University
Publication of WO2019098678A1 publication Critical patent/WO2019098678A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/145—Network analysis or design involving simulating, designing, planning or modelling of a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general

Definitions

  • the present invention relates to a system, method and apparatus for providing a security service, and more particularly, to a system and method for providing a security service, will be.
  • NFV Network Functions Virtualization
  • NFV network function virtualization
  • a data communication method for an I2NSF user equipment comprising: encoding security policy data for a security service; And transferring the security policy data to the security controller through a consumer interface between the I2NSF user and the security controller, wherein the security policy data includes multi-tenancy environment information to which the security policy is applied An endpoint group field indicating a list of entities to which the security policy is applied, a policy field including a rule of the security policy, a threat feed field for identifying a threat object, Telemetry < / RTI > collection related information.
  • encoding the security policy data may include converting an information model of the I2NSF user's high-level security policy into a YANG data modeling language.
  • the multi-tenancy field includes a policy domain field identified by the policy domain ID, a policy role field identified by the policy role ID, a policy-user field identified by the policy user ID, and a policy management authentication method ID And a policy-management-authorization-method field identified by the policy-management-authorization-method field.
  • the endpoint group field includes a metadata source field identified by a meta-data source ID, a user group field identified by a user group ID, a device group identified by a device group ID, A group field, an application group field identified by the application group ID, and a location group field identified by the location group ID.
  • the threat feed field includes a threat feed field identified by a threat feed ID, a custom list field identified by a custom list ID, a malware scan group field identified by a malware scan group ID, And at least one of the event map groups identified by the map group ID.
  • the telemetry data field includes a telemetry data field identified by a telemetry data ID, a telemetry source field identified by a telemetry source ID, and a telemetry source field identified by a telemetry destination ID. And a tree destination field.
  • the policy field includes a rule field identified by a rule ID of the security policy, and the rule field includes information related to scheduling of the rule of the security policy.
  • an I2NSF user equipment comprising: a communication module for communicating data; And a processor for controlling the communication module, the processor comprising: encoding security policy data for the security service; And transmitting the security policy data to the security controller through a consumer-facing interface between the I2NSF user and the security controller, the multi-tenancy field indicating multi-tenancy environment information to which the security policy is applied, the entity list to which the security policy is applied A policy field including rules of the security policy, a threat feed field for identifying a threat object, and a telemetry data field indicating telemetry collection related information.
  • the processor is capable of translating the information model of the high level security policy of the I2NSF user into a YANG data modeling language.
  • the multi-tenancy field includes a policy domain field identified by the policy domain ID, a policy role field identified by the policy role ID, a policy-user field identified by the policy user ID, and a policy management authentication method ID And a policy-management-authorization-method field identified by the policy-management-authorization-method field.
  • the endpoint group field includes at least one of a metadata source field identified by a metadata source ID, a user group field identified by a user group ID, a device group field identified by the device group ID, An application group field identified and a location group field identified by the location group ID.
  • the threat feed field is identified by a threat feed field identified by the threat feed ID, a custom list field identified by the custom list ID, a malware scan group field identified by the malware scan group ID, and an event map group ID.
  • the event map group may include at least one of the event map groups.
  • the telemetry data field includes a telemetry data field identified by a telemetry data ID, a telemetry source field identified by a telemetry source ID, and a telemetry source field identified by a telemetry destination ID. And a tree destination field.
  • the policy field includes a rule field identified by a rule ID of the security policy, and the rule field includes information related to scheduling of the rule of the security policy.
  • the information model can be converted into the YANG data model so that it can be used for the consumer facing interface, thereby efficiently transmitting the control and management message.
  • 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 according to another embodiment of the present invention.
  • Figure 3 illustrates a high-level abstraction for a consumer-facing interface of an I2NSF system in accordance with an embodiment of the present invention.
  • Figure 4 illustrates a generic data model for a security service in accordance with an embodiment of the present invention.
  • Figures 5 and 6 illustrate a YANG data model for policy-general in accordance with an embodiment of the present invention.
  • FIG. 7 illustrates a policy instance for a VoIP / VoLTE security service according to an embodiment of the present invention.
  • FIG. 8 illustrates a policy instance YANG data model for a VoIP security service according to an embodiment of the present invention.
  • FIG. 9 illustrates an XML output for a VoIP service according to an embodiment of the present invention.
  • FIG. 10 illustrates a block diagram of a network device according to an embodiment of the present invention.
  • FIG. 11 is a flowchart of a data communication method of a network device through a consumer facing interface according to an embodiment of the present invention.
  • NFV Network Functions Virtualization
  • I2NSF Interface to Network Security Functions
  • the purpose of the I2NSF is to define a standardized interface for a heterogeneous network security function (NSF) provided by a number of security solution vendors.
  • NSF network security function
  • This specification proposes a YANG data model for security management based on I2NSF using NFV (Network Functions Virtualization).
  • the present invention proposes a YANG data model for the I2NSF user interface and the I2NSF consumer-facing interface between the security controllers in the network function virtualization (NFV) environment.
  • NFV network function virtualization
  • the present specification also proposes a security management architecture based on the I2NSF framework.
  • the security management architecture may include an I2NSF user, a Security Management System, and / or the instance (s) of the NSF (s) in the lowest layer of the 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 also proposes a data model for performing a mission for security services (e.g., voice over Internet protocol (VoIP), voice over LTE (VoLTE)) in the I2NSF security management system.
  • a mission for security services e.g., voice over Internet protocol (VoIP), voice over LTE (VoLTE)
  • Application Logic A component of the security management architecture that creates a user perspective security policy to block or mitigate security attacks.
  • the user perspective policy is retrieved from the 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 the NSF capabilities registered by the developer management system via 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 a security controller, used to update (or create) a user perspective policy in the application logic.
  • NSF Network security function
  • the NSF may operate in various layers of various protocol stacks (e.g., a network layer or another Open Systems Interconnection (OSI) layer, etc.).
  • OSI Open Systems Interconnection
  • an NSF a firewall, an Intrusion Prevention System (IPS) / Intrusion Detection System (IDS), a Deep Packet Inspection (DPI) Application Visibility and Control (AVC), Network Virus and Malware Scanning, Sandbox, Data Loss Prevention (DLP), Distributed Denial of Service (DDoS) Mitigation, Transport Layer Security (TLS) proxies, anti-spoofing, and the like.
  • IPS Intrusion Prevention System
  • IDDS Intrusion Detection System
  • DPI Deep Packet Inspection
  • AVC Application Visibility and Control
  • DLP Data Loss Prevention
  • DLP Distributed Denial of Service
  • TLS Transport Layer Security
  • the NSF according to an embodiment of the present invention can be implemented in any of the above examples, and various types of NSFs can be used. In addition, a plurality of NSFs of the same type may be implemented. Further, the NSF according to the present invention may be implemented by combining any one or more of the above-described examples.
  • the architecture / framework of the I2NSF system and the respective components of the I2NSF system will be described. It also demonstrates how the 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, ).
  • SDN Software-Defined Networking
  • NFV Network Functions Virtualization
  • the I2NSF framework is used by a user (e.g., an application, an overlay or a cloud network management system, or an enterprise network manager or management system) of the I2NSF system to inform the I2NFS system which traffic (or traffic pattern) 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
  • the I2NSF system includes an I2NSF User, a Network Operator Management System, a Developer's Management System, and / or at least one NSF (Network Security Function).
  • NSF Network Security Function
  • the I2NSF user communicates with the network operations management system through the I2NSF Consumer-Facing Interface.
  • the network operations management system communicates with the NSF (s) through the I2NSF NSF-Facing Interface (I2NSF).
  • the developer management system communicates with the network operations management system through the I2NSF registration interface.
  • the I2NSF user may request information (e.g., NSF information) from another I2NSF component (e.g., a network operations management system) and / or a security service provided by another I2NSF component (e.g., developer management system) Service). ≪ / RTI >
  • an I2NSF user may be an overlay network management system, an enterprise network manager system, another network domain administrator, and so on.
  • the I2NSF user may be referred to as an I2NSF client.
  • I2NSF consumer An entity that performs a 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 the underlay network to allow, rate-limit, or deny flow based on a particular field of a packet during a time span
  • a video-conference network manager, enterprise network administrators and management systems that need to request a provider network to enforce specific I2NSF policies for a particular flow
  • An IoT management system (IoT management system) that sends a request to an underlay network to block flows that match a set of specific conditions.
  • I2NSF users can create and deploy high-level security policies. Specifically, I2NSF users need to use network security services to protect network traffic from a variety of malicious attacks. To request this security service, the I2NSF user can create a high-level security policy for the desired security service and notify the network operation management system thereof.
  • the I2NSF user considers the type of NSF (s) required to implement the security policy rule configuration for each NSF (s) or security policy rule configuration I can not.
  • the I2NSF user may be notified of security event (s) that occur within the underlying NSF (s) by the network operations management system.
  • security event s
  • the I2NSF user can identify new attacks and update (or create) high level security policies to cope with new attacks. In this way, the I2NSF user can define, manage, and monitor security policies.
  • a network operations management system is a component that acts as a collection and distribution point for security provisioning, monitoring and other operations.
  • 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 key roles of a network operations management system is to translate high-level security policies (or policy rules) from I2NSF users into low-level security policy rules for specific NSF (s) ).
  • the network operations management system may first determine the type of NSF (s) required to enforce the policies required by the I2NSF user.
  • the network operations management system may then create a low-level security policy for each required NSF (s).
  • the network operations management system may set the generated lower level security policy to each NSF (s).
  • the network operations management system also monitors the NSF (s) running in the I2NSF system and provides various information about each NSF (s) (e.g., network access information and workload ) State) can be maintained.
  • the network operations management system or security controller
  • NSF is a logical entity or software component that provides security-related services.
  • NSFs e.g., firewalls
  • NSFs can receive low-level security policies, detect malicious network traffic based on them, and block or mitigate them. Through this, the integrity and confidentiality of the network communication stream can be ensured.
  • the developer management system is an I2NSF component that sends information (e.g., NSF information) to other I2NSF components (e.g., a network operations management system) and / or provides security services (e.g., network security services).
  • the developer management system may also be referred to as a vendor's management system.
  • An entity that performs a role assigned to this 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 the NSF (s) to the network operator. There may be multiple developer management system (s) of various security vendors.
  • I2NSF consumer-facing interface (simply, consumer-facing interface (CFI))
  • CFI is the interface to the user's I2NSF system, located between the I2NSF user and the network operations management system.
  • the I2NSF system can hide the details of the underlying NSF (s) and provide the user with only an abstract view of the NSF (s).
  • This CFI can be used to allow different users of a given I2NSF system to define, manage and monitor security policies for a particular flow within a management domain.
  • the high level security policy (or policy rule) generated by the I2NSF user may be passed to the network operations management system via this CFI.
  • a security alert by the NSF (s) may be communicated from the network operations management system to the I2NSF user via this CFI.
  • I2NSF NSF-facing interface implies, NSF-facing interface (NFI)
  • An NFI is an interface located between the network operations management system (or security controller) and the NSF (s).
  • the primary purpose of the NFI is to provide a standardized interface for controlling and managing the NSF (s) of various security solution vendors by decoupling security management techniques from the NSF (s).
  • the NFI is independent of the details of the NSF (s) (e.g., vendor, form factor, etc.).
  • This NFI can be used to specify and monitor flow-based security policies enforced by one or more NSFs.
  • a network operations management system may deliver flow-based security policies to each flow-based NSF via an NFI interface to enforce higher-level security policies by I2NSF users.
  • a flow-based NSF is an NSF that checks the network flow according to a set of policies to enhance security characteristics.
  • Flow-based security by this flow-based NSF means that packets are checked in the order in which they are received and there is no modification to the packets according to the inspection process.
  • the interfaces for flow-based NSFs can be classified as follows:
  • NSF Operational and Administrative Interface An interface group used by the I2NSF management system to program the operational state of the NSF; This interface group also includes administrative control functions.
  • the I2NSF policy rule represents one way to change this interface group in a consistent manner. Because the application and I2NSF components need to dynamically control the operation of traffic they send and receive, most of the I2NSF effort is focused on this interface group.
  • 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 the NSF to provide information.
  • the functionality of this interface group can also be defined by other protocols such as SYSLOG and DOTS.
  • the I2NSF management system 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 operating state of NSF.
  • NFIs can be developed using a flow-based paradigm.
  • the common trait of the flow-based NSF is to process packets based on the content of the received packet (e.g., header / payload) and / or context (e.g., session state and authentication state). This feature is one of the requirements to define the operation of the I2NSF system.
  • the I2NSF management system does not need to use all the functions of a given NSF, nor does it need to use all available NSFs.
  • this abstraction allows the NSF feature to be treated as a building block by the NSF system. Therefore, the developer is free to use the security functions defined by the vendor and technology independent NSF.
  • I2NSF registration interface (simply, registration interface (RI))
  • RI is an interface that resides between the network operations management system and the developer management system.
  • the NSF provided by different vendors may have different capabilities.
  • vendors need to have a dedicated interface to define their NSF capabilities. This dedicated interface may be referred to as an I2NSF registration interface (RI).
  • the capabilities of the NSF can be preconfigured or dynamically retrieved via the I2NSF registration interface. If a new function exposed to the consumer is added to the NSF, the capability of the new function needs to be registered in the I2NSF registry via this RI so that interested management and control entities know them .
  • FIG. 2 illustrates the architecture of an I2NSF system according to another embodiment of the present invention.
  • the I2NSF system of FIG. 2 more specifically illustrates the configuration of the I2NSF user and network operations management system as compared to the I2NSF system of FIG.
  • FIG. 2 the description overlapping with the above description in FIG. 1 will be omitted.
  • the I2NSF system includes an I2NSF user, a Security Management System, and an NSF instances layer.
  • the I2NSF user layer includes Application Logic, Policy Updater, and Event Collector as components.
  • the security management system layer includes a security controller and a developer management system.
  • the security controller of the security management system layer includes a security policy manager and an NSF capability manager as components.
  • the I2NSF user layer communicates with the security management system layer through a consumer-facing interface.
  • the policy updater and event collector of the I2NSF user layer communicates with the security controller of the security management system layer through a consumer-facing interface.
  • the security management system layer communicates with the NSF instance layer via an NSF-facing interface.
  • the security controller in the security management system layer communicates with the NSF instance layer's NSF instance layer (s) through an NSF-facing interface.
  • 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 correspond to the I2NSF user component, network operation management system component, developer management system component, 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.
  • newly defined components included in each layer will be described.
  • the I2NSF user layer includes the following three components: Application logic, Policy Updater, and Event Collector. Each of the roles and operations will be described as follows.
  • Application logic is a component that creates a high-level security policy.
  • the application logic receives an event for updating (or creating) a high-level policy from the event collector and updates (or creates) a high-level policy based on the collected event. Thereafter, the higher-level policy is sent to the policy updater for distribution to the security controller.
  • the event collector receives events sent by the security collector and sends them to the application logic. Based on this feedback, the application logic may update (or create) a high-level security policy.
  • each may be implemented as one or more components in the I2NSF system as a logical component.
  • it may be implemented by a single I2NSF user component as in FIG.
  • the security controller of the security management system layer includes the following two components: a security policy manager and an NSF capability manager. Each of the roles and operations will be described as follows.
  • a security policy manager can receive a high-level policy from the policy updater through the CFI, and map this policy to several low-level policies. This lower level policy relates to a given NSF capability registered with the NSF Capability Manager. In addition, the security policy administrator can forward this policy to the NSF (s) via the NFI.
  • NSF Capabilities Administrators can specify NSF capabilities registered by the developer management system and share them with the security policy administrator to create a low-level policy associated with a given NSF capability.
  • the NSF Capability Manager may request the developer management system to register NSF capabilities / capabilities in the NSF Capability Manager's management table 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.
  • the security policy manager and the NSF capability manager are shown as separate configurations, but the present invention is not limited thereto. In other words, each may be implemented as a single component in the I2NSF system as a logical component.
  • the NSF instance layer includes NSFs. At this time, all NSFs are located in this NSF instance layer.
  • the security policy manager passes the policy to the NSF (s) via the NFI. In this case, the NSF can detect malicious network traffic based on the received lower-level security policy and block or mitigate it.
  • the information and data model for I2NSF will be described below.
  • the information and data model (YANG data model) for the consumer-facing interface in the I2NSF system is described.
  • the information model and the data model can be used to define managed objects in network management. Despite overlapped details, the information model and the data model have different characteristics in terms of network management.
  • the main purpose of the information model is to model managed objects at a conceptual level, without relying on any particular implementation or protocol.
  • the information model should hide all protocols and implementation details that define the relationship between managed objects. Based on this, the information model can be implemented in different ways and can be mapped to different protocols. Thus, the information model is protocol neutral.
  • an information model can be defined in an exemplary manner, using a natural language such as English.
  • the data model is defined as a lower level of abstraction and provides many details.
  • This data model provides details of the implementation and protocol specifications, e.g., rules describing how to map managed objects to lower level protocol constructs. Since a conceptual model can be implemented in a variety of ways, a multiple data model can be derived from a single information model.
  • NSF such as firewall, Intrusion Prevention System (IPS) / Intrusion Detection System (IDS) and attack mitigation can be used for virtual network functions (VNF) . ≪ / RTI > With efficient virtualization technology, these VNFs can be provisioned automatically and migrated automatically based on real-time security requirements.
  • IPS Intrusion Prevention System
  • IDS Intrusion Detection System
  • VNF virtual network functions
  • the present invention 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 the I2NSF Consumer Facing Interface (CFI), based on the I2NSF framework described above in Figures 1 and 2.
  • CFI I2NSF Consumer Facing Interface
  • the present specification proposes an information model and a data model for security services in a security management architecture so that the above-described security management architecture can support flexible and effective security policies.
  • the primary purpose of the data model according to an embodiment of the present invention is to provide a data model for the I2NSF user's high level security policy, such as a YANG data model, which can be used to convey control and management messages through a consumer facing interface between the I2NSF user and the security controller .
  • the semantics of the data model should be aligned with the information model of the consumer facing interface. Conversion of the information model can be performed so that this YANG data model can facilitate efficient delivery of control messages or management messages.
  • this data model is designed to support the I2NSF framework, which can be extended according to security requirements.
  • the model design is independent of the implementation and the meaning and content of the particular policy.
  • the present invention proposes a VoIP / VoLTE security service as a use case for policy rule generation.
  • FIG. 3 illustrates a high-level abstraction of 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 FIG.
  • the triangular model in 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 relationship between 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 can be defined by the capability information model for I2NSF.
  • This capability information model (NSF capability model) corresponds to the security policy model of the NSF facing interface and the consumer facing interface.
  • I2NSF provides a consumer-facing interface that conveys user-perspective security policies to the security controller for security enforcement in NSF.
  • This consumer facing interface is created using a set of objects, and each object captures a unique set of information from the security manager (i. E., The I2NSF user) needed to represent the security policy.
  • An object may have relationships with various other objects that represent a complete set of requirements.
  • the information model captures the managed objects and the relationships between them.
  • the information model proposed in this document follows the requirements of the consumer facing interface.
  • the data model which represents the implementation of the proposed information model of a particular data representation language, is described separately below.
  • the information model can be transformed into a data model used to convey control and management messages through the consumer facing interface between the I2NSF user and the security controller.
  • the information model of the consumer facing interface may include a policy-general field (or module).
  • the policy-general field may include a multi-tenancy field, an endpoint group field, a policy field, a threat feed field, and / or telemetry data. Field.
  • the policy field may include a rule field, as shown in FIG. 3, and the rule field may include an event sub-model, a condition sub-model, and an operation sub-model. This will be described in detail below.
  • the policy-general field represents a mechanism for representing a security policy by a security manager (e.g., an I2NSF user) using a consumer facing interface to the security controller. Policies can be implemented in NSF.
  • the policy-general field may include some or all of the following information (field).
  • Multi-tenancy Multi-tenancy environment information with policy applied.
  • a rule in a policy may reference a sub-object (e.g., domain, tenant, role, and user). This field can be either a reference to a multi-tenancy object defined elsewhere or a concrete object.
  • Endpoint Group This field contains a list of logical entities within the business environment to which the security policy applies. This field can be referenced by conditional objects in the rule (e.g., source, destination, match). This field can be either a reference to an endpoint group object defined elsewhere or a concrete object.
  • Threat Feed This field represents a threat feed, such as a Botnet server, GeoIP, and Malware signature. This information (field) can be referenced by the rule action object to directly implement threat mitigation.
  • Telemetry Data This field indicates information about telemetry collection that can be consulted on how the rule action object collects the telemetry information of interest.
  • the telemetry collection related information may include what type of telemetry is collected, where the telemetry source is, where to transmit the telemetry information, and so on.
  • Policy This field can contain a list of rules. If the rule does not have customized precedence, then any conflicts must be resolved manually.
  • multi-tenancy can make multiple management domains available to manage application program resources.
  • corporate organizations can include several tenants or departments, such as human resources (HR), finance and law. Therefore, an object is required that defines the set of permissions assigned to the user of the organization to manage its own security policy.
  • HR human resources
  • the policy role object shall have a name, date and access profile for granting or denying permissions for the purpose of managing security policies.
  • policy is a container of rules. To represent a rule, the rule must have complete information such as where and when the policy will be applied. Rules can be made by defining a set of managed objects and their relationships. Policy rules can relate to segmentation, threat mitigation, or telemetry data collection from NSF in the network, which can be specified as a sub-model of the policy model. A rule object may include some or all of the following information (fields).
  • Event This field may contain information that determines whether the rule condition is evaluated or not.
  • This field may contain all the checking conditions to be applied to the objective traffic.
  • Action This field identifies the action to be taken if the rule is matched. If no rules are matched against the traffic type, there can always be an implicit action to drop traffic.
  • Figure 4 illustrates a generic data model for a security service in accordance with an embodiment of the present invention.
  • Figure 4 illustrates a comprehensive data model based on an information model for the consumer facing interface of the I2NSF system of Figure 3;
  • the I2NSF system has the architecture of the I2NSF system described above in FIG. 1 or FIG.
  • the data model may include a policy-general module.
  • the policy-general module may include a policy field, a multi-tenancy field, an endpoint-group field, a threat-feed field, and / or telemetry data -data) field.
  • 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.
  • the event sub-model contains information related to scheduling rules.
  • the rules may be activated based on a time calendar or a security event that includes a threat level change.
  • the event-type field indicates whether the event triggering policy enforcement is " ADMIN-ENFORCED ", " TIME-ENFORCED “, or " EVENT-ENFORCED ".
  • the Time-Information field includes a " BEGIN-TIME " and an " END-TIME " for one time enforcement, &Quot; can be included.
  • the Event-Map-Group field may include a security event or a threat map for determining when a policy needs to be activated.
  • the conditional sub-model indicates a condition for which the security administrator wishes to apply a check for traffic to determine whether a set of actions in the rule can be executed or not.
  • the condition object may include a condition ID field, a source field, a destination field, a match field, a Match-Direction and / or an Exception field.
  • the source field indicates a field for identifying the source of the traffic
  • the destination field indicates a field for identifying the destination of the traffic.
  • Match field indicates a field that identifies a matching criterion used to evaluate whether a specified action needs to be done and a match-direction field indicates a field that identifies a matching criterion used to evaluate whether a specified action needs to be done .
  • the exception field indicates a field that identifies an exception consideration when the rule is evaluated for a given communication.
  • the action sub-model represents an action that a security administrator wants to perform based on a particular traffic class.
  • the action object may include a policy action ID field, a name field, a date field, a Primary-Action field, a Secondary-Action field, and / or an Owner field.
  • the primary-operation field identifies the operation when the rule is matched by the NSF.
  • the secondary-action field the security administrator can specify additional actions.
  • Multi-tenancy is an important aspect of any application that enables multiple administrative domains to manage application resources.
  • Enterprise organizations can have multiple tenants and departments such as human resources (HR), financial and legal departments, and each tenant needs to manage their own security policies .
  • HR human resources
  • financial and legal departments each tenant needs to manage their own security policies .
  • a tenant represents a consumer who wants to manage their own security policy.
  • the multi-tenancy field includes a policy-domain field identified by a policy-domain-id, a policy-role identified by a policy role ID (policy-role-id) (policy-mgnt-auth-method-id) identified by a policy-user field and / or a policy management authentication method ID (policy-mgnt-auth-method-id) identified by a policy user ID Method (policy-mgnt-auth-method) field.
  • Policy domain objects define boundaries for policy management purposes within the security controller. This object can vary depending on how the security controller is hosted and deployed. For example, if an enterprise hosts a security controller in their network, the domain may simply represent an enterprise. However, if the cloud service provider hosts the management service, the domain may represent a single consumer of that provider. Multi-tenancy models can work in all of these environments.
  • the policy-domain object may include a policy domain ID field, a name field, an address field, a contact field, a date field policy-tenant field, and / or an authentication-method field.
  • the policy-tenant field defines an entity within an organization.
  • An entity can be a department or business unit within an enterprise organization that wants to manage its own policies due to regulatory compliance or business reasons.
  • the authentication method field indicates an authentication method to be used for the policy-domain.
  • Policy - A rule object defines a set of permissions assigned to users in an organization that want to manage their own security policies. This object provides a convenient way to assign privilege sets or job functions within an organization to policy users.
  • the policy-rule object may include a policy rule ID field, a name field, a date field, and / or an Access-Profile field.
  • the Access-Profile field identifies the access profile for the role.
  • a profile may grant or deny access to an endpoint group for policy management purposes, or may limit certain operations related to policy management.
  • the policy-user object represents a unique identity within the organization.
  • the identity can authenticate the security controller using a credential, such as a password or a token, to perform policy management.
  • a credential such as a password or a token
  • the user may be an individual, a system or an application requesting access to the security controller.
  • the policy-user object includes a policy-user ID field, a name field, a date field, a password field, an email field, a scope-type field, a scope-reference field, and / .
  • the Policy-Management-Authentication-Method object represents the authentication schemes provided by the security controller.
  • the policy-management-authentication-method object includes a policy-management-authentication-method ID field, a name field, a date field, an authentication-method field, a mutual-authentication field, a token- A certificate-server field and / or a single sign-on-server field.
  • the authentication method may be password-based, token-based, certificate-based or single sign-on authentication.
  • the mutual-authentication field indicates whether mutual authentication is mandatory or not.
  • the token-server field stores information about the server validating the token submitted as a credential.
  • the certificate-server field stores information about the server validating the certificate submitted as a credential.
  • the single sign-on-server field stores information about the server that validates the user credentials.
  • the endpoint group field includes a meta-data-source field identified by a meta-data-source-id, a user group identified by a user-group-id, a device-group field identified by a user-group field, a device-group field identified by a device-group-id, an application-group identified by an application- ) Field and / or a location-group field identified by a location-group-id.
  • An endpoint group is a very important part of creating user-configuration-based policies.
  • the security manager creates and uses this object, which represents a logical entity in their business environment, to which the security policy applies.
  • the meta-data-source object represents an information source for the tag. Tags within a group must be mapped to corresponding contents to enforce security policies.
  • the meta-data-source object may include a meta-data-source ID field, a name field, a date field, a Tag-Type field, a tag-server-information field, a tag- And a Tag-Source-Credentials field.
  • the user-group object represents a group of users based on one of the tags or other information.
  • the user-group object includes a user group ID field, a name field, a date field, a group-type field, a metadata-server field, a group-member field, and / - level (Risk-Level) field.
  • the group-member field represents a list of user-tags, user-names or IP addresses based on the group-type
  • the risk-level field indicates to the security administrator the importance or risk level of the endpoint for policy purposes.
  • the device-group object represents a device group based on one of the tags or other information.
  • the device group object includes a device group ID field, a name field, a date field, a group-type field, a meta-data-server field, a group-member field, and / Level) field.
  • the application-group object represents an application group based on one of the tags or other information.
  • the application-group object includes an application-group ID field, a name field, a date field, a group-type field, a tag-server field, a group-member field, and / - level (Risk-Level) field.
  • the location-group object represents a location group based on one of the tags or other information.
  • the location-group object may include a location group ID field, a name field, a date field, a group-type field, a meta-data-server field, a group-member field, and / -Level) field.
  • the threat-feed field includes threat feed information identified by a threat-feed-id, custom-list identified by a custom-list-id, A malware-scan-group event-map-group information identified by a malware-scan-group-id, and / or an event-map- And event-map-group information identified by the event-map-group information.
  • Threat feeds play an important role in overall security posture by reducing attack surfaces.
  • This information can be provided in the form of a threat feed (treat feed) such as Botnet and GeoIP for third party or external services.
  • a threat feed such as Botnet and GeoIP for third party or external services.
  • Botnet and GeoIP for third party or external services.
  • Threats - The feed object represents a threat server such as Botnet server and GeoIP. Threats - The feed object may contain threat-feed ID fields, name fields, date fields, feed-type fields, feed-server fields, and / or feed- .
  • the Custom-List object represents a custom list created for the purpose of defining an exception to the threat feed. An organization may want to allow certain exceptions to the threat list obtained from a third party.
  • the custom-list object includes a custom-list ID field, a name field, a date field, a List-Type field, a List-Property field, and / or a List- can do.
  • the Malware-Scan-Group object represents the information needed to detect malware. This information may be provided from a local server or periodically uploaded from a third party.
  • the malware-scan-group object may include malware-scan-group ID field, name field, date field, Signature-Server field, File-Types field, and / Field. ≪ / RTI >
  • the event-map-group object represents an event map containing security events and threat levels used for dynamic policy enforcement.
  • the event-map-group object may include an event-map-group ID field, a name field, a date field, a security-event field, and / or a threat-map field.
  • the telemetry can be used to provide system administrators with the visibility of network activities that may be tapped for additional security analysis, such as detecting potential vulnerabilities, malicious activities, thereby providing visibility.
  • the telemetry data field includes telemetry-data information identified by a telemetry-data-id, a telemetry-data identifier identified by a telemetry-source-id, And may include telemetry-destination information identified by telemetry-source information and / or telemetry-destination-id.
  • Telemetry-data object contains information collected for the telemetry.
  • Telemetry - A data object can be a Telemetry - Data ID field, a Name field, a Date field, a Log field, a Syslog field, an SNMP field, an sFlow field, a NetFlow field, and / -Stats field.
  • the telemetry-source object contains information related to the telemetry source.
  • the source will be NSF in the network.
  • the telemetry-source object includes a telemetry-source ID field, a name field, a date field, a Source-Type field, an NSF-Credentials field, a Collection- Field, a Collection-Method field, a Heartbeat-Interval field, and / or a QoS-Marking field.
  • Telemetry - The destination object contains information related to the telemetry destination.
  • the destination may be a security controller or a collector that is part of an external system such as SIEM.
  • the telemetry-destination object includes a telemetry-destination ID field, a name field, a date field, a Collector-Source field, a Collector-Credentials field, a Data- Field, a Data-Transport field, and / or a Data-Transport field.
  • the data model described above provides a mechanism to protect the consumer-facing interface between a system administrator (e.g., an I2NSF user) and a security controller.
  • a system administrator e.g., an I2NSF user
  • One of the specific mechanisms can be used to protect the corporate network, data and all resources from external attackers.
  • This data model also stipulates that the interface must have appropriate authentication and authorization as role-based access control to establish multi-tenancy requirements.
  • Figures 5 and 6 illustrate a YANG data model for policy-general in accordance with an embodiment of the present invention.
  • Figures 5 and 6 illustrate a generalized YANG data model based on an information model for the consumer facing interface of the I2NSF system of Figure 3.
  • the I2NSF system has the architecture of the I2NSF system described above in Fig. 1 or Fig.
  • VoIP-VoLTE security service not only VoIP-VoLTE security service but also various kinds of security services can be applied.
  • the description overlapping with the above description in Fig. 4 is omitted.
  • the information model described above in Fig. 3 can be converted into a YANG data model as shown in Figs. 5 to 6 using the YANG data modeling language.
  • the generic data model of FIG. 4 may be used to transform the information model into a YANG data model.
  • FIG. 7 illustrates a policy instance for a VoIP / VoLTE security service according to an embodiment of the present invention.
  • FIG. 7 illustrates a data model for a consumer-facing interface of the I2NSF system when VoIP security services are applied to the generic data model of FIG.
  • the I2NSF system has the architecture of the I2NSF system described above in FIG. 1 or FIG.
  • the security service may be a VoIP / VoLTE security service.
  • the object / field / information included in the comprehensive data model of FIG. 7 and the relationship therebetween can be explained by the contents shown in FIG. 7 and the contents described above. In FIG. 7, the description overlapping with the above description in FIG. 4 will be omitted.
  • FIG. 8 illustrates a policy instance YANG data model for a VoIP security service according to an embodiment of the present invention.
  • FIG. 8 illustrates a YANG data model for a security service according to another embodiment of the present invention.
  • FIG. 8 illustrates a YANG data model for a consumer-facing interface of an I2NSF system when VoIP security services are applied to the generalized YANG data model of FIGS. 5-6.
  • the I2NSF system has the architecture of the I2NSF system described above in FIG. 1 or FIG.
  • the security service may be a VoIP security service.
  • the object / field / information included in the YANG data model of FIG. 8 and the relationship therebetween can be explained by the contents shown in FIG. 8 and the contents described above. In FIG. 8, a description overlapping with the above description in FIGS. 5 to 6 will be omitted.
  • the VoIP-VoLTE security service will be described as an example of a security service, and a comprehensive data model and a YANG data model for the VoIP-VoLTE security service will be described.
  • security management for VoIP-VoLTE security service and VoIP-VoLTE security service.
  • a comprehensive data model and a YANG data model for VoIP-VoLTE security service will be described.
  • VoIP-VoLTE security management is considered as an example for implementing a data model.
  • the security manager acts as application logic for the VoIP-VoLTE security service and defines security conditions.
  • a list of illegal device information may be stored in the VoIP-VoLTE database and manually or automatically updated by the VoIP-VoLTE security manager.
  • the SIP URI of the suspected Session Initiation Protocol (SIP) device may be disclosed by the VoIP-VoLTE security manager.
  • SIP Session Initiation Protocol
  • a list of illegal devices that are updated automatically (or passively) may be stored in the VoIP-VoLTE database.
  • VoIP-VoLTE security administrators can use this list to create new user-perspective security policies (eg, block lists of illegal devices such as IP addresses and source ports) to prevent the forwarding of packets from / to the newly added VoIP-VoLTE attackers. You can load it periodically.
  • VoIP-VoLTE security management maintains and publishes IP addresses, black lists of source ports, expiration times, user-agents and illegal phones, or SIP URIs of suspected SIP devices.
  • the VoIP-VoLTE security manager acts as application logic for the VoIP-VoLTE security service of FIG.
  • VoIP-VoLTE security manager Based on VoIP-VoLTE security management, a list of illegal device information can be manually or automatically updated by the VoIP-VoLTE security manager as application logic.
  • the VoIP-VoLTE security administrator creates a new user-perspective security policy and enforces a lower-level security policy in NSF to prevent the forwarding of packets from / to the newly added VoIP-VoLTE attacker.
  • the VoIP-VoLTE security manager sends the new user perspective security policy to the policy updater, which then passes it to the security controller.
  • domain information such as IP address, user-agent and expiration time values is sent by the NSF to the security controller via the NFI.
  • the security controller passes it to the event collector.
  • the event collector delivers the detected domain information to the VoIP-VoLTE security manager, and then the VoIP-VoLTE security manager updates the VoIP-VoLTE database.
  • the data model for VoIP-VoLTE security services is derived from the I2NSF CFI information model.
  • the main purpose of this data model is to fully transform this information model into a YANG data model that can be used to deliver security policies to orchestrate control or management messages between components within the proposed security management architecture will be.
  • the semantics of the data model should be aligned with the CFI data model towards the security controller. That is, the meaning of each object / field in the data model for the CFI can correspond to the meaning of each object / field in the information model for the corresponding CFI.
  • the transformation of the information model to the CFI is typically performed by hand, certain changes must be made to reflect the fact that this is the YANG data model.
  • This data model is designed to support the I2NSF framework, which can be extended to meet security needs.
  • the model design is independent of the implementation and the content and meaning of the particular policy.
  • the VoIP / VoLTE security service is used as a use case of policy rule generation.
  • blacklisting countries To implement this data model, the following three parameters are considered to define the user perspective policy: blacklisting countries, time interval specification, and caller's priority levels.
  • the I2NSF user's data model parser can interpret the policy and generate the XML file according to the YANG data model.
  • a communication channel based on RESCONF may be implemented.
  • the data model can be defined based on security policy requirements to detect suspicious phone numbers of VoIP / VoLTE services.
  • a security management system may be implemented to translate a user perspective policy into a set of lower level policies. After translating the user perspective security policy, the security management system creates a low level policy to specify an operation from the IP address and / or to the IP address. The data model parser generates an XML_le for low-level security policy and passes it to the appropriate NSF instance. The security management system also interprets the security events generated by the NSF as a user perspective log message of the YANG data model and forwards it to the I2NSF user in the opposite direction.
  • the firewall application may be selected as the NSF instance to determine the location and duration of the caller or recipient and to determine whether the VoIP / VoLTE call is suspicious. If the phone has a suspicious behavior pattern, the network traffic may be effectively blocked by the firewall application according to the low-level security policy.
  • the results for the firewall application can be passed from the YANG data model to the security management system via the RESTCONF protocol. Multiple NSF instances may be considered depending on the particular situation. For example, additional DPI can be used to analyze network traffic from suspicious phones.
  • the following describes the YANG data model for VoIP / VoLTE security services based on the CFI's information model towards the security controller.
  • the information model described above in FIG. 3 can be converted into a YANG data model as shown in FIG. 8 using the YANG data modeling language.
  • the generic data model of FIG. 4 may be used to transform the information model into a YANG data model.
  • security management architecture is derived from the I2NSF framework
  • security considerations of the I2NSF framework should also be included here.
  • a suitable secure communication channel must be used for the delivery of control or management messages between components in the proposed architecture.
  • FIG. 9 illustrates an XML output for a VoIP service according to an embodiment of the present invention.
  • FIG. 9 illustrates an XML output for a VoIP service according to an embodiment of the present invention.
  • a call received from a country having an IP of Africa classified as malicious is dropped.
  • the element / field / information included in the YANG data model of FIG. 9 and the relationship therebetween can be explained by the contents shown in FIG. 9 and the contents described above.
  • the description overlapping with the description in FIGS. 1 to 8 will be omitted.
  • the policy message may include a ⁇ policy-voip> element that provides a VoIP policy.
  • the ⁇ policy-voip> element may contain a ⁇ rule-voip> element as a subelement that provides VoIP policy rules.
  • the ⁇ rule-voip> element includes a ⁇ rule-voip-id> element, an ⁇ event-voip-name> element, a ⁇ rule-voip-date> element indicating the date when the VoIP rule was created, Element and / or ⁇ action > element as a sub-element.
  • the information contained in each element (field) and each element (field) is as described above with reference to Figs.
  • the network device corresponds to the I2NSF system described above, or may be a device included in the I2NSF system.
  • Examples of the devices included in the I2NSF system may include the above-described I2NSF, security controller, developer management system, NSF, and the like.
  • a network device 1000 includes a processor 1010, a memory 1020, and a communication module 1030.
  • the processor 1010 implements the functions, processes and / or methods suggested in Figs. 1-9 above.
  • the memory 1020 is coupled to the processor 1010 and stores various information for driving the processor 1010.
  • the communication module 1030 is connected to the processor 1010 to transmit and / or receive a wired / wireless signal.
  • the memory 1020 can be internal or external to the processor 1010 and can be coupled to the processor 1010 in a variety of well known ways.
  • FIG. 11 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 the 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 passing security policy data to the security controller via a consumer-facing interface (S1320).
  • the security policy data may include a multi-tenancy field indicating multi-tenancy environment information to which the security policy is applied, an endpoint group field indicating a list of entities to which the security policy is applied, A policy field, a threat feed field for identifying a threat object, and a telemetry data field indicating telemetry collection related information.
  • step S1310 may include converting an information model of the high-level security policy of the I2NSF user into a YANG data modeling language.
  • the multi-tenancy field includes a policy domain field identified by a policy domain ID, a policy role field identified by a policy role ID, a policy-user field identified by the policy user ID, and a policy management authentication method ID Management-authorization-method field identified by the policy-management-authorization-method field.
  • the endpoint group field includes a metadata source field identified by the metadata source ID, a user group field identified by the user group ID, a device group field identified by the device group ID, An application group field identified by the location group ID, and a location group field identified by the location group ID.
  • the threat feed field may include a threat feed field identified by a threat feed ID, a custom list field identified by a custom list ID, a malware scan group field identified by a malware scan group ID, and an event map group ID And at least one of a group of event maps to be identified.
  • the telemetry data field includes a telemetry data field identified by a telemetry data ID, a telemetry source field identified by a telemetry source ID, and a telemetry source field identified by a telemetry destination ID. And a metric destination field.
  • the policy field includes a rule field identified by a rule ID of the security policy, and the rule field includes information related to the scheduling of rules of the security policy, A condition sub-model indicating a condition for applying an inspection of traffic for determining whether to perform the intra-rule operation, and an operation sub-model indicating an operation that the I2NSF user desires to perform based on the specific traffic class.
  • Embodiments in accordance with 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) 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
  • an embodiment of the present invention may be embodied in the form of a module, a procedure, a function, and the like for performing the functions or operations described above, Lt; / RTI >
  • the recording medium may include program commands, data files, data structures, and the like, alone or in combination.
  • Program instructions to be recorded on a recording medium may be those specially designed and constructed for the present invention or may be available to those skilled in the art of computer software.
  • the recording medium may be an optical recording medium such as a magnetic medium such as a hard disk, a floppy disk and a magnetic tape, a compact disk read only memory (CD-ROM), a digital video disk (DVD)
  • Optical media such as a floppy disk and a hardware device specifically configured to store and execute program instructions such as ROM, RAM, flash memory and the like.
  • Examples of program instructions may include machine language code such as those generated by a compiler, as well as high-level language code that may be executed by a computer using an interpreter or the like.
  • Such hardware devices may be configured to operate as one or more software modules to perform the operations of the present invention, and vice versa.
  • a device or terminal according to the present invention may be driven by instructions that cause one or more processors to perform the functions and processes described above.
  • Such instructions may include, for example, interpreted instructions such as script commands, such as JavaScript or ECMAScript commands, or other instructions stored in executable code or computer readable media.
  • the apparatus according to the present invention may be implemented in a distributed manner across a network, such as a server farm, or may be implemented in a single computer device.
  • a computer program (also known as a program, software, software application, script or code) that is embedded in the apparatus according to the present invention and which implements the method according to the present invention includes a compiled or interpreted language, a priori or procedural language , And may be deployed in any form including standalone programs or modules, components, subroutines, or other units suitable for use in a computer environment.
  • a computer program does not necessarily correspond to a file in the file system.
  • the program may be stored in a single file provided to the requested program, or in multiple interactive files (e.g., a file storing one or more modules, subprograms, or portions of code) (E.g., one or more scripts stored in a markup language document).
  • a computer program may be deployed to run on multiple computers or on one computer, located on a single site or distributed across multiple sites and interconnected by a communications network.

Landscapes

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

Abstract

L'invention concerne un procédé de communication de données d'un dispositif utilisateur I2NSF. Plus particulièrement, le procédé, qui est exécuté par un dispositif utilisateur I2NSF, peut comprendre les étapes consistant : à coder des données de politique de sécurité pour un service de sécurité ; et à délivrer les données de politique de sécurité à un contrôleur de sécurité par l'intermédiaire d'une interface orientée vers le consommateur entre un utilisateur I2NSF et le contrôleur de sécurité, les données de politique de sécurité comprenant un champ de locataires multiples indiquant des informations d'environnement de locataires multiples auxquelles la politique de sécurité est appliquée, un champ de groupe de points d'extrémité indiquant une liste d'entités auxquelles la politique de sécurité doit être appliquée, un champ de politique comprenant des règles de la politique de sécurité, un champ d'alimentation de menace pour identifier un objet menaçant, et un champ de données de télémesure indiquant des informations relatives à la collecte de télémesure.
PCT/KR2018/013923 2017-11-14 2018-11-14 Procédé permettant de fournir un service de sécurité et dispositif associé Ceased WO2019098678A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2017-0151702 2017-11-14
KR20170151702 2017-11-14

Publications (1)

Publication Number Publication Date
WO2019098678A1 true WO2019098678A1 (fr) 2019-05-23

Family

ID=66538745

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2018/013923 Ceased WO2019098678A1 (fr) 2017-11-14 2018-11-14 Procédé permettant de fournir un service de sécurité et dispositif associé

Country Status (2)

Country Link
KR (1) KR20190055009A (fr)
WO (1) WO2019098678A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114422193A (zh) * 2021-12-23 2022-04-29 中国太平洋保险（集团）股份有限公司 一种僵尸网络风险评估方法及装置
CN114490006A (zh) * 2020-10-23 2022-05-13 华为技术有限公司 任务确定方法、装置、设备及存储介质

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11792227B2 (en) 2019-06-12 2023-10-17 Research & Business Foundation Sungkyunkwan University I2NSF network security function facing interface YANG data model
KR102753854B1 (ko) * 2019-07-24 2025-01-14 성균관대학교산학협력단 I2nsf 등록 인터페이스 yang 데이터 모델
KR102819125B1 (ko) * 2019-07-24 2025-06-11 성균관대학교산학협력단 I2nsf 소비자 직면 인터페이스 양 데이터 모델
KR102335012B1 (ko) * 2019-11-04 2021-12-07 성균관대학교산학협력단 I2nsf 네트워크 보안 능력에 직면한 인터페이스 yang 데이터 모델
CN112241243B (zh) * 2020-10-19 2024-01-26 北京计算机技术及应用研究所 一种主动对象存储系统的实现方法
KR102766789B1 (ko) 2024-03-27 2025-02-11 쿠팡 주식회사 사용자 컨텍스트 전파 방법 및 이를 수행하는 장치

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
"Trend of I2NSF technology and standardization", OSIA S& TR JOURNAL, vol. 28, no. 4, December 2015 (2015-12-01), pages 42 - 55 *
JAEHOON PAUL JEONG: "Consumer-Facing Interface YANG Data Model for Interface to Network Security Functions", IETF INTERNET DRAFT, DRAFT-JEONG-I2NSF-CONSUMER-FACING-INTERFACE-DM-01, 27 March 2017 (2017-03-27), pages 4 - 8, XP015118553 *
JAEHOON PAUL JEONG: "I2NSF Consumer-Facing Interface YANG Data Model", IETF INTERNET DRAFT, DRAFT-JEONG-I2NSF-CONSUMER-FACING-INTERFACE-DM-03, 18 July 2017 (2017-07-18), XP015121036 *
R. KUMAR: "Information model for Client-Facing Interface to Security Controller", IETF INTERNET DRAFT, DRAFT-KUMAR-I2NSF-CLIENT-FACING-INTERFACE-IM-02, 30 April 2017 (2017-04-30), XP015119406 *
S. HARES: "Interface to Network Security Functions (I2NSF):Problem Statement and Use Cases", IETF INTERNET DRAFT, RFC 8192, XP015121130, ISSN: 2070-1721 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114490006A (zh) * 2020-10-23 2022-05-13 华为技术有限公司 任务确定方法、装置、设备及存储介质
CN114490006B (zh) * 2020-10-23 2025-03-14 华为技术有限公司 任务确定方法、装置、设备及存储介质
CN114422193A (zh) * 2021-12-23 2022-04-29 中国太平洋保险（集团）股份有限公司 一种僵尸网络风险评估方法及装置

Also Published As

Publication number Publication date
KR20190055009A (ko) 2019-05-22

Similar Documents

Publication Publication Date Title
WO2019098678A1 (fr) Procédé permettant de fournir un service de sécurité et dispositif associé
WO2013085281A1 (fr) Procédé et dispositif de sécurité dans un service informatique en nuage
US20250284812A1 (en) Browser managed access of corporate resources
DeCusatis et al. Implementing zero trust cloud networks with transport access control and first packet authentication
US11115437B2 (en) Cyber-security system and methods thereof for detecting and mitigating advanced persistent threats
KR102136039B1 (ko) 소프트웨어 정의 네트워크에서의 보안
WO2014069777A1 (fr) Commande de transit pour des données
WO2018101565A1 (fr) Structure de gestion de sécurité dans un environnement de virtualisation de réseau
Patel et al. A detailed review of cloud security: issues, threats & attacks
CN117693746A (zh) 企业浏览器系统
Hares et al. Interface to network security functions (I2NSF): Problem statement and use cases
WO2016064235A2 (fr) Procédé de gestion d'une ressource enfant d'un membre d'un groupe dans un système de communication sans fil, et dispositif associé
WO2016013846A1 (fr) Procédé de traitement de message de demande dans un système de communications sans fil, et appareil associé
WO2019088671A1 (fr) Procédé de fourniture de service de sécurité de réseau et appareil pour cela
Charanya et al. Levels of security issues in cloud computing
US20110154469A1 (en) Methods, systems, and computer program products for access control services using source port filtering
WO2023163514A1 (fr) Système de commande d'accès au réseau basé sur un dispositif de commande et procédé associé
WO2023211124A1 (fr) Système de commande de connexion de réseau basée sur un contrôleur et procédé associé
WO2016089567A1 (fr) Système de cyber-sécurité et ses procédés de détection et d'atténuation de menaces persistantes avancées
WO2021095926A1 (fr) Dispositif ido complexe et procédé de fourniture de service de partage l'utilisant, et procédé de reconnaissance d'informations externes par application de chaîne de blocs et fourniture d'informations
Seneviratne et al. Integrated corporate network service architecture for bring your own device (BYOD) policy
WO2018169292A1 (fr) Procédé et système pour fournir un service de sécurité et dispositif associé
WO2024144383A1 (fr) Système et procédé de fourniture de service qui utilisent un jeton d'accès d'utilisateur
WO2018097422A1 (fr) Procédé et système d'orientation de trafic déclenchée par une fonction de sécurité de réseau, et dispositif associé
WO2024228524A1 (fr) Système de contrôle d'accès au réseau, et procédé 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: 18878224

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

Country of ref document: EP

Kind code of ref document: A1