c o m p u t e r s & s e c u r i t y 7 8 ( 2 0 1 8 ) 3 2 1 – 3 3 5
Available online at www.sciencedirect.com
j o u r n a l h o m e p a g e : w w w . e l s e v i e r . c o m / l o c a t e / c o s e
Risk based S ecurity E nforcement in Software
Defined Network
Bata Krishna Tripathy
a , ∗, Debi Prasad Das
b , Swagat Kumar Jena
a , Padmalochan Bera
a
a School of Electrical Sciences, Indian Institute of Technology Bhubaneswar, India b Department of Computer Science and Engineering, National Institute of Technology Rourkela, India
a r t i c l e i n f o
Article history:
Received 5 March 2018
Revised 1 July 2018
Accepted 24 July 2018
Available online 31 July 2018
Keywords:
Software Defined Network (SDN)
Network control functions (NF)
Common Vulnerability Scoring
System (CVSS)
Vulnerability
Exposure
Threat
Risk
a b s t r a c t
Software Defined Network (SDN) paradigm provides intelligent and efficient management
of different network control functions (NF) depending on changes in traffic behavior, service
providers’ requirements and application context. However, the logical centralization of con-
trollers’ functions opens up challenges towards enforcing security perimeter over the under-
lying network and the assets involved. In this paper, we propose a risk assessment model for
pro-active secure flow control and routing of traffic in SDN. The proposed model determines
threat value of different SDN entities by analyzing vulnerability and exposure with respect
to Common Vulnerability Scoring System (CVSS). The risk of a given traffic is calculated
as cumulative threat values of the SDN entities that guides the flow and routing control
functions in generating secure flow rules for the forwarding switches. The efficacy of the
proposed model is demonstrated through extensive case studies of an enterprise network.
Software Defined Networking (SDN) is an emerging network-ing paradigm that allows intelligent and efficient manage-ment of network control functions. It allows execution of dif-ferent network control functions as a logically centralizedcontroller by decoupling them from the underlying forward-ing network ( Nishtha and Sood, 2014 ) consisting of variousnetwork devices, e.g., switches, routers, access points, etc. Thecontroller provides better flexibility and configuration controlto the users with easy and on-demand dynamic configura-tion of the network and its resources ( Ghodsi, 2011 ). The SDNmodel shown in Fig. 1 provides several benefits over the tra-ditional network such as (i) simple and reliable network, (ii)
programmability feature, (iii) flexible device configuration andtroubleshooting, and (iv) virtualization of the network. Dueto these extensive features, Software Defined Networking hasattained significant attention to research community start-ing from academics to industries and has several applicationsin ranging from data centers to wide area networking, cloudcomputing, Internet of Things, Mobile Ad hoc Networking, cel-lular networking, etc. ( Kumar et al., 2015 ).
Software Defined Networking (SDN) enables efficientservice provisioning to end users from various enterpriseapplications based on Service Level Agreements (SLAs) anddynamic requirements in terms of policies by maintainingthe global view of the network. Among various SDN enabledcommunication protocol, the majority of the SDN applica-tions implement OpenFlow protocol ( OpenFlow White Paper )
322 c o m p u t e r s & s e c u r i t y 7 8 ( 2 0 1 8 ) 3 2 1 – 3 3 5
Fig. 1 – A model of Software Defined Networking.
ttan
msnmwl
tSu
2ta
Te
t
Tbbh
atcdatta
pwrtbc
r
1
Ttswd
tgcd
A
sttpttmvtt
tSufl
it
sbetcs
nsct
o support necessary interaction between the controllers and
he switches as OpenFlow is a vendor-independent standard
nd hence allows for interoperability between heterogeneous etworking devices.
Despite the advantages provided by SDN, various perfor- ance and security challenges have been major concerns
ince its evolution. The performance and security issues those eed to be addressed for efficient deployment of SDN are the anagement of complex policies in a simple interface, net- orking delay, lack of standardized interfaces between SDN
ayers, load balancing, packet scheduling, etc. In addition,here exist various open problems to utilize the benefits of DN ( Jammal, 2014 ). The most important problems lie in: (i) sable, reliable and efficient network service offerings ( Kreutz,015 ); (ii) extensible control function execution platform with
he change in network size and requirements ( Metzler, 2012 ); nd (iii) end-to-end security enforcement to network services.he thrust of this paper is to provide a seamless solution for enforcing nd-to-end security in SDN .
A number of security solutions have been contributed by he research communities to address these security issues.hese vary from access control mechanisms to encryption- ased authentication schemes. On the other hand, a num- er of security approaches have been proposed to en- ance the SDN framework using middlebox architectures. In
ddition, few researchers focus on developing Intrusion De- ection System and Intrusion Prevention System to ensure se- urity in SDN. Whereas other classes of researchers aim at ifferent aspects of security approaches such as developing secure flow specification language, inspecting packet level hreats, certificate authentication etc. to detect various at- acks such as Denial of Service, Spoofing, Man-in-the-middle ttacks, etc.
However, the state-of-art SDN security solutions do not rovide an end-to-end secure flow of packets across the net- ork segments by assessing the behavior of the traffic with
espect to different SDN components as the internal architec- ure of SDN as well as the heterogeneous policy rules enforced
y distributed policy enforcing servers impose several security hallenges.
In the next subsection, we discuss the challenges of secu- ity enforcement in SDN with a motivating example.
.1. Motivation
he open user-control, ubiquitous execution of network func- ions and centralized control management introduce various ecurity threats in different levels of Software-Defined Net- ork architecture. The major security challenges in SDN are emonstrated with an example here.
Fig. 2 shows an SDN environment for a segment of an en- erprise network. Here, the Network Application Server (AP) enerates network access control and flow configuration poli- ies based on requirements and those policies are realized
ynamically in the corresponding network control functions.t the Northbound interface (controller-application interface),ecurity challenges with respect to giving permission to al- er the network policies to an application may cause harm
o the whole network. In this scenario, there is a potential ossibility of AP being compromised as it is exposed to ex- ernal users. This might lead to altering the policy rules for he network functions. As a result, the network functions
ight be realized incorrectly that may allow propagation of arious attacks across the network. These attacks can ex- end to Denial of Service (DoS), code injection, and hidden
unnel. Now, consider the scenario, where the flow control func-
ion is driven by the rules generated from Network Application
erver (AP) and Network Management Server (NMS). In such
biquitous computing scenarios, there is a possibility of con- icts amongst the flow rules generated by these servers. This,
n turn, might cause compromising the NMS by the AP leading o security and performance violations in the network.
The controller generates appropriate flow entries from the et of network policy rules and pushes them into the flow ta- les. An SDN cannot distinguish the flow entry of a newly gen- rated application from an older one. So, there is a possibility hat a new network policy generated by an application server an bypass and override the security policy predefined by the ecurity administrator.
Furthermore, there may be vulnerable applications run- ing in end hosts, controllers, and switches leading to various tate-of-art attacks. In addition, the attack paths may be reated across the network segment as the switches along the raffic route may have various open ports. In some cases, the
c o m p u t e r s & s e c u r i t y 7 8 ( 2 0 1 8 ) 3 2 1 – 3 3 5 323
Fig. 2 – A security threat scenario.
network traffic containing malware, trojan or spams originat-ing from corrupted hosts (due to vulnerabilities) might resultin compromised network functions that can be manifestedas different end-point attacks in the networks.
However, the existing security solutions for SDN do notsupport analyzing the behavior of the traffic with respect todifferent SDN components that may lead to various vulnera-bilities and risks that may have a huge impact on the organiza-tional assets. Therefore, an appropriate security enforcementmechanism needs to be introduced to pro-actively analyze therisks of traffics and creating strong isolation between the net-work functions. The main objective of this paper is to providean end-to-end security mechanism for SDN. The major contri-bution of our work lies in developing a novel network securityenforcement function for SDN based on risk assessment.
The proposed security function determines threat value ofdifferent SDN entities by analyzing vulnerability and exposurewith respect to Common Vulnerability Scoring System (CVSS)( Mell et al., 2006 ). The risk of a given traffic is calculated ascumulative threat values of the SDN entities that guides theflow controller in generating secure flow rules for the forward-ing switches.
The remainder of the paper is organized as follows. InSection 2 , we discuss the relevant works related to the secu-rity enforcement mechanisms in SDN. In Section 3 , we presentan overview of our proposed security enforcement functionsfor SDN briefly. In Section 4 , we discuss the Risk_Analyze func-tion in detail, that assesses the risk of different SDN entities
with respect to a given traffic request. Then, we evaluate ourproposed security enforcement functions with a case study inSection 5 . Finally, we conclude the paper in Section 6 .
2. Related work
Software Defined Network simplifies network deploymentand operation along with providing a programmable platformfor managing enterprise and carrier networks. However, withthe introduction of open interfaces in SDN and knowledge ofprotocols in different application programming interfaces, thedoor is thrown open to the attackers. A number of researchworks have been contributed in the area of security enforce-ment in Software Defined Networking environment.
The research communities focus on exploiting SDN to im-prove network security with dynamic detection and mitiga-tion of suspicious activity in a network. Kreutz et al. (2013) re-ported that the centralized nature of controller and the net-work programmability scope introduce new threats in SDN.Mehdi et al. (2011) propose the implementation of SDN toprovide better security in terms of intrusion detection in asmall enterprise environment. OpenSAFE ( Ballard et al., 2010 )addresses security issues for an arbitrary direction of traf-fic with a novel flow specification language, namely ALARMS.FRESCO ( Shin, 2013 ) presents a security application devel-opment framework with different security enabled modu-lar functions that implement python based flow monitoring
324 c o m p u t e r s & s e c u r i t y 7 8 ( 2 0 1 8 ) 3 2 1 – 3 3 5
aGm
tOhpbpieeaia
tirsdMtg
tso
2acdEic
DvdtftSfrwttsfgEc
ts
tpat
ewOt
(F(
n(ntf
ipeiat
2aigetFtS
samne
s
3f
Tmmcicttflrs
3
Imcfp
nd threat detection functions. FleXam ( Shirali-Shahreza and
anjali, 2013 ) facilitates packet level inspection to detect and
itigate security threats like botnet and worm propagation. In addition, various security issues of SDN itself have at-
racted the research communities. NICE ( Canini, 2012 ) secures penFlow Applications using intrusion detection with the elp of attack graphs based analytical models. However, such
ath exploration approaches do not cope well with extensi- le applications. FlowChecker ( Al-Shaer and Al-Haj., 2010 ) ex- loits FlowVisor ( Sherwood, 2009 ) to detect inconsistencies
n policies from multiple applications or the multi-controller nvironment. FLOVER ( Son et al.) deals with conflicting flow
ntries with predefined network policies using assertion sets nd modulo theories. FortNOX ( Porras, 2012 ) resolves conflicts n flow entry installation with role-based and signature-based
uthentication. Another class of researchers aims at developing encryp-
ion approach based security solutions for SDN. The authors n Lam et al. (2015) proposed an Identity-Based Cryptog- aphy (IBC) protocol based mechanism for ensuring secure outhbound and east/west-bound communication in a multi- omain distributed SDN environment. The work ( Natanzi and
ajma, 2017b ) presented a security solution in which the con- roller provides network information only for authorized pro- rams through a safe REST API ( Sohan et al., 2017 ) based onhe NTRU algorithm ( Hoffstein et al., 1998 ) and the NSS digital ignature ( Hostein et al., 2000 ). By analyzing various threats riginating from different SDN layers, the literature ( Shi et al.,017 ) presented a different SDN security framework based on
ttribute-based encryption that enables an improved access ontrol method. Another work ( Natanzi and Majma, 2017a ) eveloped a different authentication scheme by using the lliptic Curve Cryptography on the basis of PKI certificate ver- fication for ensuring a secure communication in distributed
ontroller environment. Gabriel et al. (2014) proposed a technique for handling
istributed Denial of Service (DDoS) attack in an SDN en- ironment, by assessing risk through the means of a cyber- efense system. HiFIND ( Li et al., 2010 ) is a highly secured
echnique that prevents SDN platform from DDoS attacks or high-density data packets providing protection to cus- omers and service provider. SN-SECurity Architecture (SN- ECA) ( Bernardo and Chua, 2015 ) presents a formal security ramework that integrates and validates different security pa- ameters in the SDN/NFV design and implementation. The ork in Wang et al. (2017) presented a detect and defense con-
rol function called as SDN sEcure COntroller (SECO) to pro- ect against Denial of Service (DoS) attack originating from
witches or hosts. SECO uses the switch port statistics per- ormance and the attack source positioning feature from the lobal view of the network for this purpose. The authors in
taiwi et al. (2017) proposed a security scheme for SDN that onsists of different components, i.e., a mapping algorithm,ake-over process, synchronization messages, heartbeat mes- ages, and protective mode to prevent against DoS attack.
Avant guard in literature ( Shin et al., 2013 ) uses connec- ion migration and actuating triggers as security features to rovide security between the forwarding and control plane long with improving the response rate of the controller to he forwarding plane traffic requests. The authors in Kloti
t al. (2013) proposed a model to analyze the potential threats hen data plane communicates with the controller using the penFlow protocol using STRIDE ( Shawn et al., 2015 ) and at-
ack trees to detect various attacks. The authors in Yao et al.2016) proposed a different approach to analyze and model orwarding and Control planes Separation Network Structure FCSNS) in SDN based on STRIDE ( Shawn et al., 2015 ), Petriet, and Attack tree models. In another work, Controller DAC
Tseng et al., 2017 ) presented a controller-independent dy- amic access control scheme to ensure protection of SDN con-
rollers against malicious access by applications through dif- erent APIs (east/westbound and north/southbound).
On the other hand, few researchers focused on develop- ng security middle-boxes for SDN execution platform accom- lishing its programmability feature. Slick framework ( Anwer t al., 2013 ) presents a centralized controller for implement- ng and migrating functions onto customized middle-boxes llowing applications for routing security requirements based
raffic request. FlowTags architecture ( Fayazbakhsh et al.,013 ) is another minimally modified middle-box that inter- cts with an SDN controller through a FlowTags (traffic flow
nformation embedded in packet headers) Application Pro- ramming Interface (API). Another work, the SIMPLE policy nforcement layer ( Qazi et al., 2013 ) requires no modification
o middlebox or SDN in contrast to Anwer et al. (2013) and
ayazbakhsh et al. (2013) . However, middlebox security solu- ions incur significant overhead for security enforcement in
DN. However, the state-of-art security mechanisms do not en-
ure end-to-end security enforcement with the systematic nalysis of real-time and heterogeneous traffic, and assess- ent of the behavior of different SDN entities. Our proposed
etwork security enforcement functions will effectively and
fficiently address these problems. In the next section, we present an overview of our proposed
ecurity enforcement mechanism for SDN.
. Proposed security enforcement framework
or SDN
his section presents our proposed SDN security enforce- ent framework. We propose a novel security enforce- ent function called Risk_Analyze that along with the policy
ontrol functions: Trust_Verify, Policy_Conflict_Resolve and Pol- cy_Consistency_Check ( Tripathy, 2016 ) provides end-to-end se- urity in SDN. Here, the main emphasis of the paper is on
he Risk_Analyze function. Fig. 3 shows the overall architec- ure of the SDN control functions and the process of traffic ow through these functional modules. The proposed secu- ity enforcement functions are briefly discussed in following ubsections.
.1. Trust_Verify
n SDN, different network application servers and manage- ent servers generate policy rules for different network appli-
ations dynamically as per the requirements. The Trust_Verify unction ( Tripathy, 2016 ) checks the following properties of the olicy enforcing servers and certifies them.
c o m p u t e r s & s e c u r i t y 7 8 ( 2 0 1 8 ) 3 2 1 – 3 3 5 325
Fig. 3 – Proposed risk based security enforcement framework for SDN.
• The certificate has been issued by a valid certificate author-ity (CA).
• The certificate has not been expired (or been revoked). • The names listed in the certificate match the domain
names.
In addition, it performs verification of PKI (Public KeyInfrastructure) certificate and trust of the links (inter-faces/ports). Hence, the Trust_Verify function ensures defenseagainst security violations through any compromised applica-tion or management server. The detailed algorithm is demon-strated in our previous work ( Tripathy, 2016 ).
3.2. Policy_Conflict_Resolve
Policy_Conflict_Resolve function ( Tripathy, 2016 ) detects the po-tential conflicts between the heterogeneous policy rules re-ceived by SDN control plane using pattern matching and re-solves them by using the concept of rule override. The over-
ride function uses artificial intelligence based algorithms toresolve the conflicts between heterogeneous policies. ThePolicy_Conflict_Resolve function manages these heterogeneousconflicts by prioritizing the levels of administrators in corre-spondence to different Application and Management Serversbased on their roles. For example, a Network ManagementServer (NMS) usually has higher priority than an ApplicationServer (AP) to serve the traffic as per the requirements. Hence,policy rules set by NMS overrides the policy rules set by AP. Thedetailed algorithm is presented in our previous work ( Tripathy,2016 ).
3.3. Policy_Consistency_Check
SDN platform supports dynamic changes in the applicationlayer by different administrators in the form of requirementsor high-level Service Level Agreements (SLAs). The changesmay be due to altering existing policies, adding or remov-ing policies, installing or removing applications, etc. So, if any
326 c o m p u t e r s & s e c u r i t y 7 8 ( 2 0 1 8 ) 3 2 1 – 3 3 5
pitt
vtocct
3
Tieefi(mme
ivitte
fi
2Rgs
4f
TSRo
lttnv
wlnt
tpp
Fig. 4 – Parsing CVE values from NVD and storing as CVS
values in local vulnerability database for risk assessment.
tT
e
ntupsrpc
Tra
Xtsas
ttOoidt
dtcpicos
olicy is modified in the application layer, it must be reflected
n the flow tables of the data plane switches in order to adapt o the changes in requirements and to allow correct propaga- ion of traffic across the network.
The Policy_Consistency_Check function proposed in our pre- ious work ( Tripathy, 2016 ) detects the inconsistency between
he application layer and data layer. It checks the satisfiability f the existing flow rules in the SDN switches and the updated
onflict-free policy rule sets. This process is triggered by any hange in the Policy repository and at each packet arrival in
he SDN switches.
.4. Risk_Analyze
he three secure control functions, i.e., Trust_Verify, Pol- cy_Conflict_Resolve , and Policy_Consistency_Check compositely nable secure and efficient policy enforcement in SDN. How- ver, there is possibility of security breaches due to miscon- gurations, vulnerabilities, and backdoors in different entities
i.e., compromised end hosts, compromised switches, and compro- ised controller ). Our proposed Risk_Analyze first extracts threat odels for different entities for a given traffic request consid-
ring vulnerability and exposure of each of the entities. Then,t calculates the overall risk of the corresponding traffic in- olved using the weighted sum of the threat values and crit- cality of the traffic request. The calculated risk measures for he related traffic are fed to the routing and flow control func- ions for generating correct routing and flow rules. This will nsure secure flow and routing of traffic in SDN.
We have already discussed the three policy control unctions, i.e., Trust_Verify, Policy_Conflict_Resolve , and Pol- cy_Consistency_Check in details in our previous work ( Tripathy,016 ). The main thrust of this paper lies in developing isk_Analyze function that ensures end-to-end security for a iven traffic request in SDN environment. The next section de- cribes our proposed Risk_Analyze function in detail.
. Risk_Analyze : the risk assessment function
or SDN
his section explains our proposed risk assessment model for DN using the Risk_Analyze function in detail. Our proposed
isk_Analyze function considers the following parameters in
rder to assess the risk of various types of traffic. (a) Vulnerability : It is defined as a software and hardware
evel weakness in the network entities, which may allow an at- acker to reduce the information assurance of the entities and
he underlying network (Vulnerability) . We use Common Vul- erability Scoring System (CVSS) ( Mell et al., 2006 ) for defining ulnerability of the network entities.
(b) Exposure : It is defined as the state or condition of a net- ork being unprotected and open to the risk of suffering the
oss of information (Exposure) . We determine the threat of a etwork entity as the ratio of the potentially unprotected por- ion of the entity to the total entity size.
(c) Threat : Threats are potential events for vulnerabilities hat might lead to exposure of the network and adversely im- act the organizational assets (Threat) . Vulnerability and ex- osure of an entity are used to determine its threat value.
(d) Risk : It is a qualitative measure of potential security hreat and its impact on the network ( Cybersecurity Risk: A
horough Definition ). The Common Vulnerability Scoring System (CVSS) ( Mell
t al., 2006 ) plays an important role for risk assessment of theetwork entities in order to ensure secure flow of traffic across he network segment. The proposed risk assessment module ses a data structure called vulnerability database for this pur- ose. The vulnerability database is a local repository (offline) tored in the controller and is periodically updated with the ecent Common Vulnerability Score (CVS) values of the ap- lications or protocols or services running in different SDN
omponents or entities (controller, end hosts, and switches).he CVS values are computed by extracting necessary met- ics from online National Vulnerability Database (NVD) using script (python).
The recent vulnerability values available in NVD are in
ML format that contains two standard scores: V2 and V3 in
he form of Common Vulnerability and Exposure (CVE) mea- ures. The detailed process of parsing CVE values from NVD
nd storing in local vulnerability database as CVS values in- ide the controller is explained in Fig. 4 . It is to be notedhat in the vulnerability database, there exists exactly one en- ry of CVS value for an application with its version and the perating System platform as it is the updated CVSS value f the application parsed from NVD’s recent XML file us-
ng the script. The structure of an entry in the vulnerability atabase is 〈 Application / service / protocol, Version, Operating sys- em, CVS value 〉 .
Generally, the V3 standard is an improvement over V2 stan- ard as V3 considers the context of attacker’s access rights o read/write/execute to exploit the vulnerability and physi- al manipulation of the affected components. Hence, our pro- osed risk assessment module uses the V3 version of CVE as
ts CVS value for necessary risk assessment for secure pro- essing and flow a given traffic request. However, for some lder vulnerabilities there exist only V2 values in NVD. In
uch case, the CVS value for a vulnerability is calculated in
c o m p u t e r s & s e c u r i t y 7 8 ( 2 0 1 8 ) 3 2 1 – 3 3 5 327
Table 1 – Transformation of V2 metrics and their values for CVS computation.
V2 metric Value Transformed
metric Value
Base metrics Exploitability group Access vector Local: 0.395 Attack vector Local: 0.55
Impact subscore modifier Confidentiality, integrity, and availability requirements
Low: 0.5 Confidentiality, integrity, and availability requirements
Low: 0.5
Medium: 1.0 Medium: 1.0 High: 1.51 High: 1.5
(
two steps from the available V2 metrics in NVD as discussedbelow.
(i) Step 1 – transformation of V2 metrics: In order to compute the overall vulnerability value, CVSSconsiders certain metrics that define the hardware, soft-ware and network level vulnerabilities. The V2 version dif-fers from the V3 version in terms of the metrics and theirvalues considered for overall vulnerability score computa-tion. However, for some older vulnerabilities, V3 value isnot available in the NVD. In this scenario, the CVS valuefor a vulnerability in our solution is estimated from theV2 metrics available in the XML file by appropriately trans-forming the metrics and their values as shown in Table 1 .
The transformation is performed as per the CVSS V2 andCVSS V3 standards. These metrics after the transformation process are thenused for the necessary CVS computation in the proposedmechanism. The estimation of CVS value for a vulnerabil-ity is performed as explained below in the subsequent step.
ii) Step 2 – calculation of CVS values: The CVS value for a vulnerability is determined from thedesired metrics obtained in the previous step, using thestandard equations for the overall V3 version of CVSS com-putation ( CVSS V3 ) with optimization in order to minimizethe overhead of the CVS computation process. The proce-dure of the overall CVS value calculation is illustrated inFig. 5 .
328 c o m p u t e r s & s e c u r i t y 7 8 ( 2 0 1 8 ) 3 2 1 – 3 3 5
Fig. 5 – CVS computation of vulnerabilities from the transformed metrics in case of nonavailability of V3 value in NVD.
Tmwt
dv
t
mt
tD
4
Tewi
he entities of the Software Defined Network architecture ight be the potential sources of vulnerabilities in the net- ork ( Prasad et al., 2015 ). In this paper, we have considered
he following SDN entities for risk assessment.
• compromised end hosts • compromised switches • compromised controller
In our Risk_Analyze function, we extract threat models for ifferent entities with respect to a given traffic request using ulnerability and exposure analysis of those entities. Then,he overall risk of a given traffic request is calculated as cu-
ulative threat values of the SDN entities and criticality of he traffic request.
The following subsections illustrate the threat model and
he risk assessment model for different entities of Software efined Network.
.1. Threat model for SDN entities
his subsection presents the threat model for different SDN
ntities for a specific traffic request. The threat associated
ith different SDN entities are modeled using the vulnerabil- ty and exposure of the entities as follows.
c o m p u t e r s & s e c u r i t y 7 8 ( 2 0 1 8 ) 3 2 1 – 3 3 5 329
V
V
V
4.1.1. Threat model for an end host The threat level of an end host is modeled using the vulner-ability and exposure of the host. The model is presented asfollows.
(i) Vulnerability of an end host : A number of vulnerable appli-cations such as FTP, RSH, nmap etc. may be running in an endhost for processing a specific traffic request. The vulnerabilityof an end host V h is calculated as the average of the CommonVulnerability Scores (CVS) of all the applications running onthe host extracted from the vulnerability database, i.e.,
h =
1 10
∗∑ k
i =1 CVS i k
(1)
where h ε{ x, y }. Here, x and y are the source and destinationhosts, respectively. CVS i is the Common Vulnerability Score ofthe i th application running in the host h , and k is the numberof applications running in the host. The average value of theCVS of all applications is divided by 10 in order to normalizethe value of V h to 1 as the CVS of the applications lie between0 to 10.
(ii) Exposure of an end host : The exposure of an end host E his determined considering the number of hosts that may beaffected because of the vulnerability in the target end host.Hence, it is computed as,
E h =
n N
(2)
where n is the number of hosts communicating with the targethost and N is the total number of hosts in the network.
(iii) Threat value of an end host : Threat value of an end-host τh
is calculated as a product of vulnerability and the exposure ofthe end host for a traffic request t . Mathematically it is definedas follows.
τh = V h ∗ E h (3)
τh lies between 0 and 1. τh = 1 indicates the entity has highrisk of being compromised.
Similarly, we can define threat model for switches and con-troller with respect to a given traffic request.
4.1.2. Threat model for a switch
The threat model for an SDN switch is assessed using its vul-nerability and exposure analysis as follows.
(i) Vulnerability of a switch : The vulnerability of a switch V s
is determined as the ratio sum of the Common VulnerabilityScores (CVS) of the protocols running on the switch. For exam-ple, protocols are Multiprotocol Label Switching (MPLS) proto-col, Label Distribution Protocol (LDP), etc. Our model can flex-ibly accommodate any new protocol used in switches. Mathe-matically, it is determined as,
s =
1 10
∗∑ q
i =1 CVS i q
(4)
where CVS i is the Common Vulnerability Score of the i th pro-tocol running on the switch s (0 ≤ CVS i ≤ 1), and q is the num-ber of protocols running on the switch s . Similar to determin-ing the value of V h , the ratio sum of the CVS of all protocols
running on the switch is divided by 10 so as to normalize thevalue of V s to 1.
(ii) Exposure of a switch : Exposure of a switch E s is definedusing the probability of malfunctioning involved with an ac-tive connection and total number of ports on that switch. E s iscalculated as,
E s =
x p ∗ (1 − x ) P−p
P (5)
where p is the number of active connections, P is the totalnumber of ports on the switch and x is the probability of anactive port getting malfunctioned. For standard ports, i.e., [0–1023], x is varied between 0 and 0.5. On the other hand, forvarious application specific non-standard ports, 0.5 < x ≤ 1. Forexample, for running FTP application on standard ports suchas 989 and 990, we use x = 0 . 3 whereas for running the sameFTP application on a non-standard port such as 4901, we con-sider x = 0 . 6 .
(iii) Threat value of a switch : Vulnerability and exposure of aswitch are used to determine its threat value. Threat value τ s
of a switch s is determined as,
τs = V s ∗ E s (6)
In addition, the proposed model determines the threatvalue of a traffic route. An access route r ( x, y ) is defined as asequence of switches < s 1 , s 2 , . . . , s m
> from source host x todestination host y in the network, where Inter face (s i , s i +1 ) = T and reachable (x, y ) = T . Threat value τ r of the route r associ-ated to a traffic t is calculated using the threat values of theswitches along that route as follows.
τr =
∑ m
i =1 τs i
m
(7)
where m is the number of switches in the access route r . Thethreat value of a route lies between 0 and 1.
4.1.3. Threat model for network controller The threat model for an SDN controller is evaluated using thevulnerability and exposure analysis of the control functions inthe SDN control plane as follows.
(i) Vulnerability of a controller : A controller may run variousnetwork control functions such as Load Balancing, AnalysisEngine, Control-Plane MainApp, etc. Hence, the vulnerabilityV c of a controller c is estimated using the mean of CommonVulnerability Score (CVS) of the control functions running onit. If CVS i is the Common Vulnerability Score of the i th controlfunction running on the controller c , and j is the number ofprotocols running on the controller c , then V c is calculated as,
c =
1 10
∗∑ j
i =1 CVS i j
(8)
Similar to Eqs. (1) and (4) , V c is normalized so that its valuelies between 0 and 1 as the CVS of the control functions run-ning the controller lie between 0 to 10. The proposed modelcan be extended to include any new control functions.
(ii) Exposure of a controller : Exposure of a controller E c is de-fined as the ratio between the number of dependent network
330 c o m p u t e r s & s e c u r i t y 7 8 ( 2 0 1 8 ) 3 2 1 – 3 3 5
ftn
E
fv
τ
ct
4
Omsi
a
A
1
1
1
1
1
1
1
1
1
1
2
pfi
hcSs
w
a
Table 2 – Risk assessment model of SDN.
Traffic criticality Total threat value
≤ 0.39 0.4–0.69 ≥ 0.7
H M H C
M L M H
L L L M
Note: C – Critical, H – High, M – Medium and L – Low.
i
w
b
i
i
capipphct
t
ssi
w
Rtfs
Tas
eb
5
Trssat
unctions ( l ) (as execution of the control functions depend on
he output of other control functions) and the total number of etwork functions ( L ). Mathematically, it is calculated as,
c =
l L
(9)
(iii) Threat value of a controller : Threat value of a controller τ c
or a given traffic request t is determined as the product of its ulnerability and exposure measures, i.e.,
c = V c ∗ E c (10)
The threat value of a controller lies between 0 and 1. The following subsection illustrates the Risk_Analyze that
alculates the risk for a given traffic request as the cumulative hreat values of the different SDN entities.
.2. Risk_Analyze
ur proposed risk assessment model first evaluates threat odel for different SDN entities as discussed in the previous
ubsection. Then, the overall risk measure τ t of a given traffic t s calculated as the cumulative threat values of the end hosts,ccess route and the control functions involved. Algorithm 1
lgorithm 1 Risk_Analyze algorithm.
1: procedure Risk_Analyze 2: for each traffic t do 3: analyze packet header 4: Entity set E= { x, y, r, c } and Route 5: r = { s 1 , s 2 , . . . , s m
} 6: for each entity i ∈ E− { r } do 7: find V i
8: find E i 9: calculate τi = V i * E i 0: end for 1: for each switch s ∈ r do 2: find V s
3: find E s 4: calculate τs = V s * E s 5: end for 6: calculate τr =
∑ m i =1 τs i m
7: calculate τt = w x * τx + w y * τy
8: + w r * τr + w c * τc
9: end for 0: end procedure
resents the risk assessment procedure associated with a traf- c.
Algorithm 1 uses weights: w x , w y , w r , and w c for sourceost x , destination host y , access route r , and the controller , respectively, in order to consider the criticality of each
DN entity. w r is the sum of weights of all the switches <
1 , s 2 , . . . , s m
> along the route r .
r = w s 1 + w s 2 + · · · + w s m (11)
These weights are selected based on criticality of the nodes nd should be chosen such that their sum must be equal to 1.
.e.,
x + w y + w r + w c = 1 (12)
Total threat value τ t associated with a traffic t always lies etween 0 and 1.
The threat value ( τ t ) associated to a traffic t and its critical-ty ( I t ) are used to define the risk ( R t ) of the traffic. The critical-ty of the traffic can be High (H), Medium (M) or Low (L). Theriticality of a traffic depends on the impact of the traffic in
specific application context. For example, in a Banking ap- lication, transactions have high impact and hence have High
mportance whereas the generation of logs has medium im- act leading to Medium importance. On the other hand, sim- le query processing has low impact in the context and hence ave low importance. So, we consider three different traffic riticality levels; i.e., High (H), Medium (M) and Low (L), respec- ively, for these three types of traffic.
The mapping function for assessing the risk of a specific raffic is expressed as:
f : τt × I t −→ R t (13)
Table 2 shows the Risk assessment model of SDN with re- pect to the criticality of the traffic and threat level with re- pect to the specific traffic. For example, if criticality of a traffic s High (H) and its threat value is 5.5, then the risk associatedith the traffic is High (H).
The calculated risk measures determined by the proposed
isk_Analyze function, are used in the flow and routing con- rol functions to extract an optimal route with minimal risk or the given traffic request. This process is executed recur- ively until an optimal route with minimal risk is found.hen, the flow rule with this route and other flow attributes re populated in the flow tables of corresponding forwarding witches.
In the next section, we demonstrate our proposed security nforcement function with an extensive case study of an SDN
ased enterprise network.
. Experimental results: case study
his section presents the performance of our proposed secu- ity enforcement functions with a case study. Fig. 6 shows a egment of an SDN based large enterprise network with four ubnets corresponding to different departments, i.e., Research
nd Development (R & D), Finance, Sale, and Customer Rela- ionship (CR). The underlying SDN platform executes a set of
c o m p u t e r s & s e c u r i t y 7 8 ( 2 0 1 8 ) 3 2 1 – 3 3 5 331
Fig. 6 – A segment of an enterprise network.
control functions such as Wireshark, mainApp, OpenSSL, etc.inside the controller. The end hosts run applications FTP, RSH,nmap etc. In addition, the switches run protocols, e.g., MPLS,LDP, etc.
The requirements on various network traffic are stated asfollows:
Req 1 : All outbound traffic from CR department should gothrough Proxy server (PS).
Req 2 : All traffic from employees of R & D working outsideshould be served through Virtual Private Network (VPN) withhigh bandwidth.
Req 3 : Any incoming traffic to R & D and Finance should beforwarded through policy check and security compliance.
Req 4 : Any outbound traffic from R & D and Finance shouldguarantee high bandwidth and availability.
Req 5 : Customers should be able to communicate to CRthrough a secure channel and remote shell service (RSH). Letthey connect through port number 8091.
Req 6 : The employees of Finance and Sale should performfile transfer or transaction with proper authentication.
Req 7 : All traffic related to financial transaction from Fi-nance to employees of R & D should be authenticated.
In order to process the traffic requests with respect to theserequirements, the SDN controller must ensure secure flowof traffic across the network segment. The next subsectionpresents the efficacy of our proposed risk assessment modelwith different test cases considering the above-mentioned re-quirements.
5.1. Efficacy of the security control functions
We have implemented our proposed security enforcementcontrol functions in mininet simulator ( Mininet Documenta-tion ) with OpenFlow controller ( OpenFlow White Paper, Open-Flow Specification ). We have generated different traffic withvarying traffic rates from 10 traffic per sec (TPS) to 100 traf-fic per sec (TPS). Our proposed functions Trust_Verify, Pol-
icy_Conflict_Resolve, Policy_Consistency_Check , and Risk_Analyzeare applied on these traffic to generate secure flow and routingcontrol rules.
In order to process the traffic requests as per the above-mentioned requirements, our proposed risk assessmentmodel first extracts the CVS scores or values of various relatedapplications, protocols, and services running in different lay-ers of the network from local vulnerability database. Table 3shows the CVS scores of some of the applications, protocols,and services running in different components of the SDN en-vironment under test with their vulnerability details. For ex-ample, OpenSSL v1.0.2b is a network control function runningin the controller and has CVS score 5.9 that leads to confiden-tiality violation. On the other hand, nmap service running onend host with Android 6.1 Operating system has CVS score 7.8and has impact like DoS attack, Arbitrary controller code ex-ecution. Similarly, LDP is a protocol running on an OpenFlowswitch has CVS value 7.5.
Based on the CVS Score of the related applications, proto-cols and services with respect to a given traffic request theRisk_Analyze function determines the threat model for differ-ent SDN entities. The overall threat value is calculated as thecumulative threat values of the SDN entities. Finally, the riskof the specific traffic request is determined with respect to thefinal threat value and the criticality of the traffic. These riskmeasures guide the flow and routing controller to decide theflow rules (routing path along with other flow attributes) to bepopulated in the flow tables of the switches.
Table 4 shows the results of Risk_Analyze function for fewsample traffic requests taken as test cases. For example, thetraffic request t 1 associated to Req 1 has medium risk withroute r 1 and low risk with route r 2 . Hence, the routing pathdecided by the flow and routing control function is r 2 . Simi-larly, the traffic request t 2 associated to Req 2 has high risk withroute r 1 and medium risk with route r 2 . Therefore, the route r 2is chosen for traffic t 2 . The abbreviations used in the Table 4 areas follows.
332 c o m p u t e r s & s e c u r i t y 7 8 ( 2 0 1 8 ) 3 2 1 – 3 3 5
Table 3 – Common Vulnerability Score (CVS) of applications/services/protocols.
Applications/ Services/ Protocols
version Operating System
Bug details CVE id (online NVD) ( National Vulnerability Database )
Fig. 7 – Execution time of the proposed network security
functions w.r.t. traffic rate.
total number of traffic requests. The abbreviations TREQ, CNF,BLK, CONS, RISK in the table indicate the number of trafficrequests, number of conflicts detected and resolved, num-ber of applications blocked, number of inconsistencies iden-tified between existing flow rules and updated policy rules,and number of risks mitigated respectively. Our previous work( Tripathy, 2016 ) already discusses the number of conflicts de-tected, potential compromised applications blocked, and thenumber of inconsistencies resolved for a specific traffic re-quest. In this paper, we determine the number of potentialrisks associated with a given traffic request. The number ofrisks in this context means the number of vulnerabilities de-termined to have either one of the risk values: Low, Medium,High or Critical associated with a specific traffic request. Therecan be more than one vulnerabilities related to a given trafficrequest in this case. While finding the overall vulnerability ofend hosts, switches and controllers respectively in Eqs. (1) , ( 4 )and ( 8 ) for a specific traffic request, we maintain a data struc-ture to keep track of the individual vulnerabilities associatedto the applications with their risk levels. The same is reportedwith their impact with respect a specific traffic request andthe risks of different levels are mitigated appropriately.
The efficacy of our proposed security functions is eval-uated in terms of execution time with varying traffic rate.Fig. 7 shows the execution time for different security enforce-ment functions. In our previous work ( Tripathy, 2016 ), we al-ready observed that, the execution time of Trust_Verify and Pol-icy_Consistency_Check functions almost remains constant withincrease in traffic rate. On the other hand, the execution timeof Policy_Conflict_Resolve function increases quadratically withthe increase in traffic rates as reported in Tripathy (2016) . This
is due to increase in the number of policy and flow controlrules with the increase in traffic rate. In this paper, we eval-uate the execution time of Risk_Analyze function and reportthat it increases almost linearly with the increase in trafficrate. This is due to the use of a fixed threat model with a spe-cific number of parameters used (vulnerability, exposure, andtraffic criticality).
It is observed that the overall execution time of our pro-posed security enforcement functions lies within 2 s for traf-fic rate of 100 TPS that imply that these functions incur lessoverhead and is considerably reasonable for any kind of net-work. Our proposed functions incorporated in the SDN con-trol plane ensures end-to-end secure transmission of pack-ets across the network control execution environment andthereby strengthens the security perimeter over the underly-ing network.
In future, we plan to extend our proposed security enforce-ment functions for heterogeneous network environmentswith varying requirements and application context. In addi-tion, sensitivity analysis will be incorporated in the proposed
334 c o m p u t e r s & s e c u r i t y 7 8 ( 2 0 1 8 ) 3 2 1 – 3 3 5
sv
2oet
6
Tftwpcoltrttrbassnw
R
A
A
A
B
B
C
C
C
E
E
F
G
G
H
H
J
K
K
K
K
L
L
M
M
M
M
N
ecurity solution as it helps in identifying the sources of the ulnerabilities in the system. Sensitivity ( Younis and Malaiya,015 ) is mathematically defined as the ratio of the number f correctly predicted vulnerabilities those may be potentially xploitable to the number of actually exploitable vulnerabili- ies.
. Conclusion
he Software Defined Network (SDN) paradigm might suffer rom various security threats due to its inherent characteris- ics such as open user-control, ubiquitous execution of net- ork functions and centralized control management. In this aper, a risk assessment model is proposed where the core omponent, i.e., the Risk_Analyze function analyzes the risk f a specific traffic request based on the threat models of re-
ated SDN entities. Then, these risk values are communicated
o flow and routing control function for generating secure flow
ules with no or minimal risk. The proposed security solu- ion enables a pro-active end-to-end security assessment of he traffic requests and accordingly ensures a secure flow and
outing process. The efficacy of our proposed functions has een evaluated through a case study of an enterprise network nd the results have been reported. In future, the proposed
ecurity mechanism will be enhanced with appropriate sen- itivity analysis to find out the potential sources of the vul- erabilities. In addition, the security functions will be verified
ith varying requirements and context.
E F E R E N C E S
Complete Guide to the Common Vulnerability Scoring System
Version 2.0. [online]. Available: https://www.first.org/cvss/v2/guide , (2007).
l-Shaer E , Al-Haj S . Flowchecker: configuration analysis and
verification of federated openflow infrastructures. Proceedings of the third ACM workshop on assurable and
usable security configuration, 2010 .nwer, B., Benson, T., Feamster, N., Levin, D., & Rexford, J. (2013). A
allard JR , Rae I , Akella A . Extensible and scalable network monitoring using opensafe. Proceedings of the internet network management workshop/workshop on research on
enterprise networking (INM/WREN), 2010 .ernardo DV , Chua BB . Introduction and analysis of SDN and NFV
security architecture (SN-SECA). Proceedings of the twenty-ninth IEEE international conference on advanced
information networking and applications. Gwangiu; 2015. p. 796–801 .
anini M , et al . A NICE way to test openflow applications. Proceedings of the ninth USENIX conference on networked
systems design and implementation, 2012 .ommon Vulnerability Scoring System v3.0: Specification
ayazbakhsh S , Sekar V , Yu M , Mogul J . Flowtags: enforcing network-wide policies in the presence of dynamic middlebox actions. Proceedings of the second workshop on hot topics in
software defined networks. ACM, 2013 .abriel , et al . Achieving DDos resiliency in a software defined
network by intelligent risk assessment based on neural networks and danger theory. Proceedings of the fifteenth
international symposium on computational intelligence and
informatics. IEEE; 2014. p. 319–24 .hodsi , et al . Intelligent design enables architectural evolution.
Proceedings of the tenth ACM workshop hot topics in
networks; 2011. p. 1–6 .offstein J , Pipher J , Silverman JH . NTRU: a ring-based public key
cryptosystem. Algorithmic number theory, ANTS. Springer; 1998. p. 267–88 .
offstein J., Pipher J., Silverman J.H. (2001) NSS: An NTRU
Lattice-Based Signature Scheme. In: Pfitzmann B. (eds) Advances in Cryptology — EUROCRYPT 2001. EUROCRYPT
ammal M , et al . Software defined networking: state of the art and research challenges. Comput Netw 2014;72:74–98 . Elsevier
loti R , Kotronis V , Smith P . Openflow: a security analysis. Proceedings of the twenty-first IEEE international conference on network protocols (ICNP). Gttingen, Germany; 2013. p. 1–6 .
reutz D , et al . Software-defined networking: a comprehensive survey. Proc IEEE 2015;103(1):14–76 . January
reutz D , Ramos F , Verissimo P . Towards secure and dependable software-defined networks. Proceedings of the second ACM
SIGCOMM workshop on hot topics in software defined networking; 2013. p. 55–60 .
umar A , Jain S , Naik U , et al . BWE: flexible, hierarchical bandwidth allocation for WAN distributed computing. Proceedings of the ACM conference on special interest group
on data communication (SIGCOMM’15). London, UK; 2015. p. 1–14 . August
am J-H , Lee S-G , Lee H-J , Oktian YE . Securing distributed SDN
with IBC. Proceedings of the 2015 seventh international conference on ubiquitous and future networks. Sapporo; 2015.p. 921–5 .
i Z , Gao Y , Chen Y . HiFIND: a high-speed flow-level intrusion
detection approach with dos resiliency. Comput Netw
2010;54(8):1282–99 .ehdi SA , Khalid J , Khayam SA . Revisiting traffic anomaly
detection using software defined networking. Recent advances in intrusion detection. Springer; 2011. p. 161–80 .
ell P , Scarfone K , Romanosky S . Common vulnerability scoring system. IEEE Secur Priv 2006;4(6):85–9 . December
atanzi SBH , Majma MR . Secure distributed controllers in SDN
based on ECC public key infrastructure. Proceedings of the 2017 international conference on electrical and computing technologies and applications (ICECTA). Ras Al Khaimah; 2017a. p. 1–5 .
c o m p u t e r s & s e c u r i t y 7 8 ( 2 0 1 8 ) 3 2 1 – 3 3 5 335
Natanzi SBH , Majma MR . Secure northbound interface for SDN
applications with NTRU public key infrastructure. Proceedingsof the fourth IEEE international conference on
knowledge-based engineering and innovation (KBEI). Tehran; 2017b. p. 0452–8 .
Nishtha , Sood M . Software defined network-architectures. Proceedings of 2014 international conference on parallel, distributed and grid computing (PDGC); 2014. p. 451–6 .December
National Vulnerability Database (NVD). [online]. Available: https://nvd.nist.gov/ , (2018).
Software-Defined Networking: The New Norm for Networks. [Online]. Available: https://www.opennetworking.org/images/stories/downloads/ sdn- resources/white- papers/wp- sdn- newnorm.pdf, (2012).
Porras P , et al . A security enforcement kernel for openflow
networks. Proceedings of the first workshop on hot topics in
software defined networks. ACM; 2012. p. 121–6 .Prasad AS , Koll D , Fu X . On the security of software-defined
networks. Proceedings of the fourth European workshop on
software defined networks. Bilbao; 2015. p. 105–6 .Qazi ZA , Tu CC , Chiang L , Miao R , Sekar V , Yu M . SIMPLE-fying
middlebox policy enforcement using SDN. Proceedings of the 2013 ACM SIGCOMM, 2013 . August
Shawn, H., Scott, L., Tomasz, O., & Adam, S. (2015). Uncover security design flaws using the STRIDE approach. Mar.[Online]. Available: http://msdn.microsoft.com/en-gb/magazine/cc163519.aspx , (2015).
Sherwood, R., et al. (2009). Flowvisor: a network virtualization
layer. Openflow switch consortium.Shi Y , Dai F , Ye Z . An enhanced security framework of software
defined network based on attribute-based encryption. Proceedings of the fourth 2017 international conference on
systems and informatics (ICSAI). Hangzhou; 2017. p. 965–969 .
Shin S , et al . FRESCO: modular composable security services for software-defined networks. Proceedings of the network and
distributed security symposium, 2013 .Shin S , Yegneswaran V , Porras P , Gu G . AVANT-GUARD: scalable
and vigilant switch flow management in software-defined networks. Proceedings of the ACM conference on computer and communications security. Berlin, Germany; 2013. p. 413–24 .
Shirali-Shahreza S , Ganjali Y . Efficient implementation of security applications in openflow controller with flexam. Proceedings of the twenty-first IEEE annual symposium on
high-performance interconnects. IEEE; 2013. p. 49–54 .Sohan SM , Maurer F , Anslow C , Robillard MP . A study of the
effectiveness of usage examples in REST API documentation. Proceedings of the 2017 IEEE symposium on visual languages and human-centric computing (VL/HCC). Raleigh, NC; 2017. p. 53–61 .
Son, S., et al. Model checking invariant security properties in
Tripathy BK , et al . A novel secure and efficient policy management framework for software defined network. Proceedings of the forty IEEE annual computer software and
applications conference. IEEE; 2016. p. 423–30 .
Tseng Y , Pattaranantakul M , He R , Zhang Z , Nat-Abdesselam F . Controller DAC: securing SDN controller with dynamic access control. Proceedings of the 2017 IEEE international conference on communications (ICC). Paris; 2017. p. 1–6 .
Wang S , Chavez KG , Kandeepan S . SECO: SDN secure COntroller algorithm for detecting and defending denial of service attacks. Proceedings of the fifth international conference on
information and communication technology (ICoIC7). Melaka; 2017. p. 1–6 .
Yao L , Dong P , Zheng T , Zhang H , Du X , Guizani M . Network security analyzing and modeling based on petri net and
attack tree for SDN. Proceedings of the 2016 international conference on computing, networking and communications (ICNC). Kauai, HI; 2016. p. 1–5 .
Younis AA , Malaiya YK . Comparing and evaluating CVSS base metrics and microsoft rating system. Proceedings of the 2015 IEEE international conference on software quality, reliability and security. Vancouver, BC; 2015. p. 252–61 .
Bata Krishna Tripathy is a Ph.D. student inSchool of Electrical Sciences, Indian Instituteof Technology Bhubaneswar, India. He re-ceived his M.Tech. degree from Indian Insti-tute of Technology Kharagpur, India in 2014.He has completed his B.Tech. from Insti-tute of Technical Education and Research,Bhubaneswar, India in 2007. He has expertisein Mobile Ad hoc Networking, Software De-fined Networking, and Network Security.
Debi Prasad Das has received his B.Tech.degree from National Institute of Technol-ogy Rourkela, India in 2017. He was workingas an intern at Indian Institute of Technol-ogy Bhubaneswar, India in summer and win-ter vacations during B.Tech. He is currentlyplaced in Itron American Technology com-pany, Bangalore, India as a Software Engi-neer. He has expertise in Software DefinedNetworking and Network Security.
Swagat Kumar Jena is a Project in School ofElectrical Sciences, Indian Institute of Tech-nology Scholar Bhubaneswar, India. He re-ceived his M.Tech. degree from Indian Insti-tute of Technology Kharagpur, India in 2014.He has completed his B.Tech. from SeemantaEngineering College, Jharpokharia, India in2008. He has expertise in Internet of Things,Wireless Sensor Network, and Network Se-curity.
Padmalochan Bera received his Ph.D. fromIndian Institute of Technology Kharagpur,India in 2011. He completed his M.E. de-gree from West Bengal University of Tech-nology, Kolkata, India and his B.E. from Ja-davpur University, Kolkata, India in 2001. Heis currently working as an Assistant Pro-fessor in School of Electrical Sciences, IITBhubaneswar, India. He has expertise in Net-work and Cyber Physical Systems Security,Software Defined Networking, Cloud Com-puting, Formal Verification and optimiza-tion.
