JP6832990B2 - Security in software defined networking - Google Patents

Description

The present application generally relates to communication networks, and more specifically to security techniques in communication networks based on software-defined networking.

This section presents views that may help promote a better understanding of the invention. Therefore, the wording in this section should be read from this point of view and should not be understood as an approved fact about what is included in the prior art or what is not included in the prior art.

Software Defined Networking (SDN) is a network architecture framework that separates network control from the underlay's network exchange infrastructure so that it is directly programmable. This decoupling allows the underlay network infrastructure to be abstracted for the applications and services running on that network. The SDN controller is used to manage flow control within the SDN network. For example, SDN controllers are typically based on protocols that allow control servers to direct network elements (eg, switches) to destination packets, such as the OpenFlow (Open Networking Foundation) protocol. In such a scenario, the SDN controller is called the OpenFlow controller and the switch is called the OpenFlow switch. Such a controller acts as a kind of operating system for SDN networks. By separating the control plane from the network hardware and instead running the control plane as software, the controller facilitates automated network management, as well as application and service integration and management.

However, SDN networks have difficult security issues that cannot be addressed by existing security mechanisms.

Security techniques for use within the SDN network are provided by exemplary embodiments.

For example, in one embodiment, the method comprises the following steps. At least one security policy is obtained from the policy creator on the controller in the SDN network. Security policies are implemented in SDN networks through controllers based on one or more attributes that specify the characteristics of the security policy, the role of the security policy creator, and the security privilege level of the role of the security policy creator. To.

In another embodiment, a product is provided that includes a processor-readable storage medium in which the executable code of one or more software programs is encoded therein. The software program, when executed by at least one processing device, implements the steps of the method described above.

In yet another embodiment, the device comprises a memory and a processor configured to perform the steps of the method described above.

Advantageously, exemplary embodiments provide techniques for addressing security issues within SDN networks, which accurately translate network policies into flow rules, where new flow rules conflict with previous flow rules. Includes, but is not limited to, addressing these scenarios, responding automatically and immediately to new security attacks, and assisting in packet data scan detection.

These and other features and advantages of the embodiments described herein will become more apparent from the accompanying drawings and the detailed description below.

It is a figure which shows the SDN network which has a security architecture by one Embodiment. It is a figure which shows the security method for use in SDN network by one Embodiment. It is a figure which shows the processing platform which implements the SDN network which has a security architecture by one or more embodiments.

In this specification, exemplary embodiments are made with reference to examples of computing systems, data storage systems, communication networks, processing platforms, systems, user devices, network nodes, network elements, clients, servers, and related communication protocols. Will be described. For example, exemplary embodiments are particularly well suited for use in software-defined networking (SDN) environments. However, the embodiments are not limited to use in the particular configuration described and are generally widely used in any environment where it is desirable to instead provide mechanisms and methodologies for improving security within communication networks. It should be understood that it is applicable.

As mentioned above, SDN networks have difficult security issues that cannot be addressed using existing security mechanisms and methodologies. An exemplary embodiment addresses such a difficult security issue.

For example, one security issue addressed herein is how to ensure that the SDN controller receives network policies in a secure manner. It is recognized that SDN controllers should ensure that policy makers (eg, applications, network administrators, and management servers) are authentic. In addition, confidentiality and integrity must be guaranteed for these policies in transit. The exemplary embodiments provide these guarantees, as described in detail below.

Another security issue addressed herein is how to accurately translate network policies into flow rules. It is recognized that network policies (security policies in this case) must be accurately translated into flow rules based on attributes such as the policy creator's identifier, role, and security privilege level. In this way, one or more of the security countermeasures can be operated without bypass. As described in detail below, exemplary embodiments provide this exact transformation.

Yet another security issue addressed herein is how to implement packet data scan detection. Currently, as part of one of the implementations of the SDN Southbound interface, the OpenFlow protocol only supports packet header scan detection. In the OpenFlow switch, the flow is forwarded or dropped by matching the match field in the OpenFlow table with the packet header. However, it is recognized that packet data scan detection must be performed to prevent some attacks such as worms and spam information. As described in detail below, exemplary embodiments provide packet scan detection that addresses these issues.

