+

WO2018169294A1 - Modèle de données yang d'interface orientée vers une fonction de sécurité de réseau i2nsf - Google Patents

Modèle de données yang d'interface orientée vers une fonction de sécurité de réseau i2nsf Download PDF

Info

Publication number
WO2018169294A1
WO2018169294A1 PCT/KR2018/002957 KR2018002957W WO2018169294A1 WO 2018169294 A1 WO2018169294 A1 WO 2018169294A1 KR 2018002957 W KR2018002957 W KR 2018002957W WO 2018169294 A1 WO2018169294 A1 WO 2018169294A1
Authority
WO
WIPO (PCT)
Prior art keywords
security
policy
rule
i2nsf
clause
Prior art date
Application number
PCT/KR2018/002957
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 WO2018169294A1 publication Critical patent/WO2018169294A1/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 data model, in more detail defining an information model for an interface facing Network Security Functions (NSF) in I2NSF (Interface to Network Security Functions) and a YANG data model for security services. It is for.
  • NSF Network Security Functions
  • I2NSF Interface to Network Security Functions
  • the Internet is essentially a number of networks with different levels of hierarchy interconnected.
  • the Internet operates in accordance with TCP / IP (Transmission Control Protocol / Internet Protocol) published by the Internet Engineering Task Force (IETF), which can be found in Request For Comments (RFC) 703 and RFC 791 issued by the IETF. .
  • TCP / IP Transmission Control Protocol / Internet Protocol
  • RFC Request For Comments
  • An object of the present invention is to propose a method for designing an information model for an interface facing Network Security Functions (NSF) in I2NSF and a YANG data model for security services.
  • NSF Network Security Functions
  • the present invention proposes a specific information model for three security capabilities (eg, network security capability) and a method for designing the corresponding data model, such as network security control, content security control, and attack mitigation control.
  • security capabilities eg, network security capability
  • a method for designing the corresponding data model such as network security control, content security control, and attack mitigation control.
  • a method for providing a security service by the network operation management system in the security management system is a high-level (Inter-Level) from the I2NSF user Receiving a first security policy of the; Generating a low-level second security policy corresponding to the first security policy; And transmitting a packet including the second security policy for setting the generated second security policy to each of a plurality of NSFs, wherein the network operation management system and each of the plurality of NSFs include: I2NSF is connected to the NSF-face interface.
  • the second security policy includes a policy rule to be applied, and basic operation information indicating an operation for a general security function.
  • the policy rule includes policy information and rule information, wherein the policy information and the rule information include an event clause indicating a change of a system and a condition clause indicating an application condition of a policy rule. Clause), and an Action Clause representing a security function performed when the event clause and the condition clause are satisfied.
  • the policy rule further includes time information indicating a time when the policy rule is applied.
  • the time information further includes at least one of absolute time information indicating an absolute time when the policy rule is applied or period information indicating a periodic time when the policy rule is applied.
  • the event clause is used to determine whether the condition clause can be evaluated.
  • condition clause includes a port number value for setting a rule related to the port number.
  • the operation clause includes an ingress action, an egress action, and an apply profile action.
  • the profile operation includes content security control indicating a security function applied to an application program layer, and attack mitigation control for detecting and mitigating a network attack.
  • Condition Clause and the Action Clause are configured in a container structure for application of multiple conditions.
  • the present invention provides an I2NSF (Interface to Network Security Function) user for creating a high-level first security policy; Receiving the first security policy from the I2NSF user, generating a low-level second security policy corresponding to the first security policy, and generating the second security policy in a plurality of NSFs; Security function) a network operation management system for transmitting a packet including said second security policy for setting to each; And a plurality of NSFs (Network Security Function) for receiving the second security policy from the security management system, wherein each of the network operation management system and the plurality of NSFs is connected to an I2NSF NSF-direct interface. do.
  • I2NSF Interface to Network Security Function
  • an information model for an interface facing Network Security Functions (NSF) and an YANG data model for a security service may be designed in I2NSF (Interface to Network Security Functions).
  • the I2NSF controller may control the capability of the 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 an architecture of an I2NSF system according to an embodiment of the present invention.
  • FIG 3 shows an example of the overall I2NSF information model design to which the present invention can be applied.
  • FIG. 4 shows an example of a network security information sub-model overview to which the present invention can be applied.
  • FIG. 5 shows an example of extension of a network security information submodel to which the present invention can be applied.
  • FIG. 6 shows an example of extension of a network security information submodel event class to which the present invention can be applied.
  • FIG. 7 illustrates an example of extension of a network security information sub-model condition class to which the present invention can be applied.
  • FIG. 8 shows an example of extension of a network security information submodel action to which the present invention can be applied.
  • FIG 9 shows an example of a high level model of I2NSF security function to which the present invention can be applied.
  • FIG. 10 shows an example of a network security function information model to which the present invention can be applied.
  • FIG 11 shows an example of an attack mitigation function information model to which the present invention can be applied.
  • 12A and 12B illustrate a data model structure for network security policy identification according to an embodiment of the present invention.
  • FIG. 13 illustrates a data model structure for an event rule according to an embodiment of the present invention.
  • 14A to 14D illustrate a data model structure for a condition rule according to an embodiment of the present invention.
  • 15A and 15B illustrate a data model structure for an action rule according to an embodiment of the present invention.
  • 16A to 18J illustrate the YANG data module of the I2NSF NSF-Facing-Interface according to an embodiment of the present invention.
  • 19A through 19J illustrate a data model for NSF monitoring according to an embodiment of the present invention.
  • 20A-21I illustrate a YANG data model for monitoring according to one embodiment of the 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
  • 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 Interface to Network Security Function (NSF). do.
  • 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 NFC (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 is an I2NSF component that requests information from another I2NSF component (eg, a network operations management system) and / or uses a service (eg, a network security service) provided by another I2NSF component (eg, a developer management system).
  • another I2NSF component eg, a network operations management system
  • a service eg, a network security service
  • the I2NSF user may be an overlay network management system, an enterprise network administrator system, another network domain administrator, or the like.
  • 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 high level security policy for the security service he wants and notify the network operations management system.
  • 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) high level security policies to counter 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 be a security controller.
  • Such a network operations management system may be managed by a network security manager and may be referred to as an I2NSF management system.
  • the network operations management system may receive the high level security policy from the I2NSF user and then first determine the type of NSF (s) required to enforce the policy required by the I2NSF user. The network operations management system (or security controller) can then create a low-level security policy for each NSF (s) required. As a result, the network operations management system (or security controller) may set the generated low level security policy to each NSF (s).
  • network operations management system monitors the NSF (s) running in the system and provides various information about each NSF (s) (e.g., network access information and workloads). State, etc.) can be maintained.
  • network operations management systems or security controllers
  • NSF is a logical entity or software component that provides security related services.
  • NFC may receive a low level security policy and, based on it, detect malicious network traffic and block or mitigate it. In this way, the integrity and confidentiality of the network communication stream can be guaranteed.
  • the developer management system is an I2NSF component that sends information to other I2NSF components (eg, I2NSF users, network operations management systems) and / or provides services (eg, network security services).
  • I2NSF components eg, I2NSF users, network operations management systems
  • 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 the network operations management system. There may be multiple developer management system (s) from various security vendors.
  • I2NSF consumer-facing interface (simply, consumer-facing interface (CFI))
  • the CFI is an interface to the user's I2NSF system, located between the I2NSF user and the network operations management system. This design hides the details of the underlying NSF (s) and gives the user 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 specific flows in an administrative domain.
  • High-level security policies (or policy rules) created by I2NSF users can be conveyed to the network operations management system via this CFI.
  • NFI is an interface located between the network operations management system (or security controller) and the NSF (s).
  • This NFI may be used to specify and monitor a flow-based security policy enforced by one or more NSFs.
  • an I2NSF system can use flow-based NSF.
  • 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 capabilities. 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 capabilities 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 capabilities 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. Therefore, developers are free to use the security capabilities defined by NSF, which is independent of vendor and technology.
  • I2NSF Registration interface (simply, 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 the process using the different types of security capabilities offered by different vendors, vendors need to have a dedicated interface to define their NSF's capabilities. 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 capabilities exposed to consumers are added to the NSF, the capabilities of those new capabilities need to be registered in the I2NSF registry via the I2NSF registration interface so that interested management and control entities know them. have.
  • FIG. 2 illustrates the architecture of an I2NSF system in accordance with an 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.
  • the security management system layer also communicates with the NFC instance layer via the NSF-direct 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.
  • the I2NSF user layer, 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 of FIG. Corresponds to the 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 the component that creates the high-level security policy.
  • the application logic receives an event from the event collector to update (or create) a high level policy and updates (or creates) a high level policy based on the collected event. After that, the high level policy is sent to the policy updater for distribution to the security controller.
  • the event collector receives the events sent by the security collector and sends them to the application logic. Based on this feedback, the application logic can update (or create) a high level security policy.
  • the application logic, the policy updater, and the event collector are shown in separate configurations, but are not limited thereto. In other words, each may be implemented as one or two components in the I2NSF system as logical components.
  • the security controller of the security management system layer includes two components, a security policy manager and an NSF capability manager.
  • the security policy manager can receive high-level policies from the policy updater through CFI, and map these policies to multiple low-level policies. This low level policy relates to a given NSF capability registered with the NSF capability manager. In addition, the security policy manager 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 in the management table of the NSF capability manager through the registration interface. The developer management system is another part of the security management system for registering new NSF capabilities as NSF capability managers.
  • 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 the NFI.
  • NFC can detect, block or mitigate malicious network traffic based on the received low level security policy.
  • NSF can offer customers a variety of security capabilities.
  • the NSF can be combined together to provide security services for a given network traffic, regardless of whether it is implemented with physical or virtual capabilities.
  • Security capability refers to the security-related capabilities of a set of networks that can be used for security policy enforcement purposes. Security capabilities are independent of the security control mechanisms actually implemented, and every NSF has a registered set of capabilities that it can provide.
  • Security Capabilities are market leaders who provide a way to define custom security protection by unambiguously describing the security capabilities provided by a particular NSF.
  • security capabilities can be described in a vendor-neutral way of security capabilities.
  • I2NSF interfaces that can be used to provide security policies.
  • I2NSF user-to-application interface and security controller (Consumer-Facing Interface): A service-oriented interface that provides a communication channel between NSF data and service users and the network operations management system (or security controller).
  • the I2NSF Consumer-Facing Interface can be used to exchange security information between various applications (such as OpenStack or various BSS / OSS components) and security controllers.
  • the design goal of the Consumer-Facing Interface is to separate the specification of security services from the implementation.
  • NSF-Facing Interfaces are used to separate security management schemes from NSF sets and various implementations. It is independent of the way it is (for example: virtual machines or real appliances).
  • the following describes an object-oriented information model for network security, content security, and attack mitigation capability with associated I2NSF policy objects.
  • AAA Access control, Authorization, Authentication
  • ACL Access Control List
  • GNSF Generic Network Security Function
  • I2NSF Interface to Network Security Functions
  • NSF Network Security Function
  • VPN Virtual Private Network
  • the starting point for the design of the Capability Information Model is to classify the types of security capabilities. For example, to classify types of security capabilities such as "IPS”, “anti-virus” and “VPN concentrator.”
  • a "packet filter” can be classified as a storage device that can allow or deny packet delivery according to various conditions (e.g., source and destination IP address, source and destination port and IP protocol type fields, etc.).
  • Such a device filters packets or communications but differs in categorizing and maintaining packets and communications.
  • channel protection protocols can protect packets through symmetric algorithms that can be negotiated with asymmetric cryptography, and can operate at different layers and support different algorithms and protocols.
  • the capability information model defines a security capability model that provides the basis for automatic management of the NSF.
  • the capability information model also allows the security controller to properly identify and manage the NSF, and to allow the NSF to properly declare the capabilities to use them in the right way.
  • the system should be able to auto-detect, auto-negotiate and auto-update security capabilities (ie without user intervention). This automation capability is particularly useful for managing multiple NSFs.
  • Scalability The management system must have scale up / down or scale in / out capabilities. Thus, this scalability can meet various performance requirements derived from changeable network traffic or service requests. In addition, security capabilities that are affected by scalability can help determine whether scaling statistics should be invoked by supporting reporting statistics on the security controller.
  • the security controller compares the user and application requirements with the currently available set of capabilities and selects the NSF needed to meet those requirements.
  • NSF negative-day exploits and unknown malware
  • a new ability may be created and / or an existing ability may be updated (eg, By updating the signature and algorithm).
  • existing NSFs will be enhanced (and / or created new NSFs) to address new threats.
  • New capabilities can be transferred to a central repository and stored, or individually stored in a vendor's local repository. In both cases the standard interface makes the update process easy.
  • Event-Condition-Action (ECA) policy model is used as the basis for the design of I2NSF policy rules.
  • terms related to I2NSF policy may be defined as follows (see [I-D.draft-ietf-i2nsf-terminology]):
  • An event occurs when a managed system changes and / or at a critical point in the environment of the managed system.
  • An event can be used to determine whether the condition clause of an I2NSF policy rule can be evaluated when used in the context of an I2NSF policy rule.
  • Examples of I2NSF events may be time and user actions (eg, actions that violate logon, logoff, and ACLs).
  • a condition is defined as a set of attributes, capabilities, and / or values to be compared to a set of known attributes, features, and / or values to enable or disable the (implicit) I2NSF policy rule.
  • I2NSF conditions may include comparing the matched attribute of a packet or flow and the internal state of the NSF to the desired state.
  • Actions are used to control and monitor aspects of flow-based NSF when event and condition clauses are met.
  • NSF implements various actions to provide security capabilities. Examples of I2NSF tasks may include intrusion detection and / or protection, web and flow filtering, and deep packet inspection of packets and flows.
  • the I2NSF policy rule consists of three Boolean clauses: an event clause, a condition clause, and an action clause.
  • Boolean clause means a logical statement that evaluates to TRUE or FALSE and can consist of one or more terms.
  • the Boolean clause uses logical linking elements (that is, AND, OR, and NOT) to link the terms.
  • the logical connection element may have the meaning as shown in Table 1 below.
  • a "policy rule” can actually act as a container that aggregates not only the metadata but also the "events”, “actions” and “conditions” described earlier.
  • the ECA policy model described earlier is very generic and easily extensible and avoids potential constraints that can limit the implementation of general security capabilities.
  • FIG 3 shows an example of the overall I2NSF information model design to which the present invention can be applied.
  • the I2NSF NSF-Facing Interface uses the capabilities of the NSF to select and manage the NSF, which is performed using the following approach.
  • the security controller selects the set of capabilities necessary to meet the requirements of the security service from all available NSFs it manages.
  • the security controller uses the Capability Information Model to match selected capabilities to vendor-independent NSFs.
  • the security controller takes the above information and creates or uses one or more data models of the capability information model to manage the NSF.
  • the data model represents the concept of interest in the environment in a format that depends on the storage of the data, the data definition language, the query language, the implementation language and the protocol.
  • the information model also represents the concept of interest in the environment in a form that is independent of the data store, data definition language, query language, implementation language, and protocol.
  • Ability can be defined as a class (e.g., a set of objects representing a set of common characteristics and behaviors) (see I-D.draft-ietf-supa-generic-policy-info-model).
  • Each capability can consist of one or more model elements (eg: attributes, methods, or relationships) that distinguish it from all other objects in the system.
  • a capability is usually some kind of metadata (ie information describing and / or prescribing an object's behavior).
  • each capability can be used by an external information model to define metadata (preferably in the form of a class hierarchy).
  • capabilities can be subclassed in an external metadata model.
  • Capability submodels are used to advertise, create, select, and manage specific sets of security capabilities that are independent of the type and vendor of the NSF.
  • NFC-Facing Interface users of the NSF-Facing Interface do not consider whether NFC is virtualized or hosted, who the NSF provider is, or the set of entities with which the NSF communicates (for example, a firewall or IPS).
  • the user only considers a set of capabilities such as packet filtering or deep packet inspection that the NSF has.
  • All external models shown in FIG. 3 may be based on the SUPA information model (see I-D.draft-ietf-supa-generic-policy-info-model).
  • the class of the capability submodel inherits a set of AggregatesMetadata from the external metadata information model.
  • the external ECA information model shown in FIG. 3 provides a minimal set of classes representing general ECA policy rules and a set of classes representing events, conditions, and actions that can be aggregated by the general ECA policy rules.
  • I2NSF not only to reuse this generic model for other purposes, but also to create new subclasses or add attributes and relationships to represent I2NSF-related concepts.
  • the external ECA information model has the capability of collecting metadata. Capabilities can be subclassed in the appropriate class of the external metadata information model.
  • Capabilities are commonly used to represent NSF functions that can be called. Because capabilities are objects, they can be used in sections describing events, conditions, and / or actions of I2NSF ECA policy rules.
  • the I2NSF capability information model embodies a predefined metadata model. Application of the I2NSF capability may be performed by modifying a predefined ECA policy rule information model that defines how to use, manage or manipulate the capability set.
  • I2NSF policy rules can act as containers consisting of three clauses: the event clause, the condition clause, and the action clause.
  • the I2NSF policy engine When the I2NSF policy engine receives a series of events, it matches the events in the active ECA policy rule. If the event matches, it triggers the evaluation of the condition clause of the matching I2NSF policy rule. If the condition clause is evaluated and it matches, then a sequence of actions in the matching I2NSF policy rule can be executed.
  • Network security is a category for describing how to inspect and process network traffic using predefined security policies.
  • the inspection portion may be a packet processing engine that inspects packets passing through the network either directly or in the context of the flow with which the packets are associated. From the point of view of packet processing, the depth of the packet header and / or payload that can be implemented, the various flows and context states that can be maintained, and the actions applicable to the packet or flow may vary from implementation to implementation.
  • Content security is another category of security features that apply to the application layer. For example, by analyzing the content of traffic delivered at the application layer, you can identify the various security features required by using content security features.
  • This may include defending against intrusions, virus scanning, filtering of malicious URLs or junk mail, blocking illegal web access, or preventing malicious data retrieval.
  • each threat type in content security has its own set of characteristics and must be addressed using a set of methods that are unique to that type of content.
  • these features feature unique content-specific security features.
  • Attack mitigation capabilities are used to detect and mitigate various types of network attacks.
  • a typical network attack today can be defined as
  • Network layer DDoS attacks include SYN flood, UDP flood, ICMP flood, IP fragment flood, IPv6 routing header attack, and IPv6 duplicate address detection attack.
  • Application layer DDoS attacks For example, HTTP flood, https flood, cache bypass HTTP floods, WordPress XML RPC floods, and ssl DDoS.
  • Each type of network attack has its own network behavior and packet / flow characteristics. Thus, each type of attack requires special security features that inform the set of capabilities for detection and mitigation. Implementation and management of these security categories
  • the attack mitigation controls can be very similar to the content security control categories.
  • the purpose of the competency information submodel is to define the notion of a competency and to aggregate capabilities into the appropriate objects.
  • the network security, content security, and attack mitigation submodels will be described.
  • FIG. 4 shows an example of a network security information sub-model overview to which the present invention can be applied.
  • the purpose of the Network Security Information submodel is to define how network traffic is defined and to determine whether one or more network security features should be applied to the traffic.
  • ECA policy rules are defined in an external ECA information model along with events, conditions, and action objects.
  • the network security submodel can extend all these objects to define extensions to security-related ECA policy rules and (general) event, condition, and action objects.
  • I2NSF policy rules are a special type of policy rule in the form of event condition actions (ECA). It can consist of policy rules, components of policy rules (for example: some extensions such as events, conditions, action and resolution policies, default actions, and external data), and optionally metadata, and one-way and two-way traffic through NSF. Can be applied to both.
  • ECA event condition actions
  • FIG. 5 shows an example of extension of a network security information submodel to which the present invention can be applied.
  • FIG. 5 shows an example of a more detailed design of an ECA policy rule subclass included in the network security information submodel. This shows how more specific network security policies are migrated and extended in the SecurityECAPolicyRule class.
  • the SecurityECAPolicyRule is located at the top of the I2NSF ECA policy rule hierarchy. This rule is migrated from (external) general ECA policy rules and represents the specialization of these general ECA policy rules for adding security-related ECA policy rules.
  • the SecurityECAPolicyRule contains all the attributes, methods, and relationships defined in the super class and adds additional concepts for network security.
  • the six SecurityECAPolicyRule subclasses extend the SecurityECAPolicyRule class to represent six types of Network Security ECA Policy Rules.
  • the generic (external) ECAPolicyRule class can define basic information in the form of attributes such as unique object IDs, as well as descriptions and other necessary information.
  • a network security policy consists of one or more ECA policy rules, organized by the information model described above. In the simple case where the event and condition clauses have not changed, an action in one policy rule can invoke additional network security actions in another policy rule.
  • the network security policy inspects traffic and performs basic processing as follows.
  • the NSF evaluates the event clause of a given SecurityECAPolicyRule (which may be generic or specific to security as shown in FIG. 3).
  • Security event objects can be used to perform all or part of the evaluation described below.
  • conditional clause can then be evaluated. All or some of the evaluations described below can be performed using the Security Requirements object. If the condition clause evaluates to TRUE, it is defined as "matching" the SecurityECAPolicyRule. Otherwise, the SecurityECAPolicyRule stops running and the next SecurityECAPolicyRule can be evaluated.
  • Step 3 A series of tasks to be executed is retrieved and a resolution strategy is used to define the order of execution.
  • the process may include the use of optional external data related to the SecurityECAPolicyRule.
  • the NSF can perform the actions defined by the resolution strategy.
  • the resolution strategy may allow only a single action (e.g., FMR or LMR) to be executed or allow all actions to be executed (optionally or in a particular order).
  • the NSF first performs the function and then checks whether a specific security function is referenced in the rule. If yes, go to Step 5. If no, traffic is allowed.
  • the NSF can be configured to use the referenced security features (eg For example: check condition or action enforcement).
  • FIG. 6 shows an example of extension of a network security information submodel event class to which the present invention can be applied.
  • FIG. 6 illustrates an example of a design of an event subclass included in the network security information submodel.
  • the four Event classes of FIG. 6 extend the (external) general Event class to represent important events in network security. It can be assumed that the (external) generic Event class defines basic event information in the form of attributes, such as a unique event ID, description, and the date and time the event occurred.
  • FIG. 7 shows an example of extension of a network security information submodel condition class to which the present invention can be applied.
  • condition classes shown in FIG. 7 extend the (external) general condition class to represent conditions related to network security. Since the (external) general conditional class is abstract, it is assumed that data model optimization can be defined.
  • a generic condition class is assumed to define basic condition information in the form of attributes such as unique object ID, description, and a mechanism for associating zero or more metadata objects.
  • FIG. 8 shows an example of extension of a network security information submodel action to which the present invention can be applied.
  • FIG. 8 shows a more detailed design of the action subclass included in the network security information submodel.
  • the four operation classes of FIG. 8 represent operations for extending the (external) general operation class to perform network security control functions.
  • the three operational classes in FIG. 8 extend the (external) general operational class to represent tasks related to network security. Since the (external) Generic Action class is abstract, data model optimization can be defined.
  • a generic action class is assumed to define basic action information in the form of attributes, such as a unique object ID, description, and a mechanism for attaching zero or more metadata objects.
  • FIG 9 shows an example of a high level model of I2NSF security function to which the present invention can be applied.
  • the I2NSF functional model is composed of many functions representing various content security and attack mitigation functions. Each feature protects against certain types of threats at the application layer.
  • FIG. 10 shows an example of a network security function information model to which the present invention can be applied.
  • GNSS Generic Network Security Function
  • content security may be configured with various unique security functions. Each of these capabilities can protect content from certain types of threats at the application layer.
  • the content security may be a Generic Network Security Function (GNSS) type, as shown in FIG. 10.
  • GNSS Generic Network Security Function
  • FIG 11 shows an example of an attack mitigation function information model to which the present invention can be applied.
  • attack mitigation may be composed of several GNSFs. Each protects your content from certain types of network attacks.
  • Acknowledge mitigation security is a type of GNSF that summarizes well-defined security features.
  • I2NSF Security Policy Rule I2NSF Security Policy Rule
  • I2NSF security policy rules represent policy rules for general network security functions.
  • the object of the policy rule may be defined as policy information and rule information. This can include ECA policy rules such as Event Clause Objects, Condition Clause Objects, Action Clause Objects, Resolution Strategy, and Default Action.
  • events can occur when a managed system changes and / or at a critical point in the environment of the managed system.
  • Event Clause Objects can be used to determine whether the condition clause of an I2NSF policy rule can be evaluated when used in the context of an I2NSF policy rule.
  • the targets of the event clause can be defined as user security events, device security events, system security events, and time security events.
  • the subject of the event clause can be extended according to specific vendor event capabilities.
  • a condition is defined as a set of attributes, functions, and / or values to be compared to a set of known attributes, features, and / or values, as discussed above, to enable or disable the (implicit) I2NSF policy rule.
  • Such objects may be defined as packet security conditions, packet payload security conditions, target security conditions, user security conditions, context conditions, and general context conditions.
  • Objects in the Action clause can be extended according to specific vendor condition capabilities.
  • Actions are used to control and monitor aspects of flow-based NSF when event and condition clauses are met.
  • NSF implements various actions to provide security.
  • the object of the action clause may be defined as an input action, a transmit action, and an application profile action, and the object of the action clause may be extended according to a specific vendor action function.
  • the structure of the data model proposed in the present invention has been considered as follows.
  • -Consider NSF feature categories e.g. network security, content security and attack mitigation.
  • 12A and 12B illustrate a data model structure for network security policy identification according to an embodiment of the present invention.
  • the data model for identifying a network security policy may be configured in a structure as shown in FIGS. 12A and 12B.
  • the data model for identifying a network security policy may consist of a security policy, an event clause container, a condition clause container, and an action clause container.
  • the security policy field may consist of policy name, policy rules, resolution strategy, and fixed action.
  • Policy rules are id to identify the rule, description to describe the rule, rev, priority, policy-event-clause-agg-ptr *, policy-condition-clause-agg-ptr *, policy-action-clause-agg It can consist of -ptr * and time-zone.
  • the time-zone may include an absolute-time-zone and a periodic-time-zone so that the applied rule may be set to a periodic time in addition to an absolute time.
  • absolute-time-zone sets the start-time? and end-time? to set the start time and end time to set the absolute time or date the rule applies to. And absolute-date * for setting the date.
  • periodic-time-zone may include day and month for setting a periodic time to apply the rule.
  • resolution-strategy is a resolution-strategy-type for setting the strategy type to set the resolution strategy for the rule, and a first-matching-rule for setting the first matching rule. And last-matching-rule? For setting the last matching rule.
  • Default-action is a field for setting an action that can be performed when there is no selected action and can set an action type.
  • the event-clause-container, condition-clause-container and action-clause-container can be used by policy rules to aggregate "events", "actions” and "conditions”.
  • FIG. 13 illustrates a data model structure for an event rule according to an embodiment of the present invention.
  • an event refers to an event that occurs when a managed system changes and / or at a critical point in the environment of the managed system.
  • the objects for the event clause shown in FIG. 13 may be defined as a user security event, a device security event, a system security event, and a time security event. These objects can be extended according to specific vendor event capabilities, and additional event objects can be added for more general network security features.
  • 14A to 14D illustrate a data model structure for a condition rule according to an embodiment of the present invention.
  • a condition may be defined as a set of attributes, functions and / or values to be compared to a set of known attributes, features and / or values, as discussed above, to enable or disable the (implicit) I2NSF policy rule.
  • the object for the condition rule may be defined as a packet security condition, a packet payload security condition, a target security condition, a user security condition, a context condition, and a general context condition.
  • condition rules can be extended according to specific vendor condition functions, and condition objects for more general network security functions can be added.
  • the data model structure for the condition rule is pkt-sec-cond-tcp-src-port *, pkt-sec-cond-tcp-dest-port *, pkt-sec-cond-udp Rules related to port numbers can be set through -src-port * and pkt-sec-cond-udp-dest-port *.
  • 15A and 15B illustrate a data model structure for an action rule according to an embodiment of the present invention.
  • Actions are used to control and monitor aspects of flow-based NSF when event and condition clauses are met.
  • Such entities may be defined as receive actions, transmit actions and application profile actions. These objects can be extended to specific vendor job functions, and you can add action objects for more general network security functions.
  • the structure of the data model for the condition rule and the action rule shown in Figs. 14A to 15B can apply multiple conditions because a container structure is used.
  • 16A to 18J illustrate the YANG data module of the I2NSF NSF-Facing-Interface according to an embodiment of the present invention.
  • a YANG data model for an information model of network security functions may be set using the data model described with reference to FIGS. 12A through 15B.
  • FIGS. 16A-18J may be defined as both data modules for network security functions.
  • NSF for example: FW, IPS, Anti-DDOS or Anti-Virus functions
  • managed entities for example: NMS, security controllers
  • I2NSF NSF-Facing Interface see ID.ietf-i2nsf-terminology.
  • the monitoring part means obtaining important information about the NSF. Notifications, events, records, counters. When performed in a timely and comprehensive manner, NSF monitoring plays an important role in the overall security framework.
  • the monitoring information generated by the NSF may be an early indication of malicious activity or potential signs of abnormal behavior or denial of service attacks.
  • NSF monitoring data can be used in the following situations:
  • monitoring plays a very important role in the overall security framework. Monitoring the NSF provides information critical to the security controller in maintaining a defined security posture. There are other reasons for monitoring NSF as well.
  • Security administrators can configure policies to trigger on specific events that occur on NSFs or networks.
  • the security controller monitors specified events and configures additional security features based on the policy when the event occurs.
  • NSF's event and activity logs can be used to build advanced analytics such as behavior and predictions to improve security posture.
  • Security controllers can use events from NSF to achieve high availability. Corrective actions can be taken, such as restarting a failed NSF or scaling out an NSF.
  • NSF's event and activity logs can be helpful for debugging operational issues and root cause analysis.
  • -NSF's activity records can be used to create record data for operational and business reasons.
  • the present invention may define a series of information elements (and ranges thereof) that can be obtained from NSF and used as monitoring information.
  • this type of monitoring information can be utilized to support continuous visibility into different levels of granularity and can be consumed by the function.
  • message_version A two-digit decimal number starting with 01 indicating the version of the data type.
  • message_type event, warning, alarm, log, counter, etc.
  • time_stamp Indicates the time the message was created.
  • vendor_name The name of the NSF vendor.
  • NSF_name The name (or IP) of the NSF generating the message.
  • Module_name Module name to display the message
  • Severity indicates the level of the log. There are a total of eight levels (0 to 7), the smaller the number, the higher the severity.
  • the extended information model is only used for structured data such as alarms. Unstructured data is specified only in the basic information model.
  • module_name indicates the NSF module responsible for generating the alarm.
  • Threshold the threshold that triggers the alarm
  • risk level e.g., risk level, high, medium, low
  • the following information may be included in the CPU alarm.
  • threshold the threshold that triggers the event
  • risk level e.g., risk level, high, medium, low
  • the following information may be included in the disk alarm.
  • threshold the threshold that triggers the event
  • risk level e.g., risk level, high, medium, low
  • the following information may be included in the hardware alarm.
  • component_name Indicates the HW component generating this alarm.
  • Threshold the threshold that triggers the alarm
  • risk level e.g., risk level, high, medium, low
  • the following information may be included in the interface alarm.
  • interface_state 'UP', 'DOWN', 'CONGESTED'
  • threshold the threshold that triggers the event
  • risk level e.g., risk level, high, medium, low
  • the following information may be included in the event.
  • event_name "ACCESS_DENIED"
  • group the group to which the user belongs
  • login_ip_address The user's login IP address
  • authentication_mode User authentication mode. For example: local authentication, third party server authentication, certificate exemption, SSO authentication
  • the following information may be included in the event.
  • group the group to which the user belongs
  • login_ip_address The user's login IP address
  • authentication_mode User authentication mode. For example: local authentication, third party server authentication, certificate exemption, SSO authentication
  • the access log records the administrator's login, logout, and device activity, and analyzes them to identify security vulnerabilities. Operational reports may include the following information:
  • login_ip_address IP address used by the administrator to log in
  • login_mode Specifies the administrator login mode (for example: root, user).
  • operation_type The type of operation the administrator performs (eg, login, logout, configuration, etc.)
  • -content the action taken by the administrator after login.
  • Running reports record the running status of the device system, which is useful for device monitoring.
  • the performance report may include the following information:
  • system_status the current running state of the system
  • -CPU_usage Specify CPU usage.
  • memory_usage Specifies memory usage.
  • -disk_usage Specify disk usage.
  • -disk_left Specifies the disk space available.
  • -session_number Specifies the total number of concurrent sessions.
  • -process_number Specifies the total number of system processes.
  • in_traffic_rate Total inbound traffic rate (pps)
  • User activity records provide visibility into the user's online history (login time, online / lockout period and login IP address) and the tasks that the user performs. User activity reports are useful for identifying exceptions during user login and network access activity.
  • group the group to which the user belongs
  • login_ip_address The user's login IP address
  • authentication_mode User authentication mode. For example: local authentication, third party server authentication, certificate exemption, SSO authentication
  • access_mode the user access mode. For example: PPP, SVN, LOCAL
  • lockout_duration lockout duration
  • Interface counters provide visibility into traffic and bandwidth usage to and from the NSF.
  • interface_name Network interface name configured in the NSF
  • in_traffic_ave_rate Average rate for inbound traffic (pps)
  • in_traffic_peak_rate Inbound traffic peak rate (pps)
  • in_traffic_ave_speed Inbound traffic average speed (bps)
  • in_traffic_peak_speed Inbound traffic peak speed (bps)
  • out_traffic_ave_rate Average rate for outbound traffic (pps)
  • out_traffic_peak_rate Outbound traffic peak rate (pps)
  • out_traffic_ave_speed Outbound traffic average speed (bps)
  • the DDos event may include the following information.
  • sub_attack_type Syn flood, ACK flood, SYN-ACK flood, FIN / RST flood, TCP connection flood, UDP flood, Icmp flood, HTTPS flood, HTTP flood, DNS query flood, DNS reply flood, SIP flood, etc.
  • dst_ip IP address of the victum under attack
  • dst_port The port number for which traffic is targeted.
  • start_time a timestamp indicating when the attack started
  • end_time A timestamp indicating when the attack ended. If the attack continues to occur when sending an alert, this field may be empty.
  • attack_rate PPS of attack traffic
  • attack_speed bps of attack traffic
  • rule_id The ID of the rule that is triggered.
  • rule_name The name of the rule to be triggered
  • -Profile The security profile that the traffic matches.
  • the following information may be included in the session table event.
  • threshold the threshold that triggers the event
  • the following information may be included in the virus event.
  • virus type eg trojan, worm, macro
  • virus type eg trojan, worm, macro
  • virus name eg trojan, worm, macro
  • dst_ip destination IP address of the packet where the virus was found
  • src_ip Source IP address of the packet where the virus was found
  • src_port the source port of the packet where the virus was found
  • dst_port the destination port of the packet where the virus was found
  • src_zone Source security zone of the packet where the virus was found
  • dst_zone The target security zone of the packet where the virus was found
  • file_name The name of the file where the virus is hidden
  • raw_info Information describing the packet that triggers the event.
  • rule_id The ID of the rule being triggered.
  • rule_name The name of the rule to be triggered
  • -Profile The security profile that the traffic matches.
  • Event_name Event Name: 'SEC_EVENT_Intrusion'
  • sub_attack_type attack type, eg brutal force, buffer overflow
  • dst_ip the destination IP address of the packet
  • src_port the source port number of the packet
  • dst_port the destination port number of the packet
  • src_zone the packet's source security zone
  • dst_zone the target security zone of the packet
  • Transport layer protocol used, e.g. TCP, UDP
  • app adopted application layer protocol (e.g. HTTP, FTP)
  • HTTP HyperText Transfer Protocol
  • rule_id The ID of the rule being triggered.
  • rule_name the name of the rule to be triggered
  • intrusion_info A brief description of the intrusion
  • raw_info Information describing the packet that triggers the event.
  • Botnet event Botnet Event
  • the following information may be included in the botnet event.
  • Event_name Event Name: 'SEC_EVENT_Botnet'
  • botnet_name The name of the detected botnet
  • src_port the source port number of the packet
  • dst_port the destination port number of the packet
  • src_zone the packet's source security zone
  • dst_zone the target security zone of the packet
  • Transport layer protocol used, e.g. TCP, UDP
  • app adopted application layer protocol (e.g. HTTP, FTP)
  • HTTP HyperText Transfer Protocol
  • rule_id The ID of the rule to be triggered.
  • rule_name The name of the rule to trigger
  • raw_info information describing the packet that triggers the event
  • the following information may be included in the web attack event.
  • Event_name Event Name: 'SEC_EVENT_WebAttack'
  • sub_attack_type Specific web attack type (e.g. sql injection, command injection, XSS, CSRF)
  • src_port the source port number of the packet
  • dst_port the destination port number of the packet
  • src_zone the packet's source security zone
  • dst_zone the target security zone of the packet
  • req_method The method of requirement. E.g. 'PUT' or 'GET' in HTTP
  • filtering_type blacklist, whitelist, custom, predefined, malicious category, unknown URL filtering type
  • rule_id The ID of the rule being triggered.
  • rule_name The name of the rule to be triggered
  • -Profile The security profile that the traffic matches.
  • the following information can be included in the DDoS log.
  • attack_ave_rate average pps of attack traffic within recorded time
  • attack_ave_speed Average bps of attack traffic within recorded time
  • attack_pkt_num the number of attack packets within the recorded time
  • attack_src_ip Source IP address of the attack traffic. If you have a large number of IP addresses, choose a specific number of resources according to different rules.
  • Actions on DDoS attacks e.g., allow, warn, block, discard, declare, block IP, block service.
  • virus log In addition to the fields of the virus alert, the following information may be included in the virus log:
  • Actions dealing with viruses e.g. warnings, blocking
  • OS on which the virus is affected e.g. all, android, ios, unix, windows.
  • the following information can be included in the intrusion log:
  • OS that affects intrusions (e.g. all, android, ios, unix, windows)
  • Actions dealing with intrusions, eg allow, warn, block, discard, declare, block-IP, block-services
  • attack_rate pps NUM of the attack traffic
  • attack_speed bps of NUM attack traffic
  • botnet log In addition to the fields of the Botnet Alarm, the following information may be included in the botnet log:
  • -botnet_pkt_num Number of packets sent or received to the detected botnet
  • Actions Actions that process detected packets (e.g., allow, warn, block, discard, declare, block IP, block service, etc.)
  • os all OSs being attacked, e.g. android, ios, unix, windows, etc.
  • DPI logs can provide statistics about uploaded and downloaded files and data, sent and received emails, and alert and block records on the website.
  • DPI operation type E.g. file blocking, data filtering, application behavior control
  • file_type the file type
  • dst_zone the target security zone of the traffic
  • dst_region the destination region of the traffic
  • src_user the user who generated the traffic
  • dst_port the destination port of the traffic
  • Protocol Protocol type of traffic
  • Vulnerability search log should record the victim host and related vulnerability information. The following information should be included in the report.
  • victim_ip IP address of the victimized host with the vulnerability
  • Vulnerability ID Vulnerability ID
  • vulnerability_level The vulnerability level. E.g. high, low, low
  • protocol The protocol type. E.g. TCP, UDP
  • vulnerability_info Information about the vulnerability
  • fix_suggestion A fix proposal for the vulnerability.
  • attack_type web attack
  • raw_info Information describing the packet that triggers the event.
  • Firewall counters Firewall Counters
  • Firewall counters provide visibility into traffic signing, bandwidth usage, and how configured security and bandwidth policies are applied.
  • dst_zone the target security zone of the traffic
  • dst_region the destination region of the traffic
  • src_user the user who generated the traffic
  • dst_port the destination port of the traffic
  • Protocol Protocol type of traffic
  • in_traffic_ave_rate Average rate for inbound traffic (pps)
  • in_traffic_peak_rate Inbound traffic peak rate (pps)
  • in_traffic_ave_speed Inbound traffic average speed (bps)
  • in_traffic_peak_speed Inbound traffic peak speed (bps)
  • out_traffic_ave_rate Average rate for outbound traffic (pps)
  • out_traffic_peak_rate Outbound traffic peak rate (pps)
  • out_traffic_ave_speed Outbound traffic average speed (bps)
  • the policy hit counter records the security policy and the number of hits that the traffic matches. You can verify that the policy configuration is correct.
  • dst_zone the target security zone of the traffic
  • dst_region the destination region of the traffic
  • src_user the user who generated the traffic
  • dst_port the destination port of the traffic
  • Protocol Protocol type of traffic
  • hit_times The number of times the security policy matches the specified traffic.
  • 19A through 19J illustrate a data model for NSF monitoring according to an embodiment of the present invention.
  • a data model may be designed using the information model for monitoring the NSF described above.
  • 20A-21I illustrate a YANG data model for monitoring according to one embodiment of the invention.
  • NSF monitoring When NSF monitoring is carried out in a comprehensive way, timely detection of malicious activity, abnormal behavior or potential denial of service attacks can be detected. This monitoring feature is based on the monitoring information generated by the NSF discussed earlier.
  • the present invention proposes a method of designing a corresponding YANG data model for NSF monitoring as well as a data model structure tree specifying an information model for NSF monitoring.
  • a corresponding YANG data model may be designed using the information model and data model for NSF monitoring described above.
  • 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), and 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
  • an embodiment of the present invention may be implemented in the form of a module, procedure, function, etc. that performs the above-described functions or operations.
  • 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 security management systems.

Landscapes

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

Abstract

La présente invention concerne un procédé et un appareil permettant de fournir un service de sécurité par un système de gestion de fonctionnement de réseau dans un système de gestion de sécurité. La présente invention peut fournir un procédé et un appareil qui reçoivent une première politique de sécurité d'un niveau élevé d'une interface à un utilisateur de fonction de sécurité de réseau (I2NSF), génèrent une seconde politique de sécurité d'un niveau bas correspondant à la première politique de sécurité, et transmettent un paquet comprenant la seconde politique de sécurité générée de façon à configurer la seconde politique de sécurité pour chacune des multiples fonctions de sécurité de réseau (NSF), le système de gestion de fonctionnement de réseau étant connecté à chacun des multiples NSF par l'intermédiaire d'une interface orientée vers NSF (I2NSF).
PCT/KR2018/002957 2017-03-13 2018-03-13 Modèle de données yang d'interface orientée vers une fonction de sécurité de réseau i2nsf WO2018169294A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR20170031427 2017-03-13
KR10-2017-0031427 2017-03-13

Publications (1)

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

Family

ID=63522442

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2018/002957 WO2018169294A1 (fr) 2017-03-13 2018-03-13 Modèle de données yang d'interface orientée vers une fonction de sécurité de réseau i2nsf

Country Status (1)

Country Link
WO (1) WO2018169294A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110007924A (zh) * 2019-03-29 2019-07-12 烽火通信科技股份有限公司 Yang模型配置界面的自动化构建方法及系统
US20210029175A1 (en) * 2019-07-24 2021-01-28 Research & Business Foundation Sungkyunkwan University Security policy translation in interface to network security functions

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040042609A1 (en) * 2002-09-04 2004-03-04 Tekelec Methods and systems for enhancing network security in a telecommunications signaling network
US20090077086A1 (en) * 2007-09-19 2009-03-19 International Business Machines Corporation Policy-based method for configuring an access control service
US20150207813A1 (en) * 2012-02-01 2015-07-23 Vorstack, Inc. Techniques for sharing network security event information
US20160352780A1 (en) * 2007-09-17 2016-12-01 Ulrich Lang Method and system for managing security policies
US9521115B1 (en) * 2016-03-24 2016-12-13 Varmour Networks, Inc. Security policy generation using container metadata

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040042609A1 (en) * 2002-09-04 2004-03-04 Tekelec Methods and systems for enhancing network security in a telecommunications signaling network
US20160352780A1 (en) * 2007-09-17 2016-12-01 Ulrich Lang Method and system for managing security policies
US20090077086A1 (en) * 2007-09-19 2009-03-19 International Business Machines Corporation Policy-based method for configuring an access control service
US20150207813A1 (en) * 2012-02-01 2015-07-23 Vorstack, Inc. Techniques for sharing network security event information
US9521115B1 (en) * 2016-03-24 2016-12-13 Varmour Networks, Inc. Security policy generation using container metadata

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110007924A (zh) * 2019-03-29 2019-07-12 烽火通信科技股份有限公司 Yang模型配置界面的自动化构建方法及系统
US20210029175A1 (en) * 2019-07-24 2021-01-28 Research & Business Foundation Sungkyunkwan University Security policy translation in interface to network security functions
US11632402B2 (en) * 2019-07-24 2023-04-18 Research & Business Foundation Sungkyunkwan University Security policy translation in interface to network security functions

Similar Documents

Publication Publication Date Title
US11616761B2 (en) Outbound/inbound lateral traffic punting based on process risk
WO2021060857A1 (fr) Système de gestion de flux de commande de nœud à base de code d'exécution à distance et procédé associé
US8281019B1 (en) Method and system for scanning network devices
US10855656B2 (en) Fine-grained firewall policy enforcement using session app ID and endpoint process ID correlation
WO2019066295A1 (fr) Système et procédé de journalisation de trafic web permettant de détecter un piratage web en temps réel
WO2013085281A1 (fr) Procédé et dispositif de sécurité dans un service informatique en nuage
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
WO2019098678A1 (fr) Procédé permettant de fournir un service de sécurité et dispositif associé
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
WO2020009418A1 (fr) Modèle de données yang d'interface côté fonctions de sécurité de réseau d'i2nsf
WO2020149617A1 (fr) Procédé de sécurisation d'une communication de message de monodiffusion dans des réseaux sans fil basés sur 3gpp
WO2019143043A1 (fr) Procédé et dispositif de diagnostic de performances de réseau, et système
CN111295640B (zh) 使用会话app id和端点进程id相关性的精细粒度防火墙策略实施
WO2016013846A1 (fr) Procédé de traitement de message de demande dans un système de communications sans fil, et appareil associé
WO2018169294A1 (fr) Modèle de données yang d'interface orientée vers une fonction de sécurité de réseau i2nsf
Ceron et al. MikroTik devices landscape, realistic honeypots, and automated attack classification
WO2023017931A1 (fr) Dispositif de traitement d'informations de cybermenace, procédé de traitement d'informations de cybermenace et support de stockage stockant un programme de traitement d'informations de cybermenace
Han et al. State-aware network access management for software-defined networks
Scarfone et al. Intrusion detection and prevention systems
EP1542116A1 (fr) Multiplexeur d'accès ayant la capacité de détection d'intrusion
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é
WO2018169292A1 (fr) Procédé et système pour fournir un service de sécurité et dispositif associé
Gao et al. Software-defined firewall: Enabling malware traffic detection and programmable security control
Gonçalves et al. IPS architecture for IoT networks overlapped in SDN

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

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

Country of ref document: EP

Kind code of ref document: A1

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