Improving Covert Storage Channel Analysis with SDN and Experimentation on GENI

Yiyuan Hu Johns Hopkins University

3400 N. Charles St. Baltimore, MD 21218 yhu30@jhu.edu

Xiangyang Li Johns Hopkins University

3400 N. Charles St. Baltimore, MD 21218

(+1) 410-5168521 xyli@jhu.edu

Xenia Mountrouidou Wofford College

429 N. Church St. Spartanburg, SC 29301

(+1) 864-5974528 mountrouidoup@wofford.edu

ABSTRACT This paper introduces a collaborative approach of detecting one type of covert storage channel (CSC) in packet TCP Flags and the experimentation of this approach. A CSC using packet TCP Flag headers can segment a message into multiple pieces and send them through multiple network paths to a destination where they are then reassembled. This stealth technique through flow split-join operations aims to protect a high-value command and control channel. The proposed approach employs Software-Defined Networking (SDN) to access critical information about network flows and improve both the efficiency and accuracy of detection and mitigation as applicable. In order to reveal potential CSCs, a group of monitors and correlators coordinate to observe aggregate and individual network traffic flows, at multiple network locations, for irregularities. The effectiveness of such an approach is evaluated on a realistic networking testbed, GENI (Global Environment for Network Innovations).

Categories and Subject Descriptors Security and Privacy: Intrusion Detection Systems

General Terms Experimentation, Security

Keywords Covert Storage Channel (CSC), Software Defined Networking (SDN), Global Environment for Network Innovations (GENI)

1. INTRODUCTION A covert channel aims to convey information secretly in a way that its host system is not designed or intended for, to purposely hide the channel from being seen by monitoring facilities. For example, two programs monitoring disk-reading speed can enable a covert channel. The host system is unable of detecting this. The hypervisor system would not know that coding bits in such speed variation could transmit a secret message.

There are two types of covert channel techniques, timing channel and storage channel [1]. A covert timing channel (CTC) like the

above example alters a temporal characteristic of a system. The accomplices code and decode transmitted information by measuring the change in this characteristic. The second type of covert channel, a covert storage channel (CSC), uses legitimate protocol fields, in a way they are not designed for, to convey secret messages. It interprets the value in the field according to a different coding. A computer network is an ideal environment to construct such CSC channels for its many network header fields used by TCP/IP packets and its large volume of traffic.

For CTCs, two parties may be unable to reveal the correct message due to network instability, delays, or an obstructing firewall. CSCs do not have such problems and are difficult to detect. The data is “legitimate” and the involved parties are authorized. An intrusion detection system (IDS) faces challenges to distinguish CSC packets from legitimate traffic.

Moreover, accomplices may develop transmission mechanisms for stealthier covert channels. One way to achieve this is by splitting a message through multiple paths established between two communication parties. This dilution effect can reduce the signal to noise ratio of a CSC. Requiring higher processing overhead at both ends, comes at the cost of using less bandwidth of a single communication path for slower transmission. However, this may be desirable to certain CSC use cases, such as a command and control channel that is critical to an operational botnet. Such stealthier CSCs pose new challenges to their detection and analysis.

In this study we consider the detection of one type of CSC that uses the TCP Flag field of network packets. Specifically, we consider the above stealth technique of dividing the message in multiple communication paths to further hide such a CSC. To develop a countermeasure, we introduce a collaborative CSC detection design supported by a recent networking technology, Software-Defined Networking (SDN). SDN separates the control plane from the data plane while providing flexible access to useful network topology information. It enables distributed agents that monitor and correlate network traffic data, and helps mitigate CSC threats by reconfiguring the network. Lastly, we implement this stealthy CSC and the countermeasure to detect it on GENI (Global Environment for Network Innovations), a network testbed that supports SDN. A few preliminary experiment results are presented at the end of the paper.

2. RELATED LITERATURE In this section we first review a few related efforts of constructing CSCs. We also give a brief introduction of SDN, a new networking technique utilized in our proposition for CSC analysis, and GENI, the testbed environment for our experimentation.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. National Cyber Summit’16, June 7–9, 2016,Huntsville, Alabama, USA. Copyright 2010 ACM 1-58113-000-0/00/0010 …$15.00.