Yet another security issue addressed herein is how to handle new flow rules that conflict with old flow rules. For example, assume that the new flow rule created by switch _1 specifies that a packet with WLAN_ID_4 is forwarded to port 5. Further assume that the old flow rule of switch _1 that specifies that a packet with VIN_ID_4 is forwarded to port 6 is replaced with a new flow rule. However, the old flow rules were created by security administrators to force packet scan detection. This old flow rule must not be replaced by the new flow rule. Illustrative embodiments address this type of inconsistency problem, as described in detail below.

Yet another security issue addressed herein is how to secure the flow rules transmitted from the SDN controller to the network switch. The OpenFlow protocol states that Transport Layer Security (TLS) may be used to secure transmission. However, implementation details such as which versions and cipher suites can be used are not discussed. An exemplary embodiment addresses this issue, as described in detail below.

Another security issue addressed herein is how to react automatically and immediately to new attacks. An exemplary embodiment addresses this issue, as described in detail below.

Yet another security issue addressed herein is how to ensure that the SDN controller's execution environment is secure. The logically centralized SDN controller gives operators more flexibility in programming their networks. However, a logically centralized SDN controller can also expose a single high-value asset to an attacker. It is important for the operator to mitigate some of the threat by deploying the SDN controller in a secure execution environment. An exemplary embodiment addresses this issue, as described in detail below.

An exemplary embodiment provides an SDN security architecture that addresses the aforementioned and other security issues. Specifically, the exemplary embodiment introduces attributes related to flow rules within the SDN controller to address such security issues. In one embodiment, these security attributes include: (i) the characteristics of the network policy, (ii) the role of the policy creator, and (iii) the security privilege level of that role. Each of these three security features is designated as a separate attribute, as exemplified herein, but one or more of the security features can be combined and designated as one attribute. Is understood.

The attributes of the network policy characteristics are used to indicate whether the new network policy is a real-time policy or can be operated with some delay. For real-time policies, the policy must be translated into flow rules, updated in the flow table, and then synchronized to the SDN switch without any delay. These real-time policies may react to security attacks detected online by security devices (eg, firewalls, DPI, and IDP). For these policies, which may operate with some delay, the policies are periodically batch converted into flow rules, updated in the flow table, and then synchronized to the SDN switch to improve system performance. To.

The policy author role attribute is used to define the role of the administrator / application that created a given network policy. The creator role may be a security administrator, general administrator, user, or guest.

Role security privilege level attributes are used to specify different security privilege levels for different roles of policy authors. Hierarchical levels may be L5, L4, L3, L2, L1 and L0 from higher to lower. Roles with a relatively high level of security privilege are given more rights to access the SDN controller. For example, a policy created by an author with a relatively low security privilege level is replaced by a policy created by an author with a higher level of security. In one exemplary embodiment, the security privilege levels of the roles can be set as: Security Administrator-L5 (Highest), General Administrator-L4, User-L2, and Guest-L1. In this exemplary embodiment, it is understood that security privilege levels L3 and L0 do not have a dedicated role. However, the amount and assignment of security privilege levels are open to developers and can be instantiated based on the specific needs of the SDN network design.

The exemplary embodiment also provides improved flow table management capabilities. This feature is used to deal with situations when the new flow rule conflicts with the old flow rule. Currently, the flow items in the OpenFlow table do not distinguish between applications that generate new flow rules and applications that generate old rules. Thus, an attacker attempting to hijack an application server could create a new flow rule to bypass the security detection and replace it with the flow rule created by the security administrator. Based on the above-mentioned three new attributes defined in the SDN controller, the above-mentioned security problem can be solved. The reason is that a flow rule created by a security administrator with a high security privilege level cannot be replaced with a new flow rule with a low security privilege level.

