Bridging the Gap Between Security Tools and SDNControllersH
Li Wang and Dinghao Wu∗
College of Information Sciences and Technology, The Pennsylvania State University, University Park, PA, USA
Abstract
Software-Defined Networking (SDN) is a promising paradigm to improve network security protections.However, current SDN-based security solutions can hardly provide sufficient protections in a real SDNnetwork, due to several reasons: 1) they are implemented at either the centralized SDN controllers or thedecentralized network devices, which are subject to a performance limitation; 2) their designs are confinedby the SDN network characteristics and can only provide limited security functions; and 3) many solutionshave deployment challenges and compatibility issues. In this paper, we propose SecControl, a practicalnetwork protection framework combining the existing security tools and SDN technologies, to produce acomprehensive network security solution in an SDN environment. We implement a SecControl prototypewith OpenFlow and evaluate its effectiveness and performance. Our experiment shows that SecControl cancooperate with many mainstream security tools and provide effective defense responses over SDN-supportednetworks.
Software-Defined Networking (SDN) has gained muchattention in both academia and industry [24]. By decou-pling the control logic from the closed and predesig-ned network devices, SDN enables the reprogrammingcapability of network devices. Previously, traditionalnetwork devices can only work as they are manufactu-red, and all their traffic control and forwarding functi-ons are not changeable once produced. With SDN, thetraffic control functions and traffic forwarding functi-ons are divided as control plane and data plane. Theseparation of control plane and data plane provides apowerful and flexible network structure for variousnetwork applications.
HA preliminary version [39] of this article appeared in Proceedings ofthe Workshop on Applications and Techniques in Cyber Security (ATCS),co-located with the 13th EAI International Conference on Security andPrivacy in Communication Networks (SecureComm ’17), Niagara Falls,Canada, October 22–25, 2017.∗Corresponding author. Email: [email protected]
A lot of network-related research has been conductedwith SDN, such as network management [9, 10, 21],network QoS [15], network load balancing [18, 40],and content delivery system [41]. Similarly, researcherstried to take advantage of SDN technologies todevise new network security solutions as well. Manyinnovations [34–37] tried to provide better securityservices over software-defined networks, and they areprovided either at the centralized controllers or thedistributed inline network devices.
However, the existing SDN-based security solutionscan hardly compete with traditional security solutionsdue to various reasons. First, they are designedwith limitations inherently. When security functionsare implemented at centralized controllers [35], theprocessing capabilities of controllers will becomea potential bottleneck; when security functions aredeployed at network devices[37], it can hardly providea comprehensive protection over the network. Second,most of them are focusing on maximizing thecontrol flexibility of SDN. Maximizing network controlflexibility does not necessarily lead to strengthened
1
Research ArticleEAI Endorsed Transactions on Security and Safety
network protection ability. Third, the existing SDN-based security solutions are mainly on a certain aspectof network protection [20], which can hardly satisfy thegeneral network protection requirements. Last, manyof them have deployment challenges and compatibilityissues.
As a result, the current SDN-based security solutionscannot provide the same protection capabilities astraditional security tools can provide over SDNnetworks. Actually, the key innovations brought bySDN are over network control instead of securityprocessing capability. Network protection demandsmore powerful security processing capabilities, such aspacket payload inspection, traffic pattern analysis, andso on. Therefore, we need a practical network securitysolution which can provide competitive securityprotection and, at the same time, can take advantage ofthe flexible control over SDN networks.
Traditional security tools, like firewalls and intru-sion detection systems, have strong security proces-sing capabilities in protecting traditional network infra-structures, and each type of security tool is specializedto deal with a certain type of security threat. They arecomposed together to form a comprehensive networksecurity solution. However, traditional security toolscan hardly be used directly in software-defined net-works because of the following reasons: 1) existing secu-rity tools are designed under the traditional networkinfrastructure, which does not fit into SDN networkstructure; 2) most security tools are devised to deal witha certain type of security threat. Their exclusive designsdecide they can only be used individually and cannotcooperate with each other; and 3) there is no interfaceon existing security tools to let them take advantage ofSDN benefits.
In this paper, we propose SecControl, a newnetwork protection framework bridging the gapbetween security tools and SDN technologies, toprovide sufficient protection capabilities in an SDNenvironment. Our goal is to design a practical andcomprehensive network security solution over SDNnetworks by leveraging existing security tools and SDNcontrol flexibility. Unlike existing SDN-based securitysolutions, SecControl is designed on a new securitycontrol layer above SDN controllers, which releasesSDN controllers from security processing pressure.SecControl is able to perceive the real-time securitythreats, generate real-time defense reactions, and adjustcorresponding network behaviors dynamically. WithSecControl, security engineers can easily add differentsecurity tools into the protection boundary and makeuse of their detection abilities to serve the entirenetwork. Our method can be applied on mainstreamSDN platforms without difficulty.
In summary, the main contributions of SecControl areas follows.
• We propose a novel network protection frame-work for software-defined networks, which com-bines the existing security tools and SDN techno-logies. Our framework retrofits and reuses theexisting security tools in the SDN context, whichavoids re-development of many security defensefunctionalities.
• Our method equips an SDN network with strongsecurity processing capabilities in an economicway. Existing security tools can be used to protectSDN networks without difficulty.
• SecControl layer provides an additional layerabove SDN controllers, which release controllersfrom security processing pressures. SecControlhas a full security view of the protected networkdomain, which enables SecControl to offer aunified protection.
• We design a practical method to dynamicallytranslate defense responses into SDN rules toadjust network behaviors. We provide a set ofSDN primitives, namely drop, forward, reflect,isolate, and copy, and these primitives can betranslated to OpenFlow flow rules automatically.
• SecControl separates the security processing logicfrom the security enforcement components. Withour method, a SecControl domain can receiveremote protection instructions from other Sec-Control domains, which enables a unified Sec-Control protection over different SDN networks.
The remainder of the paper is organized as follows.We introduce the challenges of SecControl in Section2. In Section 3, we discuss SecControl’s architectureand how it is designed. Section 5 describes aSecControl prototype implementing with OpenFlow.The evaluation is presented in Section 6. In Section 7,we talk about a few insights obtained from this work.We briefly summarize the related work in Section 8.Finally, a conclusion is given in Section 9.
2. ChallengesOur goal is to design a practical network securitysolution in SDN networks by employing the securityprocessing capabilities of traditional security tools andSDN technologies. To achieve it, we need to answerseveral research questions.
RQ1. How Does SDN Improve Network SecurityProtection?
Network security was once regarded as a subsetof network management problem [10]. The keyinnovation of SDN is separating control plane and dataplane which maximizes the network control flexibility.
2 EAI Endorsed Transactions on Security and Safety
12 2018 - 12 2018 | Volume 5 | Issue 17 | e1
Bridging the Gap Between Security Tools and SDN Controllers
However, Maximizing network control flexibility doesnot necessarily lead to the strengthened networkprotection ability. We may need to think how can we useSDN to improve security. For example, how to assignsecurity responsibilities to control plane and data plane?How to dynamically adjust network behaviors againstsecurity threats?
RQ2. How to Fit Traditional Security Tools into SDNNetworks?
Although traditional security tools have powerfulsecurity processing capabilities, they cannot be usedin an SDN environment directly. The reasons aresummarized as follows: 1) traditional security tools areinvented for traditional network infrastructure, whichcan hardly fit into the SDN structure; 2) these tools donot have interaction interfaces for using SDN featuresto improve security; and 3) seldom can existing securitytools share threat information with each other sincethey are designed individually, and that is a weakpoint in defending SDN networks. Based on the abovereasons, we need to answer how to fit existing securitytools into SDN networks? For example, How do weplace security tools in an SDN network? How canwe collect threat information from traditional securitytools?
RQ3. How Can We Combine Them Together?To make use of the protection capabilities of
traditional security tools and maximize the SDNbenefits in securing networks, we need to makethem work together. Consider most security toolsare designed for traditional networks instead of SDNnetworks, there are several practical issues whencombining them together. The first issue is the currentsecurity tools are heterogeneous, and their detectionresults are not compatible. For instance, a host-basedintrusion detection system will be mainly monitoringsystem behaviors, while a firewall will be interested insuspicious network activities. The log generated by thetwo tools can hardly join together for further securityanalysis. The second issue is we lack an interactionmechanism for security tools to communicate withSDN networks. We want to employ real-time threatsinformation to adjust network behaviors dynamically.The last issue is we need a unified method totranslate the semantics of threat information intoSDN rules. For example, how do we extract effectivethreats information from heterogeneous security eventinformation? Given a certain security threat, how do weadjust network behaviors for an effective defense? Howdo we distribute defense decisions in an SDN network?
3. System ArchitectureIn this section, we introduce the SecControl architec-ture. We first give an overview of SecControl. Then, we
illustrate the three-layer structure of SecControl as wellas the main functions. Last, we explain how SecControlworks.
3.1. Overall ArchitectureSecControl seeks to make use of existing security toolsto build up a practical protection framework to maxi-mize SDN benefits in protecting production networks.Through collecting various threats information fromvarious security tools, SecControl converges heteroge-neous security alerts to one point. By using specificsecurity analysis and detection algorithms, SecControlidentifies attack evidence, accesses an overall securitysituation, and generate corresponding defense respon-ses. Figure 1 shows the SecControl architecture. Ascan be seen from the figure, SecControl architectureis divided into three layers, Threat Collecting Layer,SecControl Layer, and SDN Controller Layer. Each layerplays a different role in the SecControl protection fra-mework. The Threat Collecting Layer is in the upperpart, which is composed of various security tools andThreat Collecting Agents. Consider SecControl aimsto provide an overall protection framework, it needsto provide enough compatibility supports to varioussecurity tools. Each security tool will be attached acustomized Threat Collecting Agent which is devised tocooperate with this tool. As Figure 1 shows, a securitytool is represented by a blue rectangle, and the small tri-angle stands for the attached Threat Collecting Agent.The Threat Collecting Layer collects security events andsend them to the SecControl Layer, and the SecControlLayer will transform the threat information into defenseresponses. After the defense responses are translatedinto specific SDN rules, they will be passed down to theSDN Controller Layer. The SDN Controller Layer willdistribute the SDN rules to corresponding SDN devicesfor enforcement. The work flow will be given in nextsubsection.
The Threat Collecting Layer includes two parts, tra-ditional security tools and Threat Collecting Agents,whose responsibility is gathering effective securityevent information from various security tools. Due tothat existing SDN solutions are weak in enhancing secu-rity processing abilities of SDN networks essentially, wetry to borrow the existing powerful security tools toprovide SecControl stronger security processing abili-ties. The security tools are deployed for detecting secu-rity threats, while the Threat Collecting Agents are forcollecting the latest security event information detectedby these tools. The function of Threat Collecting Agentsis to provide a uniform interface to fit the traditionalsecurity tools into the SecControl Layer. As Figure 1shows, each security tool will be assigned a ThreatCollecting Agent, which is equipped with customizedinterfaces for recording detection information on that
3 EAI Endorsed Transactions on Security and Safety
12 2018 - 12 2018 | Volume 5 | Issue 17 | e1
Li Wang and Dinghao Wu
...Security Threats
Step 1
Step 3
... ...
... ... ...
Threat Collecting Layer
SecControl Layer
SDN Controller Layer
Firewall NIDS HIDS
SecControl Node
AntiVirus System LogRemote
SecControl Node
SDN Controller
SDN Device
SDN Controller SDN Controller
SDN Device SDN Device SDN Device SDN Device SDN Device
Figure 1. The SecControl Architecture
tool. The collected information will go through a pre-processing procedure which transforms heterogenousand unorganized information into a uniform format.After the threat information is preprocessed and orga-nized, then it will be sent to the SecControl Layer forfurther processing.
The SecControl Layer is located in the middle of theother two layers, which contains only one component,the SecControl Node. The SecControl Node is the keycomponent in our framework, which is designed tobridge the connection between the security tools andSDN controllers. When receiving security event recordsfrom the Threat Collecting Layer, the SecControl Nodewill keep running a series of standard steps. Thestandard steps include converging all the collectedsecurity events, correlating related alerts, analyzingalert information, and abstracting attacking evidence.After that, the SecControl Node will decide how tomake a defense response to the detected security threatsover SDN networks. The responses will be given in SDNrules, and these SDN rules will be distributed to therelated SDN controllers for enforcement. As a result,SecControl adjusts the network behaviors based on thesecurity threats. Our work is mainly on this layer, andthere are a lot of research questions to be solved. Moredetails about how we design the inside process of theSecControl Node is presented in the next section.
The SDN Controller Layer is responsible for enfor-cing the SDN rules for our protection framework, whichis formed by many SDN controllers. The SDN control-lers we use here are just standard SDN controllers.When receiving SDN rules from the SecControl Node,a controller will check its local device list to locate therelated network devices. Then, the controller will notifythe corresponding network devices and send out thelatest SDN rules. The new SDN rules will be installedand enforced at SDN network devices. The revolutio-nary design of SDN is decoupling the functions of cur-rent network devices into control plane and data plane.The control plane is implemented as an SDN controller,while the data plane is deployed as new SDN networkdevices. In SDN networks, every SDN controller willbe connecting at least one or more network devices,and these devices will be maintained and managedby this SDN controller. Network devices will sharestate information with their controllers, and controllerswill collect statistic information from network devices.When there is an update request, the SDN controllerwill send out SDN rules to the related network devicesto update data plane rules.
4 EAI Endorsed Transactions on Security and Safety
12 2018 - 12 2018 | Volume 5 | Issue 17 | e1
Bridging the Gap Between Security Tools and SDN Controllers
3.2. How SecControl Works
The working process of SecControl is shown in Figure1. There are four steps: (1) The security threats aredetected by security tools and the detection results arerecorded and processed by Threat Collecting Agents(ThreatCA). (2) The preprocessed threat information issent from ThreatCA to the SecControl Node. (3) TheSecControl Node converges and analyzes the threatinformation to decide how to make a defense responseover SDN networks. Based on the defense response,new SDN rules are generated. (4) The SecControlNode distributes the generated SDN rules to thecorresponding SDN controllers for enforcement. Afterthe four steps, the network devices behaviors in theSDN networks are modified based on the detectedsecurity threats.
In step one, security threat information is generatedby various security tools. Consider existing securitytools are divided into several types and each type ofsecurity tools is designed for a certain special securitypurpose, different security tools will be targetingdifferent security threats. For example, firewalls focuseson filtering unwanted network traffic, while intrusiondetection systems concentrate on detection systemanomalies. It is very common to have different securityevent formats in different security tools. As a result,we need to customize ThreatCA for different securitytools. And the security event information recorded byThreatCA will be featured with various formats. Tosimplify SecControl Layer’s work, ThreatCA is alsoresponsible for preprocessing the recorded informationand transform it into a uniform format in step one. Itwill be much easier for SecControl Layer to analyze thecollected information with a unified format.
The collected threat information will be sentto SecControl Layer in step two. However, beforesending threat information to the SecControl Node,ThreatCA has to extract effective information fromthe heterogeneous detection results, which can greatlysimplify the work of the SecControl Node. To helpreduce the workload of the SecControl Node, ThreatCAneeds to be capable of recognizing alert informationfrom various security tools. And it should be able todismiss the format difference in detection results andextract effective threat characters based on the mainfunctions of security tools. For example, a processedfirewall alert could be (firewall, network position, alertlevel, threat source, detection time, ...). Actually, thepreprocessing of threat information can be quitecomplicated. More details will be given in the designsection.
Step three happens inside of the SecControl Node,where defense choices are made and SDN rules are pro-duced. After receiving threat information from Threa-tCA, SecControl Node will be analyzing security threats
information under given detection algorithms. Sincedifferent protection environments may have differentsensitivities on security attacks, security engineers canequip SecControl Node with different security analy-sis and detection algorithms to decide whether theprotected environment is facing attack threats or not.The security analysis and detection algorithms can bemodified and replaced in different defense situations,which ensure the SecControl framework is able toprovide a comprehensive and flexible protection onthe target network environment. Based on the analysisresult, SecControl can tell what defense responses canbe made and how to generate the corresponding SDNrules to adjust the network behaviors. We summarizethe defense reactions into several types. For each typeof reaction, we transform the reaction into a set of SDNrules, which decide how we adjust network behaviorsbased on the threat information. The generated SDNrules will be distributed to corresponding SDN control-lers in step four.
The last step is to distribute the generated SDN rulesto the SDN Controller Layer. SecControl Layer willmaintain a list which records the location informationof all the controllers in the protected SDN networks.The SecControl Node will be aware of the controllerlayout in the protected SDN networks, which ensuresthe SDN rules can be sent to the related controllers.When the SDN rules are transmitted, the transmissionprocess will be protected and secured. There will bea secure protocol between the SecControl Node andcontrollers to protect their communications.
4. SecControl DesignSecControl takes advantage of threat detection abilitiesof security tools to change network behaviors. Ourdesign work focuses on bridging the gap betweensecurity tools and SDN controllers. Most questionsraised in motivation part will be answered in thissection.
4.1. SecControl ComponentsThe SecControl framework is composed of fourcomponents, as shown in Figure 2. The first componentis Threat Collecting Agent, which is running outsideof the SecControl Node and responsible for collectingvarious security event information from security tools.The second one is Threat Analyser, which is incharge of converging and analyzing the collectedthreat information and decides corresponding defenseresponses. The third component is SDN Rule Engine,whose responsibility is transforming the generateddefense responses to specific SDN rules. The lastcomponent, SDN Rule Distributer, is designed fordistributing the SDN rules to SDN controllers (SDN
5 EAI Endorsed Transactions on Security and Safety
12 2018 - 12 2018 | Volume 5 | Issue 17 | e1
Li Wang and Dinghao Wu
SecControl Node
Defense Responses
SDN Rule Uniform Format Interface
Threat Analyzer SDN Rule Engine
General SDN Rules
SDN Rule Distributer
Threat Collecting Agent
Threat Information
SDN Rulesto
Controller
Platform-Specific SDN Rules
Figure 2. The SecControl Components
Rule Distributer should have a full picture of the SDNcontrollers).
Threat Collecting Agent. This is running outside of theSecControl Node. ThreatCA functions like a speciallydesigned agent dealing with security tools. Its positionshould be close enough to the security tool it targets, inorder to reduce the threat collection latency. The inputsof the ThreatCA are various detection results collectedfrom different security tools, while the outputs ofthe ThreatCA are well-structured threat information,which can be directly used for other components. Tocomplete the security threats SecControl can react,we need to collect as much security threats as wecan through ThreatCAs. Consider existing securitytools are separately targeting different threats, theirdetection results could be quite different. To handledifferent detection results, we need to provide eachtype of security tools at least one specialized ThreatCA,ensuring all the detection results can be handled.
The purpose of ThreatCA is to provide effective thre-ats information to Threat Analyzer. As we mentionedin Section 3, traditional security tools are individuallydesigned for different protection purposes, and theirdetection results could be very different. If Threa-tCA sends raw detection results to Threat Analyzerdirectly, it is hard for Threat Analyzer to conduct secu-rity analysis efficiently. Threat Analyzer has to extracteffective information from raw data first, then analyzethe results, which will greatly reduce the performanceof SecControl Node.
We design a preprocess function on ThreatCA. Thepreprocess function is responsible for transformingthe raw detection results to a uniform format whichcan be used by Threat Analyzer for security analysispurpose. For each TreatCA, it is designed specially tounderstand the raw detection results of the securitytool it is attached. To release the Threat Analyzer from
tedious format details, we present the detection resultsin a uniform format (the format is IDEMF [2]) so thatThreat Analyzer can use the unified interface to dealwith all detection results from different sources. Allthe ThreatCAs take different raw detection results andgenerate the processed detection results in the sameformat. Through this way, we can greatly reduce theworkload for Threat Analyzer. There are several optionsfor our choices. More details about the uniform formatcontent will be given in Section 5.
Threat Analyser. The preprocessed threat informationwill be sent to the Threat Analyser. The ThreatAnalyzer will be analyzing threats, assessing securitysituations, and deciding defense responses. As a keycomponent of SecControl, Threat Analyzer providesstrong supports for entire framework to deal withvarious security threats. To deal with various securitythreats, we are trying to design Threat Analyser aconfigurable, adaptable, and extendable module fordifferent protection purposes. Security engineers areable to adjust defense strategies in Threat Analyzerto practice different security analysis and detectionalgorithms.
In fact, analyzing threat information in a largenumber of detection records is quite complicated, anda lot of algorithms have been proposed [25, 30]. Theanalyzing results can be affected by many factors.For example, the same set of network traffic maylead to different alert information for using differentdefense strategies. In productive networks, peopleuse different criterions to decide whether there isa security threat. Security engineers usually designcustomized security analysis algorithms for their ThreatAnalyzers. Consider the threat analysis algorithmsdepend on actual security policies, we will not provideconcrete algorithms. Here, we introduce three commonsecurity analysis principles based on our experiences.
6 EAI Endorsed Transactions on Security and Safety
12 2018 - 12 2018 | Volume 5 | Issue 17 | e1
Bridging the Gap Between Security Tools and SDN Controllers
Many practical security analysis algorithms could begenerated following these three principles.
Time-based Threat Correlation: As its name implies,time-based threat correlation analyzes detected threatsaccording to their detection time-stamps. Time-stampis an important attribute of a detected security event,which has an immediate relation to the happeningtime of the security event. Most time-driven attacks,like DDoS and network scan attacks, are identified bytime intervals. Time-based threat correlation can helpus detect time-related attacks happening on differenttargets. For example, computer worms may broadcasttheir propagation traffic in a very short time to reachas many nodes as they can. When a computer wormis attacking, we may experience a time period whilenetwork traffic is featured with multi-nodes to multi-nodes. We can detect these malicious activities withtime-based threat correlation.
Target-based Threat Correlation: Target-basedthreat correlation studies threat records by a certaintarget. Here, a target could be a physical machine, avirtual machine, or even an operating system. To avoidbeing detected by security tools, some experiencedattackers may cooperate to star an attack to a targetsimultaneously. For example, distributed network scanscan hardly be detected by a firewall or an IDS due tothe network scan is not finished by a single attacker.Target-based threat correlation can help us to dig allthe detection results together to figure out potentialattacks on one target.
Experience-based Threat Correlation: Experience-based Threat Correlation identifies security threatsbased on work experience of security engineers. Ina real protection environment, a smart attacker mayuse complex strategies to compromise a target node,which can bypass the detection of most security tools.When the compromise is detected, security engineerswill go to the audit information, correlate relatedinformation, and restore the attacking process reversely.The restoring process is based on the security engineers’experience. After time to time, security engineers areable to locate the suspicious events based on theirexperience. The experience of security engineers couldbe concluded as practical threat detection algorithms,which can provide more choices in real networkprotections.
When dealing with a real defense environment, theseprinciples can be used together for detecting moreadvanced attacks. Except for the above principles,security engineers can design their own detectionalgorithms to detect a certain security threat. Manyresearch has been done on correlation-based securityanalysis algorithms [11, 13, 38]. Security engineerscan easily customize these algorithms and deploythem in SecControl Node for specified securitythreats. Once a security threat is identified, the
Threat Analyzer will choose a predefined defenseresponse as a reaction against the security threat.In different protection scenarios, defense responsesmean different actions. For example, on a firewall,a defense response could be blocking the threatentraffic; while on a host system, a defense responsecould be isolating a suspicious executable file. InSecControl, we focus on network level response, whichmeans we adjust network behaviors through SDNtechnologies as defense response on potential attacks.Similarly, Threat Analyzer allows the defense responsesbe defined in a flexible way. Just like security analysisand detection algorithms, the defense responses shouldbe configurable to fit different defense scenarios as well,and security engineers can dynamically map securitythreats to different defense responses.
In this paper, all the defense responses will beadjusting current behaviors of SDN networks in orderto minimize the property loss and maximize thesecurity benefits. How to choose a proper defenseresponse, just like how to customize a Threat Analyzer,is also depending on security policies. We will giveseveral examples in Section 6. Once a defense responseis fixed, it will be sent to the SDN Rule Engine and thentranslated into basic SDN primitives.
SDN Rule Engine. SDN Rule Engine, as the namesuggests, generates the corresponding SDN rules forthe SecControl framework. Just as we mentionedpreviously, the defense response generated by ThreatCAwill be focusing on adjusting network behaviors.Network behaviors will be adjusted through controllersover SDN network. Controllers send out SDN rules toindividual network devices, where the SDN rules areenforced and the network behaviors are adjusted. InSecControl, SDN Rule Engine translates the defenseresponses into SDN rules. We design a systematicmethod to achieve the translation process through usingSDN primitives, which stands for the basic networkoperations when dealing with security threats. Wedefine five SDN primitives based on the network flowfeatures. They are Drop, Forward, Reflect, Isolate, andCopy. The five SDN primitives can be used individuallyor in combination to deal with various security threats.
The five SDN primitives are as follows:
1. Drop, which means discarding the identifiednetwork traffic. This primitive is usually used toblock unwanted network traffic.
2. Forward, which just tells the network devices topass the identified traffic to its destination basedon the existing SDN rules. When we do not wantto do any operation on the identified networktraffic for passing certain network device, we useforward.
7 EAI Endorsed Transactions on Security and Safety
12 2018 - 12 2018 | Volume 5 | Issue 17 | e1
Li Wang and Dinghao Wu
3. Reflect, changes the destination of the identifiednetwork traffic both for inbound and outbounddirections. For example, A wants to build up aconnection with B. When A’s connection traffic isreflected to C, A will be connected with C insteadof B. After this, C will use B’s network address andcommunicate with A, and A knows nothing aboutthis. Reflect primitive can be used in deploying ashadow server or a honeypot.
4. Isolate, limits the identified traffic to a certainhost or network area. When a node (or a nodegroup) is identified as a source of an attack, weuse this primitive to confine its network activities.
5. Copy, duplicates the identified packets, which isusually used for monitoring or logging use. Mostcurrent network devices have been equipped withthis primitive. It could be used for real-time trafficanalysis and other purposes.
The five SDN primitives can be used in combination,repeatedly, and in any sequence to form a wanteddefense response. Each defense response will betranslated into one or several SDN primitives. Forexample, a defense response may require directing thesuspicious source to a honeynet, where the suspicioustraffic will be recorded and analyzed. In this situation,the defense response will be translated into two SDNprimitives, reflect and isolate. The suspicious traffic willbe first reflected to a honeynet and then isolated in thehoneynet area.
Usually, each SDN rule contains one SND primitive,which represents the specific action of this rule. SomeSDN primitives, like drop and forward, have beensupported on most SDN platforms. For those SDNprimitives that cannot be well supported, we may needadditional translation processes to turn these primitivesinto corresponding SDN rules which can be executedon specific SDN platforms. For each SDN platform, wecan design a set of interfaces for transforming SDNprimitives to SDN rules. The generated SDN rules willbe handled to the SDN Rule Distributer.
SDN Rule Distributer. The generated SDN rules willbe sent to SDN controllers through the SDN RuleDistributer. SDN network employs a distributedstructure which is formed with SDN controllers andnetwork devices. In an SDN network, network devicesare divided into groups and each group is connectedand managed by a controller, and a controller cannotdirectly operate on a network device that is notconnected to it. Since SecControl has no privileges tooperate network devices directly, we need to distributeSDN rules to SDN controllers first, then have SDNcontrollers send SDN rules to correct network devicesfor execution.
Device
List 1
For
Controller
1
SDN Rule
Distributer
...
Controller 1
Device
List 1
Device
List 2
For
Controller
2
...Device
List n
For
Controller
n
... ...Controller 2
Device
List 2
Controller n
Device
List n
Figure 3. The SDN Rule Distributer
To ensure the SDN rules can be delivered to theirdestination correctly, the SDN Rule Distributer shouldhave a full picture of the SDN networks. As can be seenin Figure 3, the SDN Rule Distributer stores a localcopy of network device lists for all SDN controllers.Through the local copy of network device lists, the SDNRule Distributer knows how to distribute SDN rules tocorrect SDN controllers.
Consider different network vendors may use differentSDN rule formats on their SDN platforms, beforesending out SDN rules, the SDN Rule Distributermay need an additional interface to transform SDNrules for a given SDN platform. In our prototypeimplementation, we use OpenFlow to build up SDNnetworks, and the defense responses are translated intoOpenFlow flow rules. More details can be referred inSection 5.
We may need to consider another practical problemon SDN controller. Consider these SDN rules aregenerated with different criterions, there could beinconsistencies among these SDN rules. A lot ofresearch has been done on how to update SDN ruleson SDN controllers with consistencies [3, 20, 26]. Sincehow to consistently update SDN rules on controllersis another research problem and is not one of ourcontributions, we assume the inconsistency problem onSDN rules is well solved in our design.
4.2. CommunicationTo work as an integrated protection framework,the SecControl components need to cooperate andcommunicate with each other. We need to design insidecommunication mechanisms for SecControl as well.
Based on the workflow of SecControl, we needtwo communication mechanisms which reside instep two and step four separately. In step two,the Threat Collecting Agents need to communicate
8 EAI Endorsed Transactions on Security and Safety
12 2018 - 12 2018 | Volume 5 | Issue 17 | e1
Bridging the Gap Between Security Tools and SDN Controllers
Open vSwitch
Snort IDS
Host C
Linux
Firewall
iptable
NOX Controller
Host A
Host B
SecControl Node
Threats Collecting Agents
192.168.1.153
192.168.1.154
192.168.1.152
Figure 4. A SecControl Prototype
with the SecControl Node to send collected securityevent information, and that communication can behappening all the time. The other communicationhappens between the SecControl Node and SDNcontrollers, which serves to distribute SDN rules andmaintain network devices information. Besides, we alsoneed another communication mechanism among theSecControl Nodes, which enables the exchange of SDNrules between different SecControl Nodes.
We can achieve the step two communication like anytypical network application by using TCP/IP protocols.The Threat Collecting Agents can send security eventsinformation over TCP or UDP protocol, which bothcan be used for network transportation purpose. Thecommunication between the SecControl Node andSDN controllers is a little bit different. Except fordistributing SDN rules, it is also used to synchronizenetwork device information. Because it is related todevice information update on SDN controller, it shouldbe extended with existing SDN protocols. Similarly,the communication among SecControl Nodes can beimplemented like any typical network application overTCP/IP. The implementation details will be given inSection 5.
5. A SecControl PrototypeWe develop a prototype of the SecControl framework.For a proof of concept purpose, we implement bothSecControl Node and SDN controller together. We choseto modify and extend an open source SDN controller,NOX [17], to finish all the related functions. Ourimplementation includes all the necessary functions forthe SecControl components and is able to show theeffectiveness of SecControl protections.
The SecControl Node is implemented on NOX version0.9.0 with OpenFlow v1.0. NOX is an open sourceOpenFlow controller in C++/Python, which can be usedto manage OpenFlow switches. We implemented the
<IDMEF-Message version="1.0">
<Alert ident="abc123456789">
<Analyzer analyzerid="analyzer1">
<Node category="dns">
<location>HTTP Server</location>
<name>host.domain.org</name>
</Node>
</Analyzer>
<CreateTime ntpstamp="0xbc72b2b4.0x00000000">
2020-05-19T15:31:00 -08:00
</CreateTime>
<Source ident="abc01">
<Node ident="abc01-01">
<Address ident="abc01-02" category="ipv4-addr">
<address>192.168.1.100</address>
</Address>
</Node>
</Source>
<Target ident="vic01">
<Node ident="vic01-01" category="dns">
<name>www.example.com</name>
<Address ident="vic01-02" category="ipv4-addr">
<address>192.168.1.50</address>
</Address>
</Node>
<Service ident="vic01-03">
<portlist>1-1024</portlist>
</Service>
</Target>
<Classification origin="vendor-specific">
<name>portscan</name>
<url>http://www.vendor.com/portscan</url>
</Classification>
</Alert>
</IDMEF-Message>
Figure 5. A Scan Detection in IDEMF
Threats Analyzer in Python and SDN Rule Engine inC++. The Threat Analyzer module is running as anOpenFlow application on NOX, while the SDN RuleEngine is inserted as an extension of NOX. We modifiedthe built-in functions, send_openflow_command andinstall_datapath_flow, of NOX to implement theSDN Rule Distributer.
We pick three most used security tools for ademonstration purpose. They are Snort IDS, Linuxiptables, and Linux system logs. Snort IDS is a popularopen source IDS; Linux iptables is a kernel-supportedfirewall tool on Linux system; Linux system logs arenative log system of Linux system which is often usedfor audit purposes. Each tool is attached a customizedThreatCA. Because the three tools use different alertformats, we implement three different ThreatCAs tocollect security threat information. Besides, to simplifythe protection, we categorize security events into attackevents and suspicious events. The attack events shouldbe reacted with a defense response instantly, whilesuspicious events need further analysis before decidinga defense response. When a ThreatCA meets an attackevent, it just tags the event and sent it to ThreatAnalyzer to get an instant defense response. For thesuspicious events, the ThreatCA extracts the critical
9 EAI Endorsed Transactions on Security and Safety
12 2018 - 12 2018 | Volume 5 | Issue 17 | e1
Li Wang and Dinghao Wu
FlowAction generateOFActions(defenseResponse){
FlowAction flowaction;
switch (defenseResponse) {
case drop:
addAction(flowaction,drop);
case forward:
addAction(flowaction,forward);
case reflect:
addAction(flowaction,reflect);
case isolate:
addAction(flowaction,isolate);
case copy:
addAction(flowaction,copy);
}
return flowaction;
}
Figure 6. Translate Five SDN Primitives into OpenFlow FlowActions
information of the events and put them in a unifiedformat, Intrusion Detection Exchange Message Format(IDEMF) [2]. IDEMF provides a unified format andstructure that allows the security detection results canbe transferred among different parties. A scan detectioninvolving three nodes can be demonstrated in IDEMF asshown in Figure 5.
The collected IDEMF messages are stored in alocal DB for further analysis. If a defense responseis determined, it will be translated into OpenFlowflow rules. In OpenFlow, each flow rule will have aset of attributes, such as match field, counter, timeout,actions, and so on, to match network flows. Theactions field contains an action set, which indicatesthe operations to be executed for the matchednetwork traffic. To enforce the SDN primitives atthe OpenFlow switches, we translate the five SDNprimitives into compatible OpenFlow actions. Figure6 shows generateOFactions() function translatingfive SDN primitives to the OpenFlow flow rule actions.Finally, the new flow rules are sent to switch throughfunction install_datapath_flow (self, dp_id,
attrs, idle_timeout, hard_timeout, actions,
buffer_id, priority, inport, packet).
6. Prototype EvaluationIn this section, we evaluate the SecControl prototypewith respect to effectiveness and extendibility. Theevaluation testbed is deployed as shown in Figure 4.It is running on a desktop with an Intel Core i7-3370 3.4Ghz processor and 16GB RAM. We useKVM, Open vSwitch [1, 32], NOX [17], Linux firewalliptables, Snort IDS, and Linux built-in log system toconstruct a SecControl protected virtual network. Theevaluation environment is built on a virtual network192.168.1.0/24. The physical machine is runningCentOS 6.0 with kernel 2.6.32 and qemu-kvm-0.15.1for virtualization. The three hosts are running as guestOSes with CentOS 6.0 as well. As can be seen in
Figure 4, all the nodes are in a virtual network andconnected by an Open vSwitch. We have security tools,Snort 2.9.7.5, iptables 1.4.7, and Linux Syslog systems,running at host machine. Each security tool is attachedwith a Threat Collecting Agent (each blue triangle inFigure 6 stands for a ThreatCA), and the ThreatCAs arecommunicating with the SecControl Node through thevirtual network.
6.1. EffectivenessWe demonstrate the effectiveness of the SecControlframework with several security threats, regular scanthreat, and payloads specific attacks. As Figure 4 shows,host A, and host B are attacking machines, and hostC is the victim machine (for some attacking scenarios,we may deploy more attacker nodes). We use attackingmachines to send out attack traffic to the victimmachine.
Regular Scan Threat. Regular network scan is typicallyconducted by a single attacker to locate easy targets inan open network environment, like a public network.In our network environment, we assume an attackerowns host A 192.168.1.152, and he wants to sniff thenetwork status of host C 192.168.1.153. We configureSnort with a scan detection rule: alert tcp any
any -> $HOME_NET any (msg: "TCP SYN"; flow:
stateless; flags:S; detection_filter:track
by_dst, count 100, seconds 5; sid:1000001;
rev:1). We tag the detected scan threats as attackevents and configure primitive reflect as default defenseresponse to a scan threat. All the scan traffic for host Cwill be reflected to host B 192.168.1.154. We open port22, 23, 25, 80, 111, and 443 on B, and 22, 25, and 111on C. Figure 7 shows the reflecting process, from whichwe can see the scan results are from host B instead ofhost C. That is, the scan traffic is successfully reflectedto B.
An Attack with Specific Payloads. When an attackerknows a specific vulnerability of a target machine,he can attack the target machine by sending awell-designed exploit. The attacking exploit sentthrough network packets is called malicious payloads.Malicious payloads can help the attacker take overthe victim machine and gain an absolute control overit. We install an old Windows 2000 OS on host C192.168.1.153 and open the vulnerable service SMBon port 445, which holds a dangerous vulnerabilitythrough which an attacker can easily obtain a remoteshell with admin privileges. We configure the Snortto match the signature of the attacking payloadwindows/vncinject/bind_tcp. We choose block as thedefault defense response if any malicious payload ismatched. Correspondingly, the block defense responseis translated to primitive drop on the controller. We
10 EAI Endorsed Transactions on Security and Safety
12 2018 - 12 2018 | Volume 5 | Issue 17 | e1
Bridging the Gap Between Security Tools and SDN Controllers
Reflect to B
Figure 7. A Simple Network Scan
use host A 192.168.1.152 as the attacking machine.The attacking payload is sent with metasploit, apenetrating test tool. Figure 8 shows the metasploit
console window. The result shows the exploit fails dueto a connection timeout, which proves we successfullyblock the attacking traffic to host C.
6.2. ExtendibilityWe demonstrate the extendibility of the SecControl fra-mework by using different security analysis principles.We use time-based threat correlation and target-basedthreat correlation to identify several advanced attacks,which usually may not be easily detected by existingsecurity tools. And, we show the scalability of the Sec-Control framework by deploying multiple SecControlinstances over different SDN networks, and our resultsshow different SecControl instances can cooperate tooffer protections across SDN networks.
Distributed Scan Threat. Distributed Scan is an advancedand hidden network scan, which is achieved by multiplescanning sources. Smart attackers can take multipleattacking sources to start a distributed scan, in orderto bypass existing security tools. In this attackingscenario, we use host A and host B to start a distributedport scan on host C. Our target port range is 0-500.Host C is opening port 22, 25, and 111, while hostD has port 22, 25, 80, 111, and 443 open (we addone more host D as a honeypot to communicatedwith the reflected scan traffic. Host D share the sameconfiguration with host B). We choose redirect defense
response to deal with the distributed scan, and it istranslated to reflect primitive. To detect the distributedscan threat, we extend the security analysis process ofThreat Analyzer by following the target-based threatcorrelation principle. We configure Snort to record allthe traffic. Figure 9 shows the results of distributedscan. From the scan result of A and B, we can seethe port 80 and 443 is open, which shows D is thereal scanned node and the distributed scan traffic issuccessfully reflected to D.
Step-Stone Attack. Step-stone attack is another advan-ced attack [7]. To reduce the risks of being detected,attackers choose to start an attack on step-stone nodesinstead of his own machine. Step-stone nodes are imme-diate nodes taken by attackers. Through step-stonenodes, an attacker can get more accesses or convenien-ces in taking over the target node. Following the time-based threat correlation principle, we design a two step-stones attack detection algorithm. We use redirect andblock as the defense response for the step-stone attack.In our defense, the attacker node will be blocked, andthe step-stone node will be redirected to a honeypot.We use host A as the attacker’s machine and host B asthe step-stone to attack host C. As the attacking sideon host A, we first open and login a shell remotely onhost B, then we use B as a step-stone to send maliciouspayloads to host C. We record all the outside connecti-ons of host B, including the connection between A andB. We configure Snort to record the SSH connectionsbetween A and B. The remote login attempt is recorded
11 EAI Endorsed Transactions on Security and Safety
12 2018 - 12 2018 | Volume 5 | Issue 17 | e1
Li Wang and Dinghao Wu
Figure 8. An Attack with Specific Payloads
Figure 9. A Distributed Network Scan
in the system log of host B. Targeted by the detectionalgorithm, the SSH traffic is tagged as attack traffic. Theresults show SecControl detected the step-stone attackand the host B’s traffic is successfully reflected to thehoneypot node.
Cooperations among SecControl Nodes. We show the sca-lability of the SecControl framework with multipleSecControl deployments. We use two physical machi-nes, and each physical machine is deployed with oneSecControl instance. Two SecControl frameworks arerunning in two different virtual networks. We configurerouting information of two virtual networks so that they
12 EAI Endorsed Transactions on Security and Safety
12 2018 - 12 2018 | Volume 5 | Issue 17 | e1
Bridging the Gap Between Security Tools and SDN Controllers
can communicate with each other. In our evaluation,we manually send a set of OpenFlow rules from oneSecControl Node to the other, and the result showsthe other SecControl Node can successfully receive andenforce the OpenFlow rules. However, there could be aninformation inconsistency problem when we have moredifferent SecControl Nodes. In order to send SDN rulesto the proper SecControl Node, every SecControl Nodeshould have a full picture of all other SecControl Nodes’network positions and their network device lists. A lotof algorithms studied in distributed computing can beborrowed and used in this scenario. Consider this is notthe focus of this paper, we will not elaborate further onthis.
6.3. OverheadSecControl is a practical network security solutionaiming to provide a comprehensive protection for SDNnetworks. Since SecControl uses different strategies andalgorithms to deal with different security threats, wecan hardly find a unified method to evaluate its overallperformance. We evaluate the time interval between aSecControl flow rule leaves NOX and the flow takeseffect in the network. For the forward primitive, the timeinterval is 7.542 ms; for the drop primitive, the timeinterval is 13.152 ms; for the reflect primitive, the timeinterval is 17.684 ms. Besides, consider our evaluationtestbed is deployed on one physical machine and all theinvolved nodes share the same set of physical resources,we should be able to shorten the time interval value if itis conducted on a more powerful machine.
7. DiscussionWe discuss some limitations of the SecControl fra-mework in this section. First, SecControl may have adelay reaction issue when providing defense responses.This is a common issue for many monitor-based secu-rity tools for there is always a delay between threatdetection and defense reaction. Also, the network effi-ciency may affect the protection effect of SecControl.Consider security events are transmitted over networkbetween the Threat Collecting Agents and the Sec-Control Node, the network transmission efficiency canaffect SecControl’s protection effect. In some protectionscenarios, security engineers may require an instantresponse on a detected threat. A possible way to alle-viate this issue is to build an exclusive network channelbetween the Threat Collecting Agents and SecControlNode. Further, to improve the performance of securityevent collecting, we may design built-in threat col-lecting interfaces on security tools.
Second, SecControl relies on existing security tools togather security events and generate defense responses.We may face an accuracy issue because the accuracyof the security threat information is not exactly
guaranteed. Almost all mainstream security solutionsfollow a detection-based protection policy, and theprotection is affected by detection accuracy. Considerthe current detection algorithms are not perfect, thedetection results may suffer false positive and falsenegative issues. Therefore, SecControl may produceinaccurate defense responses. One possible solutionis to manually record the real attacks and pick upcorresponding defense responses. We believe a lot offurther research can be done on this issue.
Third, consider the SecControl framework relies ona distributed architecture, it may suffer all possibleissues that can happen in a distributed networkenvironment. For example, a potential issue is the singlefailure problem. If the SecControl Node is down, ourprotection will be discontinued. In fact, single failureand all other related issues have been well researched inthe distributed system field. We can just take whatevercomes to our protection scenarios and adopt thesesolutions.
8. Related WorkSecurity Incident and Event Management (SIEM) [29,31] is a set of technologies which are used to gather,analyze and present information from network andsecurity devices. SIEM is designed to collect security-related information from all kinds of devices andapplications such as firewalls, IDS, antivirus, and soon. When an attack happens, security engineers willturn to SIEM for a complete record of that attackfor security investigations and audits. SIEM mainlyfocuses on monitoring and tracing purposes. Comparedwith SecControl, although SIEM is capable of collectingand analyzing security threats, it does not provideinteraction interfaces for the latest SDN networks.
OpenFlow is currently one of the most popularSDN protocols, which has been widely acceptedboth in academia and industry. It originates from aseries of research on enterprise network managementarchitecture, which includes SANE [10], Ethane [9],and ONIX [22]. SANE is proposed to solve enterprisenetwork security problem by providing fine-grainednetwork connection control. In a SANE protectedenterprise network, all the network subjects bydefault are not allowed to visit any network servicesunless being authorized. The initial implementationof SANE relies on a network service directory, whichmaintains an access control list for all the registerednetwork services. The restricted design and clean-slateimplementation make SANE difficult to deploy andtest. Ethane is a greatly improved enterprise networkarchitecture based on SANE, which mainly extendsSANE in three aspects. Ethane first recognizes networksecurity as a subproblem of network management,and believes the security goal can be achieved by
13 EAI Endorsed Transactions on Security and Safety
12 2018 - 12 2018 | Volume 5 | Issue 17 | e1
Li Wang and Dinghao Wu
defining better management policies; Ethane supportsincremental deployment, and that makes it a morepractical network management solution; Ethane hasboth software and hardware implementations whichprovide more hands-on experience for future SDNresearch. Following Ethane, ONIX is devised to providea production-level network control paradigm. ONIXextends Ethane and broadens its control functions tonetwork discovery, devices statistics collecting, andfailure recovery mechanism. Different from Ethane,ONIX aims to break the stable architecture of thetraditional network and build a new distributednetwork control plane. Furthermore, ONIX creativelysuggests building network management applicationsover network control plane, which provides valuablereferences for the following SDN controllers.
SecControl can be regarded as a “controller” ofthe SDN controllers. It releases the security relatedcomputation logic from typical SDN controllers thatshould focus on managing low-level network devices.NOX [17] and POX [27] are two twin open sourceOpenFlow controllers implemented in C++ and Pythonrespectively. They provide a set of APIs for upper-level network applications to dynamically changethe flow tables of OpenFlow switches. However,the current OpenFlow structure is problematic andmay meet some issues when deploying in a largescale network. Researchers propose different SDNcontroller solutions to fit existing controllers into largescale deployments, like HyperFlow [4], Pratyaastha[23], DISCO [33], ElastiCon [14], and ONOS [6].These methods enhance the existing controllers byadding more supports on scalability, device statesynchronization, controller cooperation, fault tolerance,and other functions. Relying on SDN controllers, manynetwork relevant applications have been innovated.Heller et al. [19] propose to reduce the energyconsumptions by improving network infrastructuresof data centers through centralized SDN controllers.Curtis et al. [12] suggest to use SDN controllers tooptimize flow management to further achieve a betteroverall network performance.
SecControl combines traditional security tools andSDN technologies to provide a practical networksecurity solution. For one hand, SecControl makes useof security processing abilities of existing tools; for theother hand, SecControl maximizes the security benefitsof taking SDN technologies. Shin et al. propose FRESCO[35], a modular security application developmentframework for OpenFlow networks. FRESCO providesa fine-grained framework to implement securityfunctions as OpenFlow applications. However, itrequires security engineers to reimplement all securityfunctions to fit FRESCO design, which brings a lotof engineering work. Besides, consider FRESCO isimplemented at controller side, it is greatly confined
by the processing capabilities of the controller. As aresult, the security functions requiring complicatedcomputation and analysis can hardly be deployedwith FRESCO. AVANT-GUARD [36] aims to improvethe data plane performance in order to provide SDNsecurity applications a more scalable and responsiveOpenFlow infrastructure. It designs a connectionmigrations mechanism to improve OpenFlow’s weakpoints and protect OpenFlow devices from saturationattacks. However, AVANT-GUARD does not changethe fact that the SDN controller could be a potentialbottleneck in security applications. Different fromFRESCO and AVANT-GUARD, OpenFlow ExtensionFramework (OFX) [37] modifies the software system ofnetwork hardware devices to allow SDN applicationsdynamically load software modules. OFX achieves agood performance because it is running on switchhardware directly. However, not all security servicescan provide effective protections on a switch hardware.Compared with existing SDN security innovations,SecControl neither introduces heavy workload to SDNcontroller nor brings negative effects to existing securitytools.
Except for the SDN security application frameworks,researchers also extended the individual security toolsin SDN environments. FlowGuard [20] is designedto achieve a firewall running over SDN networks.FlowGuard is capable of checking suspicious networkflows and verifying network-wide firewall policies.However, it just provides basic firewall functions andcannot be extended with other security functions.Similarly, some research modifies traditional intrusiondetection systems to fit SDN environments. Mehdiet.al [28] suggest using SDN to solve home networksecurity problems. They provide four prominenttraffic anomaly detection algorithms to detect securitythreats on SDN controllers. This innovation providesan example of applying SDN technologies in homenetwork security solution.
Some researchers also try to innovate securityfunctions with Network Function Virtualization (NFV)[5]. Aaron et al. design OpenNF [16], a control planearchitecture to enable the reallocation of flows withinNF instances. Through OpenNF, network operatorsare able to create rich control applications, includingfirewall, NAT, traffic loadbalancer, and so on. OpenBox[8] is designed to decouple the control plane ofmiddleboxes from their data planes and unify thedata plane through service instances. It provides aset of interfaces and protocols to communicate withSDN controllers and middleboxes. OpenBox introducesa uniform platform for network admins to designnetwork applications cross SDN network devicesand middleboxes. Similarly, these NFV innovationsfocus on a universal network architecture for generalnetwork applications instead of security applications.
14 EAI Endorsed Transactions on Security and Safety
12 2018 - 12 2018 | Volume 5 | Issue 17 | e1
Bridging the Gap Between Security Tools and SDN Controllers
SecControl can be regarded as a “controller” ofthe SDN controllers. It releases the security relatedcomputation logic from typical SDN controllers thatshould focus on managing low-level network devices.NOX [17] and POX [27] are two twin open sourceOpenFlow controllers implemented in C++ and Pythonrespectively. They provide a set of APIs for upper-level network applications to dynamically changethe flow tables of OpenFlow switches. However,the current OpenFlow structure is problematic andmay meet some issues when deploying in a largescale network. Researchers propose different SDNcontroller solutions to fit existing controllers into largescale deployments, like HyperFlow [4], Pratyaastha[23], DISCO [33], ElastiCon [14], and ONOS [6].These methods enhance the existing controllers byadding more supports on scalability, device statesynchronization, controller cooperation, fault tolerance,and other functions. Relying on SDN controllers, manynetwork relevant applications have been innovated.Heller et al. [19] propose to reduce the energyconsumptions by improving network infrastructuresof data centers through centralized SDN controllers.Curtis et al. [12] suggest using SDN controllers tooptimize flow management to further achieve a betteroverall network performance.
9. ConclusionIn this paper, we propose a new network protectionframework bridging the gap between existing securitytools and SDN technologies, to produce a practicaland comprehensive network security solution for SDNenvironments. SecControl integrates the capabilities ofexisting security tools and combines SDN controls toobtain an optimized SDN network security solution.We demonstrate the capability of SecControl byimplementing a prototype with the OpenFlow protocoland evaluate its effectiveness and performance impactswith common security threats. Our experiments showthat SecControl can cooperate with many mainstreamsecurity tools and provide effective defense responsesover SDN-supported networks.
References[1] Open vSwitch. http://openvswitch.org/.[2] RFC4765. The Intrusion Detection Exchange Mes-
sage Format (IDEMF). https://www.ietf.org/rfc/
rfc4765.txt.[3] E. Al-Shaer and S. Al-Haj. Flowchecker: configuration
analysis and verification of federated openflow infra-structures. In The 3rd ACM Workshop on Assurableand Usable Security Configuration, SafeConfig, Chicago, IL,USA, 2010.
[4] B. Balis. HyperFlow: A model of computation,programming approach and enactment engine for
[5] J. Batalle, J. F. Riera, E. Escalona, and J. A. Garcia-Espin. On the implementation of nfv over an openflowinfrastructure: Routing function virtualization. In FutureNetworks and Services (SDN4FNS), pages 1–6. IEEE,2013.
[6] P. Berde, M. Gerola, J. Hart, Y. Higuchi, M. Kobayashi,T. Koide, B. Lantz, B. O’Connor, P. Radoslavov, W. Snow,and G. M. Parulkar. ONOS: towards an open, distributedSDN OS. In Proceedings of the third workshop on Hot topicsin software defined networking, HotSDN, 2014.
[7] A. Blum, D. X. Song, and S. Venkataraman. Detection ofinteractive stepping stones: Algorithms and confidencebounds. In Recent Advances in Intrusion Detection:Proceedings of 7th International Symposium, RAID, France,2004.
[8] A. Bremler-Barr, Y. Harchol, and D. Hay. Openbox: asoftware-defined framework for developing, deploying,and managing network functions. In Proceedings of the2016 conference on ACM SIGCOMM. ACM, 2016.
[9] M. Casado, M. J. Freedman, J. Pettit, J. Luo, N. McKeown,and S. Shenker. Ethane: Taking control of the enterprise.SIGCOMM Review, 2007.
[10] M. Casado, T. Garfinkel, A. Akella, M. J. Freedman,D. Boneh, N. McKeown, and S. Shenker. SANE: aprotection architecture for enterprise networks. InProceedings of the 15th Conference on USENIX SecuritySymposium - Volume 15, 2006.
[11] F. Cuppens and A. Miège. Alert correlation in acooperative intrusion detection framework. In IEEESymposium on Security and Privacy, 2002.
[12] A. R. Curtis, J. C. Mogul, J. Tourrilhes, P. Yalagandula,P. Sharma, and S. Banerjee. Devoflow: scaling flowmanagement for high-performance networks. InProceedings of the ACM SIGCOMM Conference onApplications, Technologies, Architectures, and Protocols forComputer Communications, 2011.
[13] H. Debar and A. Wespi. Aggregation and correlationof intrusion-detection alerts. In Recent Advancesin Intrusion Detection, Proceedings of 4th InternationalSymposium, RAID Davis, CA, USA, 2001.
[14] A. A. Dixit, F. Hao, S. Mukherjee, T. V. Lakshman, andR. R. Kompella. Elasticon: an elastic distributed sdncontroller. In Proceedings of the 10th ACM/IEEE sympo-sium on Architectures for networking and communicationssystems, 2014.
[15] H. E. Egilmez, S. T. Dane, K. T. Bagci, and A. M.Tekalp. OpenQoS: An OpenFlow controller design formultimedia delivery with end-to-end quality of serviceover software-defined networks. In Asia-Pacific Signaland Information Processing Association Annual Summitand Conference, APSIPA, 2012.
[16] A. Gember-Jacobson, R. Viswanathan, C. Prakash,R. Grandl, J. Khalid, S. Das, and A. Akella. Opennf:Enabling innovation in network function control. ACMSIGCOMM Computer Communication Review, 2015.
[17] N. Gude, T. Koponen, J. Pettit, B. Pfaff, M. Casado,N. McKeown, and S. Shenker. NOX: towards anoperating system for networks. Computer Comm. Rev.,2008.
15 EAI Endorsed Transactions on Security and Safety
[18] N. Handigol, S. Seetharaman, M. Flajslik, N. McKeown,and R. Johari. Plug-n-Serve: Load-balancing web trafficusing OpenFlow. ACM Sigcomm Demo, 2009.
[19] B. Heller, S. Seetharaman, P. Mahadevan, Y. Yiakoumis,P. Sharma, S. Banerjee, and N. McKeown. ElasticTree:Saving energy in data center networks. In Proceedings ofthe 7th USENIX Symposium, NSDI, 2010.
[20] H. Hu, W. Han, G. Ahn, and Z. Zhao. FlowGuard:building robust firewalls for software-defined networks.In Proceedings of the third workshop on Hot topics insoftware defined networking, HotSDN ’14, 2014.
[21] H. Kim and N. Feamster. Improving networkmanagement with software defined networking. IEEECommunications Magazine, 2013.
[22] T. Koponen, M. Casado, N. Gude, J. Stribling, L. Pou-tievski, M. Zhu, R. Ramanathan, Y. Iwata, H. Inoue,T. Hama, and S. Shenker. Onix: A distributed controlplatform for large-scale production networks. In Procee-dings of the 9th USENIX Symposium on Operating SystemsDesign and Implementation, OSDI, 2010.
[23] A. Krishnamurthy, S. P. Chandrabose, and A. Gember-Jacobson. Pratyaastha: an efficient elastic distributedSDN control plane. In Proceedings of the third workshop onHot topics in software defined networking, HotSDN, 2014.
[24] B. Lantz, B. Heller, and N. McKeown. A networkin a laptop: rapid prototyping for software-definednetworks. In Proceedings of the 9th ACM Workshop on HotTopics in Networks. HotNets, 2010.
[25] A. Lazarevic, L. Ertöz, V. Kumar, A. Ozgur, andJ. Srivastava. A comparative study of anomaly detectionschemes in network intrusion detection. In Proceedings ofthe Third SIAM International Conference on Data Mining,2003.
[26] R. Mahajan and R. Wattenhofer. On consistent updatesin software defined networks. In Twelfth ACM Workshopon Hot Topics in Networks, HotNets-XII, 2013.
[27] J. Mccauley. POX: A Python-based OpenFlow controller.http://www.noxrepo.org/pox/about-pox/, 2014.
[28] S. A. Mehdi, J. Khalid, and S. A. Khayam. Revisitingtraffic anomaly detection using software defined networ-king. In Proceedings of the 14th International Symposiumon Recent Advances in Intrusion Detection, RAID, 2011.
[29] D. Miller, S. Harris, A. Harper, S. VanDyke, andC. Blask. Security information and event management(SIEM) implementation. McGraw Hill Professional, 2010.
[30] B. Mukherjee, L. T. Heberlein, and K. N. Levitt. Networkintrusion detection. Network, IEEE, 1994.
[31] M. Nicolett and K. M. Kavanagh. Magic quadrant forsecurity information and event management. GartnerRAS Core Reasearch Note (May 2009), 2011.
[32] B. Pfaff, J. Pettit, K. Amidon, M. Casado, T. Koponen, andS. Shenker. Extending networking into the virtualizationlayer. In Eight ACM Workshop on Hot Topics in Networks(HotNets-VIII), HOTNETS, 2009.
[33] K. Phemius, M. Bouet, and J. Leguay. DISCO: distributedmulti-domain SDN controllers. In IEEE NetworkOperations and Management Symposium, 2014.
[34] P. Porras, S. Shin, V. Yegneswaran, M. Fong, M. Tyson,and G. Gu. A security enforcement kernel for OpenFlownetworks. In Proceedings of the first workshop on Hot topicsin software defined networks. ACM, 2012.
[35] S. Shin, P. A. Porras, V. Yegneswaran, M. W. Fong,G. Gu, and M. Tyson. FRESCO: Modular composablesecurity services for software-defined networks. In20th Annual Network and Distributed System SecuritySymposium, NDSS, 2013.
[36] S. Shin, V. Yegneswaran, P. A. Porras, and G. Gu.AVANT-GUARD: scalable and vigilant switch flowmanagement in software-defined networks. In ACMSIGSAC Conference on Computer and CommunicationsSecurity, CCS, 2013.
[37] J. Sonchack, A. J. Aviv, E. Keller, and J. M. Smith.Enabling practical software-defined networking securityapplications with OFX. In 23th Annual Network andDistributed System Security Symposium, NDSS, 2013.
[38] F. Valeur, G. Vigna, C. Krügel, and R. A. Kemmerer.A comprehensive approach to intrusion detection alertcorrelation. IEEE Trans. Dependable Sec. Comput., 2004.
[39] L. Wang and D. Wu. Seccontrol: Bridging the gapbetween security tools and sdn controllers. In Securityand Privacy in Communication Networks: SecureComm2017 International Workshops, ATCS and SePrIoT, NiagaraFalls, ON, Canada. Springer, 2018.
[40] R. Wang, D. Butnariu, and J. Rexford. OpenFlow-basedserver load balancing gone wild. In USENIX Workshopon Hot Topics in Management of Internet, Cloud, andEnterprise Networks and Services, Hot-ICE, 2011.
[41] H. Yin, X. Liu, G. Min, and C. Lin. Content deliverynetworks: a bridge between emerging applications andfuture IP networks. IEEE Network, 2010.
16 EAI Endorsed Transactions on Security and Safety
![A survey on emerging SDN and NFV security mechanisms for ... › publications › A_survey_on...to SDN and NFV paradigms. In [23], [24], [25], SDN-based security solutions are proposed](https://static.documents.pub/doc/80x56/5eced8390e2bd5210370c255/a-survey-on-emerging-sdn-and-nfv-security-mechanisms-for-a-publications-a.jpg)