2.1 Covert Storage Channel (CSC) Recent interests on covert information channels have risen from both sides of information security. Researchers focus on methods to construct more reliable CSC channels for the need of privacy protection of communication parties. Conspirators, on the other hand, seek advanced steganographic tools for the purposes of data exfiltration and command and control. Consequently, defenders are striving for capabilities of efficient CSC characterization and detection. This research falls into the latter category.

In [2] the authors defined two types of covert channels: timing IP simple covert channels (SCC) and storage IP SCC in both noiseless and noisy traffics. Their test results showed that an IP covert channel could be differentiated from legitimate channels for a detection rate of over 95%. They only used ten IP header traces, a very small portion of a 200GB data set collected at the New Zealand Internet Exchange. For the SCC implementation, only one bit in each packet header was used, which would be very inefficient for two parties to talk to each other.

In a dissertation [1], Ahsan proposed several possible convert channels embedded in different fields at transport and network protocol layers. Network protocols, such as TCP and ICMP, are ideal for building a covert channel. This study listed methods to implement covert channels within protocols including packet sorting and rearranging techniques, but lacking practical implementation of the covert channels and evaluation. Gianvecchio and Wang introduced an entropy-based approach to differentiate covert traffic from legitimate traffic for different types of covert timing channels [3]. Their results showed that this measure is sensitive to recent CTCs, including IPCTC, TRCTC, and JitterBug, and capable to detect them. The authors did not specify the portion of CTC traffic mixed in the test samples and did not try it on CSC traffic, thus it is unclear how realistic and general their approach would be.

Additionally, in a related study of detecting anomalies in network traffic, Bayarjargal and Cho discussed measuring TCP Flags distributions based on Shannon’s entropy [4]. They proposed a methodology to detect anomalies that can identify DDoS attack traffic by the use of Mahalanobis distance for comparisons to pre-computed traffic profiles. Their testing results showed high detection accuracy and efficiency.

These studies provide us with the techniques to build up CSCs as well as the measures that we can employ to detect the existence of such CSCs. In the next we will discuss one specific CSC. But our focus will be on a stealth technique to make such a CSC more difficulty to detect, and then, a countermeasure based on SDN.

2.2 A CSC Using TCP Flags In our study, a covert channel uses the TCP Flag (TF) header field in a network packet, a six-bit field used to set up a TCP connection. For two accomplices, Bob can use ‘000010’ to say “start”, and Alice replies Bob with ‘010000’ to represent “confirmed.” Then Bob and Alice start exchanging messages based on a pre-agreed coding scheme, such as in Figure 1. (These specific TF values are used only for illustration purpose.) If other people were eavesdropping the communication, they would not be able to recover the messages because packets between Bob and Alice do not look different from other network sessions.

In the real world, such a CSC has two potential use cases with different goals. In the first case, utilizing the bandwidth available to transmit information using a CSC is of high priority. For example, during data exfiltration following hacking into a

proprietary system, valuable data may be transmitted out through this channel with the hope to remain undetected. The goal of the attackers is to leak out as much information as possible in a short period of time before the breach is found and patched. However, using just six bits in every packet such a CSC channel may not be ideal. The second case of using this type of CSC aims at stealthy, unsuspected communication. A likely use is sending out one or several critical messages in a botnet or spy network. The bandwidth is not the foremost concern, but every effort will be taken to prevent these messages from being revealed and cracked. We will consider one general technique to achieve stealthier communication for this scenario.

Figure 1. A covert storage channel embedded in TCP Flags

Considering a large computer network, two computer users usually are able to establish communication connections through multiple paths, as shown in Figure 2. They may use these paths in different connection sessions. Or, if desired, more than one network paths can even be used in one communication session by designating selective routing preferences. This provides a natural way to further reduce the footprint of CSC by simply breaking one message into multiple pieces and choosing different paths to send out these pieces. Then these pieces are assembled together at the receiver. We call this communication using multiple network paths a split-join (S-J) network. We call these two communication parties a candidate pair for CSC accomplices.