An exemplary embodiment also provides improved packet data scan detection. According to the current OpenFlow protocol v1.4, one feasible strategy for packet data scan detection is to select m consecutive packets from each of the n consecutive packets of interest flow for scan detection. That is. This strategy is designed for all flows, or only for flows that meet some condition, such as packets destined for a certain destination or packets with a specified virtual local area network (VLAN) identifier. Can be. According to an exemplary embodiment, the OpenFlow protocol is extended to assist in packet data scan detection. A new action (OFBAT_DECTION), described in detail below, is assigned to all flows that meet the conditions set by the security management function.

The exemplary embodiment also provides an automatic and immediate response to a new security attack. For example, security devices deployed on the data transfer plane of a network (eg firewalls, intrusion detection systems (IDS), intrusion prevention systems (IPS), deep packet inspection (DPI)) detect security attacks and manage security. Can report to features. To react to these attacks, security controls immediately define countermeasures, which are translated into the flow rules within the SDN controller and then synchronized with the SDN switch. These attack packets are then either dropped before being forwarded out of the network or forwarded to a security device for further detection. In this way, the SDN controller can automatically respond to security attacks.

With reference to FIG. 1, a security architecture for the SDN network 100 according to an exemplary embodiment is shown. In this exemplary embodiment, the first SDN controller 102-1, ie the OpenFlow controller _1, is shown. The SDN controller 102-1 is a second SDN controller 102-2, that is, an OpenFlow controller _2, and a plurality of SDN switches 104-1 (OpenFlow switch _1), 104-2 (OpenFlow switch _2), and (104-3 OpenFlow switch). It is operably combined with _3). Host computing devices 106-1 (host 1) and 106-2 (host 2) are operably coupled to the SDN switch. The host computing device can be, for example, a data server or an end user's computer. It is understood that the SDN network 100 may include more or less controllers, SDN switches, and / or host computing devices than is exemplified in FIG. For example, SDN controller 102-2 and / or additional SDN controllers (not explicitly shown) connect to additional host computing devices (not explicitly shown) with additional SDN switches (not explicitly shown). It can be configured similar to the SDN controller 102-1 to safely control (not explicitly shown).

The SDN network 100 also includes one or more security devices 108. As mentioned above, such security devices provide firewall (FW), DPI, IPS and / or IDS functions to SDN networks. Furthermore, the SDN network 100 includes an automatic security management module 110, one or more general applications 112, a load balancing module 114, an administrator management module 116, a network security monitor 118, and one or more other servers 119. ..

The SDN controller 102-1 is configured to provide one or more of the security features described above. To provide such functionality, the SDN controller 102-1 includes policy transformation module 122, policy module 124, policy characteristic attribute module 126, policy creator role attribute module 128, role security privilege level attribute module 130. , Flow table manager 132, flow table 134, rule synchronization module 136, network security monitor support module 138, authentication and authorization module 140, integrity and confidentiality module 142, system security management module 144, log and audit module 146. , And a trusted execution environment 148.

Policy module 124 has one or more policies (network policies, in this case security policies) from its northbound interface (ie from modules 110, 112 and 114) and from its management interface (ie from modules 116 and 118). Is configured to receive). To ensure that the received policy is secure, the policy creators (eg, automatic security management module 110, general application 112, load balancing module 114, and administrator management module 116) are the modules of SDN controller 102-1. Certified by 140. In addition, module 142 checks for confidentiality and integrity of these policies in transmission.

The policy characteristic attribute module 126 is configured to specify whether the policy is sent from the SDN controller 102-1 to the SDN switches 104-1, 104-2, and 104-3 in real time or periodically. Will be done. For example, this attribute may specify urgent conditions, general conditions, and default conditions. The urgent attribute specifies that this policy should be synchronized to the switch in real time without delay. For example, this policy may be a security countermeasure to prevent or mitigate a security attack detected by the firewall or DPI function of the security device 108.

Policy Creator Role Attribute Module 128 is configured to specify the policy Creator role. As mentioned above, the policy creator may be the automatic security management module 110, one or more general applications 112, the load balancing module 114, the administrator management module 116. Therefore, the role attribute of the creator may be set as a security administrator, a general administrator, a user, or a guest. In one example, the role of the automatic security management module 110 is the security administrator, the role of the load balancing module 114 is the general administrator, and the role of one or more general applications 112 is the user, and one or more. The role of the third party application (not explicitly shown) is the guest.

The security privilege level attribute module 130 for a role is configured to specify the security privilege level given to each role set by module 128. As described above as an example, the security privilege level attribute of the role is among the security privilege levels L5, L4, L3, L2, L1 and L0 in which L5 is the highest security privilege level and L0 is the lowest security privilege level. It can be set to one. In one exemplary embodiment, the security privilege levels of the roles can be set as: Security Administrator-L5 (Highest), General Administrator-L4, User-L2, and Guest-L1. Roles with higher security privilege levels are given more rights to access the SDN controller. For example, a policy created by an author with the guest role is replaced by a policy created by the author with the security administrator role.

In the policy conversion module 122, the security policy is converted to the new flow rule. That is, module 122 combines the policies received from the northbound and / or management interfaces with policy characteristics, policy author roles, and security privilege level attributes, as described in detail below. It is configured to convert (convert) into rules.

The flow table manager 132 is configured to manage the search, addition, update, and deletion of flow items in the flow table 134. The flow table manager 132 confirms that the new flow rule has been successfully inserted into the flow table 134. For example, for a given data flow, the flow table manager 132 checks if the new flow rule conflicts with the old (old) flow rule before inserting the new flow rule. In the event of a conflict, only the new flow rules set by the author with a relatively high security privilege level will replace the old flow rules set by the creator with a relatively low security privilege level. Allowed.

The flow table 134 stores the flow rules for the SDN switches 104-1, 104-2, and 104-3.

The rule synchronization module 136 synchronizes the new rules with the SDN switches 104-1, 104-2, and 104-3 on a regular basis or in real time, depending on the attributes specified by module 126. Flow rules with the "general" and "default" attributes are periodically synchronized to improve the performance of communication between the SDN controller 102-1 and a given SDN switch. However, a flow rule with the "urgent" attribute is sent to the switch as soon as the flow rule is inserted into the flow table.

The network security monitor support module 138 is configured to assist the administrator when monitoring the entire SDN network, especially with respect to security issues. For example, suppose a security administrator wants to know more about a security policy for a data flow specified through Network Security Monitor 118. The network security monitor 118 sends a request to the network security monitor support module 138. The network security monitor support module 138 fetches related information (for example, flow rule, flow rule generator, etc.) from the flow table 134, analyzes the fetched information, and responds to the network security monitor 118. The Network Security Monitor 118 generates a report and displays the report to the security administrator.

The authentication and authorization module 140 is configured to provide a mutual authentication, authentication and authorization mechanism for the SDN network 100. For example, module 140: mutual authentication via southbound interface between SDN controller 102-1 and SDN switches 104-1, 104-2 and 104.3 respectively, one or more with SDN controller 102-1. Provides mutual authentication via the northbound interface with the general application 112, as well as mutual authentication via the management interface between the SDN controller 102-1 and the administrator management module 116 and the network security monitor 118. Authentication mechanisms include, but are not limited to, validation of usernames / passwords, pre-shared keys, certificates, and the like. Authorization mechanisms include, but are not limited to, verification against blacklists / whitelists, access control lists (ACLs), and role-based access controls (RBACs).

The integrity and confidentiality module 142 is configured to provide functionality including, but not limited to, encryption / decryption, digital signatures, transport layer security (TLS), and Internet Protocol security (IPsec).

The system security management module 144 is configured to provide features including, but not limited to, software patch installation, denial of service (DoS) attack detection and prevention, and antivirus and malware detection and prevention.

Log and audit module 146 captures administrator activity (eg login activity, file access, command execution, etc.) and sets security policy author activity (eg security policy, author, author role, etc.). It is configured to provide functionality that includes, but is not limited to, capturing time).

The trusted execution environment 148 includes sensitive data (eg, SDN controller operating system, software, flow table, security policy characteristics, security policy author role, security privilege level of security policy author role, authentication credentials, etc. And authorization policies) are configured to ensure storage, processing, and protection in a trusted environment.