Figure 2. Communication paths between Alice and Bob

The effect of splitting this message can be explained by a phenomenon of the change of signal to noise ratio, 𝑆𝑁𝑅 =!(!"#$%&)!(!"#$%)

of the aggregate traffic over a path. Signal is the CSC traffic and noise the normal traffic. P is the power measure, such as the intensity of corresponding network packets of each type of traffic. The higher the SNR is, the better the ability to detect this signal buried in the background noise. However, if a CSC message is split into D equal pieces, then 𝑆𝑁𝑅 = !(!"#$%&)

!(!"#$%) × !

!

over an individual path, which can be significantly lower. In this way, the CSC becomes stealthier to detectors.

Accomplices probably can split a message into as many pieces as possible to maximize such effect. However, doing so incurs additional overhead to their communication. The overhead is due to the underutilization of available bandwidth of individual communication links and more complex coding/decoding schemes that both accomplices, Alice and Bob, have to conduct. The former slows down the communication. The latter requires special markings most likely at the application level, which waste the CSC bandwidth and increase the risk of this CSC to be detected due to the existence of such unusual packet payload.

In our first study of this stealth technique and its countermeasures, we make a few assumptions to simplify the scenario:

(1) Realistically it is not possible to collect all the CSC packets at one single location in such a S-J network. This is simply because we do not know in advance where the accomplices are. It would be interesting to study strategies to optimally and/or dynamically position detection components in our future study.

(2) Only two communication paths are used and the CSC message is equally split. This can be extended to cases of more paths and unequal splits in future, which will open new research topics of finding the equilibrium points for the countermeasure to be able to be effective.

(3) The CSC message pieces will flow through the S-J network at the same time. We further assume that the sensory elements deployed in our approach maintain accurately synchronized clocks. Again more complex situations regarding synchronization will create new research topics in our future study.

2.3 Software Defined Networking (SDN) Software-defined networking (SDN) is a latest development to enable highly programmable networks. It allows service providers to customize, reconfigure and optimize physical network components, such as physical switches, dynamically and without the need to manually change the underlying physical infrastructure. Simplified networking is supported through an abstraction of underlying infrastructure and programming API between the control plane and the data plane, including OpenFlow [5]. It allows experimenters to easily develop their own routing and switching rules.

Recently a few efforts have been invested in utilizing SDN for security services. Chin et al. proposed a novel attack detection approach by introducing collaborative attack detection and containment [6]. Deploying distributed monitors and correlators, this scheme is able to quickly respond to a DDoS attack with improved accuracy. In comparison, our research adds additional elements, i.e., monitor managers and correlator managers, and thus new coordination and analysis functionality.

Song experimented an SDN-supported CSC detection approach and on Mininet, an SDN simulator [7]. A detection model using multiple stages to coordinator monitors and correlators was introduced with promising evaluation results. Different from this work, in this research we will use GENI as an emulation testbed. Moreover, Song’s work focused on differentiating use of invalid protocol header values, an easier task. Our detection aims to detect CSC channels even if they use valid TF values, which is a more realistic scenario. And we further take advantage of flow

forwarding information readily available made by SDN in our countermeasures against a CSC S-J network.

2.4 Global Environment for Network Innovations (GENI) GENI is a cloud infrastructure built for large-scale networking emulation experiments [8]. Experimenters can decide which type of computing resources they use, and request different types of disk images. GENI provided the API to popular testbed resources including emulab, cloudlab, and planetlab. The implementation of SDN is enabled in GENI by its support of OpenFlow. For example, POX controller and Open vSwitch (OVS) have been included as part of the resource reservation [9]. In our research, we make full use of the OpenFlow API to enable traffic duplication and flow correlation.

GENI creates deeply programmable experiment slices on demand. Slices are based on resource isolation in cloud computing, so multiple experiments are able to use the same physical infrastructure at the same time. On GENI the experimenters not only can install their own software on each network node, but also can run their own routing algorithms on their own network infrastructure. Deep programmability is further strengthened by the SDN concept.

3. COLLABORATIVE DETECTION To reveal the existence of a CSC we need to detect the irregularity in the use of TF in comparison to normal traffic. Moreover, our approach will deploy several elements that measure traffics in individual paths and for individual flows of communication parties. Some of these elements run constantly while others are activated as needed.

3.1 Dissimilarity Calculation We characterize the use of the 64 possible TF combinations in the frequency space during a time interval, Δt, in network packet traffic. So first we count the number of network packets bearing each different TF combination value in the chosen time window. A vector of 64 flag count values represents one such observation of network packet traffic during Δt. There are many choices of calculating the deviation (or irregularity) of one observation from a normal baseline represented by a distribution of such frequencies. We choose to use the very commonly deployed Mahalanobis distance [9]. The distance between one observation 𝑥 = (𝑥!, 𝑥!,… 𝑥!")! and a set of observations with mean µ and covariance matrix S is 𝐷 𝑥 = 𝑥 − 𝜇 !𝑆!!(𝑥 − 𝜇). The mean µ and the covariance matrix S represent the normal TF usage profile of legitimate traffic, built from real regular traffic trace collections.

3.2 A Collaborative and Multi-Step Working Mechanism Our mechanism is built for an enterprise network of multiple OVSs. The basic collaborating components are the Monitor, the Correlator, the Monitor Manager (MM) and the Correlator Manager (CM). We assign a Monitor and a Correlator to each OVS as seen in Figure 3. As the first step, monitoring the aggregate traffic through an OVS, the Monitor acts as an anomaly detector that raises an alert if CSC traffic is suspected. In the next step, triggered by the alert, the Correlator operates on demand to correlate information and analyze individual flows. The Monitors and Correlators communicate with a single, centralized Monitor Manager (MM) and a Correlator Manager (CM) respectively.

Figure 3. Multi-step collaborative detection technique

Figure 3 shows a logical diagram and steps of the multi-step collaborative mechanism and communication scheme used to detect CSC communication. The individual monitors M1 – Mn continuously observe the network traffic for irregularities (S1). The irregularities are detected by first calculating the TF frequencies of aggregated, real-time traffic, then comparing these frequencies using the Mahalanobis distance to a normal traffic profile created using a set of training data (more details in Section 4.3). If a Monitor Mi detects irregularities, that is the distance of the TF frequency is higher than a specific threshold, Mi sends an alert to Ci (S2). The Correlators, C1 – Cn, become active (S3) if they receive such an alert. They then calculate the TF frequency per information flow, to further examine the packets exchanged between every pair of IP addresses. In this case, we use the special feature of SDN that allows us to easily retrieve the information of installed local flows by dumping and examining the OVS flow table using the OpenFlow API. The SDN controller, which is hosted with the Correlator, performs this operation.

However, to counter the stealth technique previously described and employed for a CSC, flow information must be reassembled to recover the signal intensity of a CSC if the accomplices, Alice and Bob, communicate through multiple paths using both OVSs. Fortunately, such knowledge is readily made available by SDN in the flow forwarding tables maintained by the two OVSs.

Therefore, if a candidate pair of two IP addresses establishes communication using multiple paths, the Monitor sends reports of the TF counts of all the packets as well as the subset of packets exchanged by each candidate pair through each OVS involved to the Monitor Manager (MM). MM is located at the intersection of multiple paths of the enterprise network. It has the information needed to reassemble the TF frequencies for each path (S5), as if Bob and Alice exchange the whole message through that path. MM then calculates the Mahalanobis distance for each OVS again, but taking in consideration the packets between Alice and Bob through other paths. The MM sends an alert to the Correlator Manager (CM) if there is a threshold violation (S6). Triggered by an alert, the CM also activates all involved individual correlators for dissimilarity calculations for each flow. In addition, the Correlators send reports of TF counts for Alice and Bob (actually, for every candidate pair) to the CM (S4_1 and S4_2 in Figure 3). With these individual reports, the CM correlates the TF frequencies from multiple traffic flows belonging to the same candidate pair, e.g., Alice and Bob. Thus, it is able to put together all the related packets to calculate the traffic dissimilarity (S7) in order to detect irregularity in the

communication of a candidate pair, even though now this pair uses multiple communication paths at the same time.

At last, the Correlator (or the CM) identifies the accomplices to be the two parties (IP addresses/computer nodes) for a specific flow where the CSC is embedded. Naturally, if needed, mitigation actions can be taken by the SDN controller to block the flow or redirect it for further analysis.

3.3 Monitor and Correlator Currently a single Monitor and Correlator are connected to each individual OVS. Depending on the network topology and performance requirements, however, a more flexible configuration of these components, e.g., multiple Monitors and Correlators per OVS, can be introduced in future research.

The Monitor receives all the packets that go through the OVS using SDN rules of traffic duplication. The role of the Monitor is twofold: (i) calculate the TF frequencies for aggregate traffic in a chosen time window Δt, e.g., every 5 seconds, and (ii) compare these frequencies to the regular traffic profile of TF frequencies using the Mahalanobis distance to raise an alert if the distance exceeds a certain threshold, and send it to the Correlator.

Moreover, if the communication used by a candidate pair include this OVS, according to prior negotiation and configuration, the monitor sends to the Monitor Manager a report that contains the TF counts of both the aggregate traffic and the subset of packets belonging to this candidate pair in the used time window.

A Correlator is hosted with an OVS Controller. The Correlator remains idle until a Monitor alert triggers its operation. The Correlator uses information of IP address pairs, which is available in the flow table of the OVS. Each pair of IP addresses, just like Alice and Bob, represents one information flow. The SDN Controller finds this information by querying the OVS with the OpenFlow API. The Correlator calculates the per flow TF frequencies and the corresponding Mahalanobis dissimilarity. It has the capability to uncover the flow whose traffic pattern significantly deviates from the normal traffic profile. The participating parties are likely the CSC accomplices.

Moreover, if requested, the Correlator forwards the TF counts belonging to a candidate pair to the CM. Receiving an alert from the MM, the CM then completes the second step of correlation.

3.4 Monitor Manager and Correlator Manager In similar steps the MM and CM perform additional functions of traffic irregularity detection and flow correlation analysis against the stealth technique that employs an S-J communication network. These two managers have knowledge of the multi-path communication of candidate pairs, since they are connected to both OVSs. Individual monitors are requested to report the TF counts of the traffic on different OVS to the MM.

The MM reassembles the TF counts for an OVS using the following formula: 𝑐(𝐴)!"#! = 𝑐!"#! + 𝑐!"!

!"#!!!!! , where

𝑐(𝐴)!"#! is the assembled count of one specific TF value (e.g., ‘000000’) after being put together for OVS j, 𝑐!"#! is the reported count of that TF value for the aggregate traffic on OVS j, and 𝑐!"!!"#! is its count reported for a candidate pair k on OVS i.

Extracted from network packets in the same time interval, these TF counts are from observations on different OVSs. Therefore, after reassembly these TF counts for every OVS contain the complete information of potential CSCs associated with candidate pairs. The CSC signal strength is brought back to that of the

original message in the TF frequencies for each path. Then the MM can calculate the Mahalanobis dissimilarity for each OVS and raise alerts as appropriate.

Receiving an alert from the MM, the CM conducts per flow correlation calculation for all the candidate pairs similar to the calculation on a Correlator. It needs to first reassemble the TF counts as: 𝑐!"! = 𝑐!"!

!"#!! , where 𝑐!"! is the count of one specific

TF value assembled together for a candidate pair k. Then dividing with the total packet count for a candidate pair k can easily derive the frequency of TF flags. Calculating the Mahalanobis dissimilarity from the normal traffic profile, the CM identifies the culprit candidate pair for their associated IP addresses.

4. IMPLEMENTATION ON GENI We have used the GENI infrastructure to create a realistic implementation of our collaborative detection of stealthy CSCs using SDN. We have deployed a small enterprise network topology, generated regular traffic based on real traces and covert traffic, and finally implemented scripts for TF frequency calculations, Mahalanobis distance calculations, and communication between hosts.

4.1 Topology and Architecture Figure 4 shows the logical diagram of the topology that was used for our experimentation. We considered a subset of an enterprise network with two sub-networks connected by a backbone OVS. Each LAN includes an OVS and its corresponding Monitor and Correlator. The MM and CM are connected to the backbone OVS to have a full view of the multi-path flows.

Figure 4. Experimentation topology on GENI where there are

two OVSs (Open Virtual Switch) The two accomplices, Alice and Bob, are connected to both OVS1 and OVS2, thus they have two paths available used to split their CSC messages. Furthermore, we have added several regular hosts, connected to the two switches to generate the normal traffic that is mixed with CSC packets at each OVS.

4.2 Traffic Generation We have used real traffic collected in the CAIDA dataset [10]. This dataset includes regular Internet traces that have been measured during different times of the day on specific routers. We used two distinct traces that have approximately 200 flows (IP pairs) at around 270K packets per second (pps). The traffic is slowed down to about 200 pps using a traffic generator, tmix [11]. We have therefore preserved the multiplicity of the flows to

emulate a realistic environment. The two traces, trace1 and trace2, are replayed through the two OVS switches respectively, with no overlap of IP addresses between them. We have created the CSC traffic with a randomized mapping that uses 26 TFs corresponding the English letters. We then sent CSC packets by randomly selecting flags according to the English alphabet frequency distribution. This way the CSC traffic is sufficiently randomized and unpredictable, but it also follows an alphabet as if transmitting regular messages in English. We used the tool hping3 to send these packets between Alice and Bob, and we divided the CSC traffic equally through two different paths (by OVS1 and OVS2) for more stealthy communication.

4.3 Experiment Design The goals of our experimentation are: (i) create stealthy, multi-path CSC communication between Alice and Bob, interleaved with regular traffic that pass through each OVS; (ii) demonstrate the robustness or our collaborative detection method by using realistic regular traffic data; and (iii) measure its performance in repeatable experiments.

To this end, we have created a normal traffic profile based on real world datasets. Following classical machine learning techniques, we divided our CAIDA traces, trace1 and trace2, into two halves. The first half was used for training to calculate the mean and covariance matrix of TF frequencies in normal traffic and the second half for testing. To do this, the training halves were discretized by dividing them into 5-second segments, generating 100 segments in total. The TF frequencies summarized from these samples generated 100 observations. We calculated the mean vector µ and then the 64x64 covariance matrix S for the 64 possible TFs, where an element 𝑠!" = 𝐸[(𝑓! − 𝐸[𝑓!])(𝑓! − 𝐸[𝑓!])] indicates the covariance for TFs i, j with frequencies fi and fj.

Anomaly detection using the Mahalanobis dissimilarity modeling can follow a built-in threshold setting mechanism based on its covariance structure, similar to choosing a threshold at 2 or 3 standard deviations for a univariate variable. We used a simplified way to set the threshold up. We can calculate the Mahalanobis distances of TF frequency observations of the second halves of trace1 and trace2 for the above µ and S. The distance for these normal observations is in the range of [0.0945, 0.120]. So we first set the detection threshold at 0.12 and later varied it to see which threshold works the best.

To support the functions of MM and CM we have developed a method to synchronize the information from the Monitor and the Correlator. The simple information message contains timestamp, TF value, as well as IP addresses. Such information is first sorted by the timestamp, and then assembled according to the requirements described before at the MM and CM.

5. EXPERIMENTATION RESULTS 5.1 Sensitivity Performance We evaluated the performance of the multi-step detection mechanism by repeatable experiments. In the first set of experiments, we wanted to demonstrate the sensitivity of detecting CSC traffic out of normal traffic using our method. The rate of normal traffic was 200 pps in these experiments. At the same time, we injected CSC traffic of an intensity that varies from 1% - 15% of that of the regular traffic. This CSC traffic was split between the two OVSs for Alice and Bob. Therefore, each OVS and the corresponding monitor received 0.5% - 7.5% of CSC traffic. We repeated each experiment 40 times.

Figure 5. Monitor and Monitor Manager false negative rate

vs. increasing the CSC traffic percentage Figure 5 shows the resulting false negative rate of CSC detection with the detection threshold set at 0.12. The false negative rate is almost 90%-100% for individual monitors until the intensity ratio of CSC traffic to normal traffic increases to 7%. Then it drops dramatically. For 10% or more CSC traffic there is no significant improvement. The promising result is that the MM, with the knowledge of multiple paths and the calculations that use TF counts from both Monitors, shows dramatic drop of the false positive rate for CSC traffic with a packet rate higher than 5% of that of the normal traffic, which is cut in half through each individual path. It is clear that overall the detection rate of the MM is better compared to the individual Monitors.

5.2 Accuracy To measure the accuracy of the detection based on the Mahalanobis distance, a Receiver Operating Characteristic (ROC) curve for the Monitor is plotted for various detection thresholds, as shown in Figure 6.

Figure 6. Receiver Operating Characteristic (ROC) for

Monitor

The CSC to normal traffic intensity ratio is fixed at 10%. Each point is from 40 experiments. The detection thresholds are at 0.08, 0.09, 0.10, 0.105, 0.11, 0.12, 0.13, 0.14 and 0.15 respectively, as seen on the labels of data points. From this Figure we can conclude that when the most efficient threshold is set at 0.105, we

maximize the rate of detection at approximately 80% while minimize the false positive rate (less than 20%). If the threshold decreases further, there is a dramatic increase in false positive rate without a considerable increase in the detection rate.

In our preliminary experimentation, no regular traffic was sent between the accomplices, Alice and Bob, so we could not measure the false positives for the MM or CM. In our future efforts we plan to do more extensive performance testing and focus on characterizing individual flows.

6. CONCLUSIONS This paper presents preliminary results of a collaborative approach helped by SDN to analyze CSCs that employ multiple network paths to send out a message. In our future study we will continue to fine-tune the proposed solutions in more realistic experiments.

7. ACKNOWLEDGMENTS This work receives partial support from NSF through Award DUE-1525485 and Award DUE-1600060.

8. REFERENCES [1] K. Ahsan, Covert channel analysis and data hiding in

TCP/IP, Dissertation, University of Toronto, 2002.

[2] S. Cabuk, C. E.Brodley, & C. Shields, IP covert channel detection, ACM Transactions on Information and System Security (TISSEC), 12(4), 2009.

[3] S. Gianvecchio & H. Wang, Detecting covert timing channels: an entropy based approach, In Proceedings of the 14th ACM conference on Computer and communications security, pp. 307 – 316, October 2007

[4] D. Bayarjargal & G. Cho, Detecting an Anomalous Traffic Attack Area based on Entropy Distribution and Mahalanobis Distance, International Journal of Security and Its Applications, 8(2), pp. 87-94, 2004.

[5] Openflow, http://archive.openflow.org/wp/learnmore/.

[6] T. Chin, X. Mountrouidou, X. Li, & K. Xiong, An SDN-supported collaborative approach for DDoS flooding detection and containment, IEEE Military Communications Conference (MILCOM 2015), October 2015.

[7] H. Song & X. Li, SDN-Supported Covert Storage Channel Detection, Capstone Report, Johns Hopkins University, 2014.

[8] M. Berman, J. S. Chase, L. Landweber, A. Nakao, M. Ott, D. Raychaud- huri, R. Ricci, & I. Seskar, GENI: A federated testbed for innovative network experiments, Computer Networks, vol. 61, pp. 5–23, 2014

[9] P. C. Mahalanobis, On the generalized distance in statistics, Proceedings of the National Institute of Sciences of India 2 (1): 49–55, 1936.

[10] CAIDA Data, http://www.caida.org/data/overview/. [11] TMix on GENI, http://geni.web.unc.edu/tmix