Assuming the exemplary security architecture of the SDN network 100 described above in the context of FIG. 1, the four security scenarios addressed by the embodiments will be described in detail next.

Scenario 1: How SDN controller 102-1 translates a policy into a new rule and then synchronizes with SDN switches 104-1, 104-2, and 104-3. It is said that the data flow from host _1 106-1 to host _2 106-2 proceeds through OpenFlow switch _2 104-2, and after the data flow is copied, it is transferred to the security device 108 (for example, firewall) for data detection. Assume that the policy is set by the automatic security management module 110. This is a security policy without bypass. The procedure for this policy, implemented in SDN Network 100, is as follows:

1.1) Mutual authentication is performed between the two before the automatic security management module 110 sends the policy to the SDN controller 102-1. The authentication mechanism may be one or more of: a) certificate, b) pre-shared key, c) username / password, and d) physical layer security protection. After successful mutual authentication, the session key between the automatic security management module 110 and the SDN controller 102-1 is acquired.

1.2) The automatic security management module 110 transmits this policy to the SDN controller 102-1 with confidentiality (encryption) and integrity protection (message / data signature). A confidentiality key and an integrity key are generated from the session key obtained in step 1.1) above.

1.3) After verifying and decrypting the data integrity using the key generated in the same way as the automatic security management module 110 does, the SDN controller 102-1 receives this policy from the automatic security management module 110. To receive. The SDN controller 102-1 checks whether the automatic security management module 110 has the right to set policies for the SDN network 100 (ie, whether the module 110 is authorized). For example, if the automatic security management module 110 is blacklisted or does not have such a right to set a policy, this policy will be revoked. It is understood that no authentication, authorization, integrity verification, and / or confidentiality verification is performed if the communication channel between the SDN controller and the policy author is known to be a secure communication channel. To.

1.4) SDN controller 102-1 translates this policy into a flow rule with the following additional attributes:
− Policy characteristics: Real time (meaning that this policy must be applied to the network without any delay)
-Role of policy creator: Security administrator, and-Security privilege level of role: L5 (highest level)

Therefore, the current flow table format in SDN controller 102-1 is extended to reflect at least the above three attributes. However, the format is not changed in any of the flow tables of SDN switches 104-1, 104-2 and 104-3.

1.5) The flow table manager 132 is triggered to check if existing or available flow rules for the specified data flow are in the current flow table 134 (eg, Source Internet Protocol (IP)). (Identified by address / port and destination IP address / port). Here, it is assumed that there are no flow rules for data flow from host _1 106-1 to host _2 106-2. The flow table manager 132 adds this flow rule to the flow table 134.

1.6) The rule synchronizer module 136 is triggered to deliver this flow rule to the associated SDN switches 104-1, 104-2, and / or 104-3 without any delay (the characteristics of this flow rule are real-time). Because it is set). Before receiving the new flow rule, each SDN switch authenticates with the SDN controller 102-1. The authentication mechanism may be one or more of: a) certificate, b) pre-shared key, c) username / password, and d) physical layer security protection. After successful mutual authentication, the session key between each SDN switch and SDN controller is obtained. This session key is used to provide confidentiality and integrity protection for new flow rules transmitted from the SDN controller to each SDN switch. It is understood that no authentication, authorization, integrity verification, and / or confidentiality verification is performed if the communication channel between the SDN controller and the SDN switch is known to be a secure communication channel. ..

1.7) After performing a data integrity check and decryption using the keys generated in the same way that the SDN controller 102-1 does, each SDN switch acquires this new flow rule and SDN Add to the switch flow table.

The data flow from host _1 106-1 to host _2 106-2 is then transmitted according to this new policy set set by the automatic security management module 110.

Scenario 2: How does the SDN controller 102-1 handle new flow rules that conflict with old flow rules? Due to the short route from OpenFlow switch _1 104-1 to OpenFlow switch _3 104-3, the data flow from host _1 106-1 to host _2 106-2 seeks higher quality of service (QoS). It is assumed that the general application 112 sets a policy of following this route. The procedure for this policy, implemented in SDN Network 100, is as follows:

2.1) Same as step 1.1) of scenario 1.

2.2) Same as step 1.2) of scenario 1.

2.3) Same as step 1.3) of scenario 1.

2.4) SDN controller 102-1 translates this policy into a new flow rule (called a second new flow rule) with the following additional attributes:
− Policy characteristics: Real time − Policy author role: User, and − Role security privilege level: L2

2.5) Flow table manager 132 is triggered to check if existing or available flow rules are in the current flow table 134 for the specified data flow (data flow from host _1 to host _2). To do. First, the flow table manager 132 has an existing flow rule (first new flow rule generated in scenario 1) in the flow table 134 for the specified data flow (data flow from host _1 to host _2). Determine if it is in. The flow table manager 132 then checks and determines if the security privilege level of the first new flow rule is higher than that of the second new flow rule. Therefore, the second new flow rule is abandoned. A failure notification is transmitted from the SDN controller 102-1 to the general application 112.

Therefore, the non-bypass security policy set by the automatic security management is not overwritten by the QoS policy set by the general application.

Scenario 3: How does SDN controller 102-1 react automatically and immediately to new security attacks? First referring to method 200 of FIG. 2, this procedure is described as follows:

1) In step 202, one or more security devices 108 detect a security incident and report it to the automatic security management module 110.

2) In step 204, the automatic security management module 110 receives and analyzes the incident report. The automatic security management module 110 then generates countermeasures and security policies based on the knowledge learned from that analysis. These security policies are transmitted to the SDN controller 102-1.

3) In step 204, the SDN controller 102-1 receives these security policies and translates them into new flow rules. These flow rules are delivered to the SDN switches 206-1, 206-2, ..., 206-n.

4) SDN switches 206-1, 206-2, ..., 206-n process (forward, discard, or discard) flows according to new flow rules so that they can mitigate or thwart the security incidents or threats mentioned in step 1. Report to SDN controller).

Scenario 4: Packet scan detection. The administrator management module 116 copies the first consecutive m packets from each of the n consecutive packets of the flow from host _1 to host _2, and the security device 108 (for example, FW) is used for data detection. , DPI, IPS, IDS), suppose you create a policy to be forwarded to one or more. The procedure for this policy, implemented in SDN Network 100, is as follows:

4.1) Same as step 1.1) of scenario 1.

4.2) Same as step 1.2) of scenario 1.

4.3) Same as step 1.3) of scenario 1.

4.4) SDN controller 102-1 translates this policy into a new flow rule (called a second new flow rule) with the following additional attributes:
− Policy characteristics: Regular,
-Policy creator role: General administrator-Role security privilege level: L4,
-Condition: Data flow from host _1 to host _2-Pattern: Select m consecutive packets from each of n consecutive packets in the flow.

Therefore, in this scenario 4, the current flow table format in the SDN controller 102-1 is extended to reflect at least the above five attributes. The last attribute, the pattern, may be reflected in the format of the flow table in the SDN switch.

Further, a new action (OFBAT_DECTION) is assigned to the flow satisfying the above conditions.

4.5) Same as step 1.5) of scenario 1.

4.6) Same as step 1.6) in Scenario 1, except that the characteristics of this policy are periodic rather than real-time.

4.7) Same as step 1.7) of scenario 1.

In one exemplary embodiment, some modifications may be implemented in the SDN switch. For example, a counter is used to count the number of packets and a pattern attribute is added to the flow table format.

In one exemplary embodiment, in order to implement one or more embodiments, some in the ONF specification "OpenFlowSwitch Specification version 1.4", the disclosure of which is incorporated herein by reference in its entirety. Changes may be made. More specifically, paragraphs 5.12 and 7.2.4 of the ONF specification may be modified as described below.

Optional actions may be added to the section "5.12 Actions" as follows:
Optional Action: The detection action forwards the packet to the designated OpenFlow port and then to a security device (eg, FW, IDP, DPI, etc.).

In the section "7.2.4 Action Structures", the action structure may be modified as follows:

The new action, the detect action, uses the following structures and fields:

With reference to FIG. 3, a processing platform in which the SDN network and security architecture (eg, 100 in FIG. 1) is implemented according to one or more embodiments is shown. The processing platform 300 of this embodiment includes a plurality of processing devices marked 302-1, 302-2, 302-3, ..., 302-P, which communicate with each other via the network 304. Thus, one or more of the components and / or modules of the SDN network 100 (eg, SDN controllers, SDN switches, host computing devices, security equipment, and various modules) may be one or more computers, respectively. It may run on or on other processing platform elements, each of which may be considered as an example of what is more commonly referred to herein as a "processing device." As shown in FIG. 3, such devices generally include at least one processor and associated memory, one for instantiating and / or controlling the features of the systems and methodologies described herein. Or implement multiple functional modules. Multiple elements or modules may be implemented in a given embodiment by a single processing device.

The processing device 302-1 in the processing platform 300 includes a processor 301 coupled to memory 312. Processor 310 may include microprocessors, microcontrollers, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs) or other types of processing circuits, and some or combinations of such circuit elements. .. The system components disclosed herein are, at least in part, stored in memory and implemented in the form of one or more software programs executed by the processor of a processing device such as processor 310. be able to. A memory 312 (or other storage device) that embodies such program code within itself is an example of what is more commonly referred to herein as a processor-readable storage medium. A product containing such a processor-readable storage medium is considered an embodiment. A given such product may include, for example, a storage device in an integrated circuit, including a storage disk, storage array, or memory. As used herein, the term "manufactured product" shall be understood to exclude transient propagation signals.

Further, the memory 312 may include any combination of electronic memories such as random access memory (RAM), read-only memory (ROM), or other types of memory. When one or more software programs are executed by a processing device, such as processing device 302-1, the device causes the device to perform a function related to one or more of the components / steps of system / method 300. .. Those skilled in the art will be able to easily implement such software given the teachings provided herein. Other examples of embodiments that embody processor-readable storage media may include, for example, optical discs or magnetic disks.

The processing device 302-1 also includes a network interface circuit 314, which is used to interface the processing device with the network 304 or other system components. Such circuits may include conventional transceivers of the type well known in the art.

It is assumed that the other processing devices 302 of the processing platform 300 are configured in the same manner as for the processing devices 302-1 shown in the figure.

The processing platform 300 shown in FIG. 3 may include known additional components such as batch processing systems, parallel processing systems, physical machines, virtual machines, virtual switches, storage volumes, logical units, and the like. Again, the particular processing platform shown in FIG. 3 is shown merely as an example, and the SDN network 100 in FIG. 1 may include additional or alternative processing platforms, as well as a number of independent processing platforms in any combination. Good.

Also, many other configurations of servers, computers, storage devices or other components are possible. Such components are wide area networks (WAN), local area networks (LANs), satellite networks, telephone or cable networks, storage networks, centralized networks, or various parts or combinations of them and other types of networks. It is possible to communicate with other elements of the system via any type of network, such as.

Further, it is understood that the processing platform 300 of FIG. 3 can include a virtual machine (VM) implemented using a hypervisor. The hypervisor is an example of what is more commonly referred to herein as the "virtualized infrastructure." The hypervisor runs on the physical infrastructure. The processing platform 300 may also include multiple hypervisors, each running on its own physical infrastructure. As is known, a VM is a logical processing element that may be instantiated on one or more physical processing elements (eg, servers, computers, processing devices). That is, a VM generally refers to a software implementation (ie, a computer) of a machine that executes a program like a physical machine. Thus, different VMs can run multiple different operating systems and multiple applications on the same physical computer. Virtualization is implemented by the hypervisor, which is inserted directly over the computer hardware to dynamically and transparently allocate the hardware resources of the physical computer. The hypervisor allows multiple operating systems to run simultaneously on a single physical computer and share hardware resources with each other.

Although certain exemplary embodiments are described herein in the context of communication networks that utilize a particular communication protocol, other types of networks may also be used in other embodiments. Therefore, as mentioned above, the term "network" is intended to be broadly construed as used herein. Furthermore, it should be emphasized that the aforementioned embodiments are for illustrative purposes only and should never be construed as limiting. Other embodiments may use different types of configurations of networks, devices and modules, as well as alternative communication protocols, process steps and operations to implement load balancing functionality. The particular mode in which the network nodes communicate can be modified in other embodiments. It should also be understood that the particular assumptions made in explaining the exemplary embodiments should not be construed as a requirement of the present invention. The present invention can be implemented in other embodiments to which these particular assumptions do not apply. These and many other alternative embodiments, which are within the appended claims, will be readily apparent to those skilled in the art.

Claims (10)

The way
On a controller in a software-defined network, the steps to get at least one security policy from the policy author,
Put a security policy into a software-defined network through a controller based on one or more attributes that specify the characteristics of the security policy, the role of the security policy author, and the security privilege level of the role of the security policy author. A method in which the attributes of a security policy characteristic, including the steps to implement, indicate whether the security policy is a real-time policy. The method of claim 1, wherein the role of the security policy creator specifies a role on the network that is assigned to the security policy creator. The method of claim 1, wherein the security privilege level of the security policy author role specifies a different hierarchical security privilege level for each of the different roles that can be assigned to the policy author. The step to get at least one security policy from the policy creator is
A step in which the controller performs at least one of authentication, authorization, integrity verification, and confidentiality verification operations to the policy creator.
The method of claim 1, further comprising a step in which the controller revokes the security policy in a situation where at least one of an authentication operation, an authorization operation, an integrity verification operation, and a confidentiality verification operation fails. The step of implementing a security policy is based on one or more attributes that the controller specifies the security policy based on the characteristics of the security policy, the security policy author role, and the security privilege level of the security policy author role. The method of claim 1, further comprising the step of converting into at least one flow rule. The step of implementing the security policy is that the controller
Determine if there is a conflict between the flow rule converted from the security policy and the existing flow rule in the flow table, and then determine the conflict between the flow rule converted from the security policy and the existing flow rule in the flow table. Resolve based on the security privilege level of the security policy author role,
Updating the flow table with the flow rules converted from the security policy,
Distributing flow rules translated from a security policy to one or more switches in a software-defined network so that one or more switches can carry out data flows within the software-defined network according to the flow rules.
One of performing at least one of an authentication operation, an integrity verification operation, and a confidentiality verification operation on one or more switches before delivering the flow rule to one or more switches. Or the method of claim 5, comprising performing more than one. The method according to claim 1, wherein the acquired security policy is a security policy developed in response to a new security threat detected by a security device of a software-defined network. The acquired security policy contains a packet scan detection instruction, and the step of implementing the security policy is one or more switches in the software-defined network through which the translated flow rules are delivered. The controller puts a security policy, including packet scan detection instructions, into a flow rule based on data flow conditions and packet scan patterns so that multiple specified packets are instructed to be forwarded to security devices in the software-defined network. The method of claim 1, further comprising a step of conversion. A product that includes a processor-readable storage medium that embodies the executable program code, which, when executed by the processing device, is transmitted to the processing device.
In the controller of the software defined networking, the steps to get at least one security policy from the policy creator,
Through the controller, a security policy is placed in a software-defined network based on one or more attributes that specify the characteristics of the security policy, the security policy author role, and the security privilege level of the security policy author role. And let them do the steps to implement
A product whose characteristic attribute of a security policy indicates whether the security policy is a real-time policy. It ’s a device,
With memory
The controller is equipped with a processor that is operably coupled to memory to form a controller for a software-defined network.
Get at least one security policy from the policy creator
Configure security policies to be implemented within a software-defined network based on one or more attributes that specify the characteristics of the security policy, the role of the security policy author, and the security privilege level of the role of the security policy author. Being done
A device whose attribute of a security policy characteristic indicates whether the security policy is a real-time policy.

Images