2018 IEEE Symposium on Security and Privacy Workshops

Machine Learning DDoS Detection for Consumer Internet of Things Devices

Rohan Doshi Noah Apthorpe Nick Feamster

Department of Computer Science Department of Computer Science Department of Computer Science
Princeton University Princeton University Princeton University
Princeton, New Jersey, USA Princeton, New Jersey, USA Princeton, New Jersey, USA
[email protected] [email protected] [email protected]

Abstract—An increasing number of Internet of Things (IoT) neer ML models with features specifically geared towards
devices are connecting to the Internet, yet many of these devices IoT device networks or IoT attack traffic. Fortunately, how-
are fundamentally insecure, exposing the Internet to a variety ever, IoT traffic is often distinct from that of other Internet
of attacks. Botnets such as Mirai have used insecure consumer
IoT devices to conduct distributed denial of service (DDoS) connected devices (e.g. laptops and smart phones) [7]. For
attacks on critical Internet infrastructure. This motivates example, IoT devices often communicate with a small finite
the development of new techniques to automatically detect set of endpoints rather than a large variety of web servers.
consumer IoT attack traffic. In this paper, we demonstrate IoT devices are also more likely to have repetitive network
that using IoT-specific network behaviors (e.g., limited number traffic patterns, such as regular network pings with small
of endpoints and regular time intervals between packets) to
inform feature selection can result in high accuracy DDoS de- packets at fixed time intervals for logging purposes.
tection in IoT network traffic with a variety of machine learning
algorithms, including neural networks. These results indicate Building on this observation, we develop a machine learn-
that home gateway routers or other network middleboxes could ing pipeline that performs data collection, feature extraction,
automatically detect local IoT device sources of DDoS attacks and binary classification for IoT traffic DDoS detection. The
using low-cost machine learning algorithms and traffic data features are designed to capitalize on IoT-specific network
that is flow-based and protocol-agnostic. behaviors, while also leveraging network flow characteristics
Keywords-Internet of Things; Anomaly Detection; DDoS; such as packet length, inter-packet intervals, and protocol.
Machine Learning; Feature Engineering We compare a variety of classifiers for attack detection, in-
cluding random forests, K-nearest neighbors, support vector
I. I NTRODUCTION machines, decision trees, and neural networks.
The number of Internet of Things (IoT) devices is pro- Given the lack of public datasets of consumer IoT attack
jected to grow from 8 billion in 2017 to 20 billion in 2020 traffic, we generate classifier training data by simulating a
[1]. Yet, many of these IoT devices are fundamentally inse- consumer IoT device network. We set up a local network
cure. One analysis of 10 currently popular IoT devices found comprised of a router, some popular consumer IoT devices
250 vulnerabilities, including open telnet ports, outdated for benign traffic, and some adversarial devices performing
Linux firmware, and unencrypted transmission of sensitive DoS attacks. Our classifiers successfully identify attack
data [2], [3]. traffic with an accuracy higher than 0.999. We found that
The proliferation of insecure IoT devices has resulted random forest, K-nearest neighbors, and neural net classifiers
in a surge of IoT botnet attacks on Internet infrastructure. were particularly effective. We expect that deep learning
In October 2016, the Mirai botnet commanded 100,000 classifiers will continue to be effective with additional data
IoT devices (primarily CCTV cameras) to conduct a dis- from real-world deployments.
tributed denial of service (DDoS) attack against Dyn DNS
infrastructure [4]. Many popular websites, including Github, Our pipeline is designed to operate on network mid-
Amazon, Netflix, Twitter, CNN, and Paypal, were rendered dleboxes (e.g. routers, firewalls, or network switches) to
inaccessible for several hours. In January 2017, the Mirai identify anomalous traffic and corresponding devices that
source code was publicly released; DDoS attacks using may be part of an ongoing botnet. The pipeline is flow-
Mirai-derived IoT botnets have since increased in frequency based, stateless, and protocol-agnostic; therefore, it is well
and severity [5]. suited for deployment on consumer home gateway routers
This growing threat motivates the development of new or ISP-controlled switches. To our knowledge, this is the
techniques to identify and block attack traffic from IoT first network anomaly detection framework to focus on IoT-
botnets. Recent anomaly detection research has shown the specific features, as well as the first to apply anomaly
promise of machine learning (ML) for identifying malicious detection specifically to IoT botnets at the local network
Internet traffic [6]. Yet, little effort has been made to engi- level.

© 2018, Rohan Doshi. Under license to IEEE. 29

DOI 10.1109/SPW.2018.00013
 II. BACKGROUND AND R ELATED W ORK suggestions for how to meet these constraints. For example,
In this section, we present a brief background on network Sivanathan et al. investigated the use of software defined
anomaly detection and middlebox limitations. networks to monitor network traffic at flow-level granular-
ity [15]. Their work suggests that using flow-based features
A. Network Anomaly Detection can be effective in detecting security threats without incur-
Anomaly detection aims to identify patterns in data that ring the high cost of deep-packet inspection. An anomaly
do not conform to expected behavior. In the context of our detection framework for a consumer smart home gateway
work, anomaly detection techniques may be used to discern router should therefore have the following characteristics:
attack traffic from regular traffic. Simple threshold-based • Lightweight Features. Routers must handle high band-
techniques are prone to incorrectly classifying normal traffic width traffic, so any features generated must be
as anomalous traffic and are unable to adapt to the evolving lightweight [16]. In order for an algorithm to scale
nature of attacks [6]. More sophisticated anomaly detection to high bandwidth application, a given algorithm must
algorithms, particularly those using machine learning, can rely on network flow statistics (how packets are sent) as
help minimize false positives. Such approaches include deep opposed to deep packet inspection (what is in a packet).
neural networks, which promise to outperform traditional • Protocol Agnostic Features. Routers must process pack-
machine learning techniques for sufficiently large datasets. ets from a variety of protocols (e.g. TCP, UDP, HTTP,
Anomaly detection has long been used in network in- etc.), so the algorithm must consider packet features
trusion detection systems (NIDS) for detecting unwanted shared by all protocols.
behavior in non-IoT networks. The NIDS literature can • Low Memory Implementation. Routers are only able
therefore inform the choice of anomaly detection methods to maintain limited state due to memory constraints;
for IoT networks. In particular, the literature suggests near- caching adds latency and complexity. Thus, an optimal
est neighbor classifiers [8], support vector machines [9], algorithm is either stateless or requires storing flow
and rule-based schemes like decision trees and random information over short time windows only [15].
forests [10], [11] as promising approaches.
Although there are parallels between NIDS and IoT III. T HREAT M ODEL
botnet detection, there has been little work tailoring anomaly Our threat model (Fig. 1a) makes various assumptions
detection specifically for IoT networks. Our underlying about consumer IoT networks. We assume the network
hypothesis is that IoT traffic is different from other types includes an on-path device, such as a home gateway router or
of network behavior. For example, while laptops and smart other middlebox, that can observe traffic between consumer
phones access a large number of web endpoints due to web IoT devices on the local network (e.g. a smart home LAN)
browsing activity, IoT devices tend to send automated pings and the rest of the Internet. The device at this observation
to a finite number of endpoints. IoT devices also tend to point can inspect, store, manipulate, and block any network
have a fixed number of states, so their network activity is traffic that crosses its path. All traffic between WiFi devices
more predictable and structured. For instance, a smart light on the LAN or from devices to the Internet traverses this
bulb could have three states: ”On,” ”Off”, and ”Connecting middlebox.
to Wi-Fi,” each with distinctive network traffic patterns. Our goal is to detect and prevent DoS attack traffic
This hypothesis is supported by the literature. Apthorpe et originating from devices within the smart home LAN. The
al. demonstrate how the finite states of consumer IoT devices DoS victim may be another device on the LAN or elsewhere
can actually be reflected in the repeated temporal structures on the Internet. Any device connected to the middlebox
of send/receive traffic rates; this can even be used to in- can send both network and attack traffic within the same
fer consumer usage behaviors [7]. Similarly, the SCADA time period. Each device is also capable of conducting a
anomaly detection literature notes the unique network traffic variety of different DoS attacks in series, and successive
patterns of sensors and controllers in infrastructure systems attacks can vary in duration. This reflects how a remote
[12], [13]. Miettinen et al. further show how machine botnet command and control (C&C) may change orders. We
learning techniques can leverage the unique patterns of IoT assume that the time range of DoS attacks are roughly 1.5
network traffic for similar tasks, such as device identification minutes, a common duration for DoS attacks attempting to
[14]. Therefore, we use network traffic features that capture avoid detection [5].
IoT-specific behaviors to better model IoT DoS attack traffic
IV. A NOMALY D ETECTION P IPELINE
for anomaly detection.
In this section, we present a machine learning DDoS
B. Network Middlebox Limitations detection framework for IoT network traffic. Our anomaly
Network middleboxes have limited memory and process- detection pipeline has four steps (Fig. 2):
ing power, imposing constraints on the algorithmic tech- 1) Traffic Capture. The traffic capture process records the
niques used for anomaly detection. The literature contains source IP address, source port, destination IP address,

30
 fic (Fig. 1b). We configured a Raspberry Pi v3 as a WiFi
access point to act as a middlebox. We then connected a YI
Home Camera [17] and Belkin WeMo Smart Switch [18] to
the Raspberry Pi’s WiFi network. A Withings Blood Pressure
Monitor was also connected by Bluetooth to an Android
smartphone associated with the WiFi network [19].
To collect normal (non-DoS) traffic, we interacted with
all three IoT devices for 10 minutes and recorded pcap
files, logging all packets sent during that time period. We
performed many interactions that would occur during regular
device use, including streaming video from the YI camera to
the server in HD and RD modes, turning the WeMo Smart
Switch on/off and installing firmware updates, collecting
(a) Threat model blood pressure measurements from the Withing’s Blood
Pressure monitor, and sending the measurements to a cloud
server for storage. We then filtered out all non-IoT traffic
from the pcap recordings, including background traffic
from the Android phone.
Collecting DoS traffic was more challenging. To avoid
the security risks and complexity of running the real Mirai
botnet code, we simulated the three most common classes
of DoS attacks a Mirai-infected device will run: a TCP SYN
flood, a UDP flood, and a HTTP GET flood [5]. We used
a Kali Linux virtual machine running on a laptop as the
DoS source, and a Raspberry Pi 2 running an Apache Web
Server as the DoS victim. We connected both devices via
WiFi to our Raspberry Pi 3 access point. The DoS source
(b) Experiment setup then targeted the victim’s IP address with each class of
Figure 1: Consumer IoT network threat model and corre- DoS attack for approximately 1.5 minutes each. The access
sponding experiment setup for collecting normal and DoS point recorded PCAPs of the attack traffic using the Linux
attack traffic training data. dumpcap tool. The HTTP GET Flood was simulated using
the Goldeneye tool [20]. The TCP SYN Flood and UDP
destination port, packet size, and timestamp of all IP
Flood were simulated using Kali Linux’s hping3 utility [21].
packets sent from smart home devices.
We then combined the DoS traffic with the normal traffic,
2) Grouping of Packets by Device and Time. Packets from
spoofing source IP addresses, MAC addresses, and packet
each IoT device are separated by source IP address.
send times to make it appear as if the IoT devices si-
Packets from each device are further divided into non-
multaneously produced normal traffic and conducted DoS
overlapping time windows by timestamps recorded at
attacks. Each of the three IoT-devices appeared to execute
the middlebox.
each of the three DoS attack classes once within a 10
3) Feature Extraction. Stateless and stateful features are
minute internal. The attacks occurred in a random order for a
generated for each packet based on domain knowledge
random duration ranging uniformly from 90 to 110 seconds
of IoT device behavior. The stateless features are
each. Thus, we collected roughly 300 seconds (5 minutes) of
predominantly packet header fields, while the stateful
attack traffic per device. The distribution of attacks between
features are aggregate flow information over very short
devices was independent.
time windows, requiring limited memory to support
This process produced a dataset of 491,855 packets,
on-router deployment. (Section IV-B).
comprised of 459,565 malicious packets and 32,290 benign
4) Binary Classification. K-nearest neighbors, random
packets.
forests, decision trees, support vector machines, and
deep neural networks can differentiate normal traffic B. Feature Engineering
from DoS attack traffic with high accuracy (Sec-
We explore two classes of features and analyze why they
tion V-A).
are relevant to differentiating normal and attack IoT traffic.
A. Traffic Collection Stateless features can be derived from flow-independent
We set up a experimental consumer IoT device network characteristics of individual packets. These features are
to collect realistic benign and malicious IoT device traf- generated without splitting the incoming traffic stream by

31
 Figure 2: IoT DDoS detection pipeline.

IP source. Thus, these features are the most lightweight. in total. We capture protocol differences in a feature with
Stateful features capture how network traffic evolves over a one-hot encoding of the three most popular attack proto-
time. There is inherent overhead in generating these features, cols (IS TCP, IS UDP, and IS HTTP) and another binary
as we split the network traffic into streams by device indicator to reflect all other types of protocols (IS OTHER).
and divide the per-device streams into time windows. The This captures the most popular protocols while minimizing
time windows serve as a simple time-series representation noise and unnecessary dimensionality associated with less
of the devices’ evolving network behavior. These features relevant protocols.
require aggregating statistics over multiple packets in a time
window; the middlebox performing classification must retain 2) Stateful Features:
state, but the amount of state can be limited by using short Bandwidth: The literature contains evidence that
(e.g. 10-second) time windows. bandwidth usage can be used to characterize network traffic
patterns of IoT devices. For example, Apthorpe et al. were
1) Stateless Features: able to characterize consumer IoT device usage patterns
Packet Size: The distribution of packet sizes differs from send/receive rates, but dividing network traffic by
significantly between attack and normal traffic (Fig. 3a). source device was necessary for the analysis [7]. Similarly,
Over 90% of attack packets are under 100 bytes, while our pipeline splits network traffic by source device and
normal packets vary between 100 and 1,200 bytes. A device calculates the average bandwidth within 10-second time
conducting a DoS attack, such as a TCP SYN Flood, is windows to measure the instantaneous bandwidth associated
trying to open as many connection request as possible with with each device. There are minor distributional differences
the victim to exhaust the victim server’s resources. Thus, in bandwidth usage between the normal and attack traffic
an attacker wants to keep the size of the packets as small (Fig. 3g). We predict that a ML model will be able to
as possible in order to maximize the number of connection leverage these differences.
requests per second. In comparison, normal traffic can range IP Destination Address Cardinality and Novelty:
from simple server pings indicating that the device is active IoT devices are characterized by the limited number of
(small packets) to video streaming data (large packets). endpoints with which they communicate [7]. For example, a
Inter-packet Interval: Normal IoT traffic has limited WeMo smart switch communicates with only four endpoints
burstiness (Fig. 3b-d). Most packets are sent at regular inter- for the purposes of activation/deactivation from the cloud,
vals with appreciable time between packets. This may reflect retrieving firmware updates, and logging its status. Another
IoT network pings or other automated network activities. In key characteristic of IoT device traffic is that the set of
contrast, a vast majority of DoS attack traffic has close to destination IP addresses rarely changes over time.
zero inter-packet intervals (ΔT ) and high first and second We craft two features to reflect this behavior. First, a
derivatives of inter-packet intervals. Using ΔT , dΔT dt , and count of distinct destination IP addresses within a 10-second
d2 ΔT
dt 2 as features allows a classifier to capitalize on this window; more endpoints may indicate attack traffic. Second,
difference between normal and DoS traffic. we calculate the change in the number of distinct destination
Protocol: Normal and DoS attack traffic also have IP addresses between time windows; new endpoints might
varying protocol distributions (Fig. 3e-f). UDP packets out- suggest that the device is conducting an attack. Fig. 3h
number TCP packets in normal traffic by almost a factor supports the importance of these two features. Packets
of three due to UDP video streaming. In comparison, TCP associated with attack traffic are in contact with, on average,
packets outnumber UDP packets in attack trafic by almost more endpoints. This minor distributional difference can be
the same ratio. Attack traffic also includes fewer protocols leveraged in differentiating normal and attack traffic.

32
 (a) (b) (c) (d)

(e) (f) (g) (h)

Figure 3: Comparison of feature statistics for normal versus DoS attack traffic. a) Packet sizes. b–d) Inter-packet intervals
(ΔT ), dΔT /dt, and d2 ΔT /dt2 . e–f) Protocol distributions. g) Average bandwidth over 10 second time windows. h) Number
of unique IP destinations in 10 second time windows.

V. R ESULTS Table I: IoT Traffic Classification Results

A. Classification KN LSVM DT RF NN
Precision (Normal) .998 .992 .996 .999 .983
We tested five machine learning algorithms to distinguish Precision (Attack) .999 .991 .999 .999 .999
normal IoT packets from DoS attack packets: Recall (Normal) .993 .870 .993 .998 .989
Recall (Attack) .999 .999 .999 .999 .998
1) K-nearest neighbors “KDTree” algorithm (KN) F1 (Normal) .995 .927 .994 .998 .986
2) Support vector machine with linear kernel (LSVM) F1 (Attack) .999 .995 .996 .999 .999
3) Decision tree using Gini impurity scores (DT) Accuracy .999 .991 .999 .999 .999
4) Random Forest using Gini impurity scores (RF)
5) Neural Network (NN): 4-layer fully-connected feed-
forward neural network (11 neurons per layer), trained (Table I). The accuracies of our four classifiers ranged from
for 100 epochs with batch size 32 using binary cross- approximately 0.91 to 0.99. Note that there are almost 15
entropy loss; hyperpameters chosen by optimization times as many attack packets as there are normal packets
on a validation set due to the flooding nature of the DoS attacks. Thus, a naive
We implemented these machine learning models using the baseline prediction algorithm that predicts that all packets
Scikit-learn Python library [22], except for the neural net- are malicious would achieve a baseline accuracy of 0.93.
work, which was implemented using the Keras library [23]. The linear SVM classifier performed the worst, suggesting
All hyper-parameters were the default values unless other- that the data is not linearly separable. The decision tree
wise noted. classifier performed well, achieving an accuracy of 0.99,
We trained the classifier on a training set with 85% suggesting that the data can be segmented in a higher fea-
of the combined normal and DoS traffic and calculated ture space. The K-nearest neighbors classifier also achieved
classification accuracy on a test set of the remaining traffic the same accuracy, suggesting that the two different data

33
 Table II: Feature Importance using Gini Impurity Scores. on a protected laboratory network or collaborating with an
Feature Gini Score
ISP to obtain NetFlow records or packet captures recorded
Packet Size .510 during a DDoS attack. This will be an essential test of the
is HTTP .177 method’s external validity.
ΔT .070
is TCP .068
Collecting a larger dataset would also allow us to see
is OTHER .043 how DoS detection accuracy is affected by the amount
is UDP .041 and diversity of IoT traffic. The network behavior of IoT
dΔT /dt .018
d2 ΔT /dt2 .012
devices varies widely by device type [7]. We are curious
Bandwidth .006 whether certain types of devices are more amenable to
# Destinations .004 network anomaly detection, perhaps because their normal
Δ # Destinations .003
traffic follows more regular patterns, or vice versa.
We would also like to experiment with additional features
and more complex machine learning techniques beyond
Table III: Classifier performance, with and without IoT-
those discussed in this paper. We believe that there is great
specific stateful (temporal) features.
potential for the application of deep learning to anomaly
F1 (Normal) KN LSVM DT RF NN detection in IoT networks, especially for detecting attacks
Stateless Features .967 .920 .977 .981 .939
All Features .995 .921 .995 .998 .989
that are more subtle than DoS floods. We hope that this
work inspires further efforts to develop network protection
techniques specifically designed for IoT devices.
classes clustered well in feature-space. The neural network It is also an open question how best to intervene once
performed surprisingly well despite having fewer than half an IoT device is discovered to be part of a DDoS attack.
a million training samples from a 10-minute packet capture. Simply cutting the device off from the network might not
Given the nature of the algorithm, the neural network be feasible, especially if the device is essential (e.g. a blood
is expected to scale its performance with the amount of sugar monitor or a home water pump), because many smart
available training data. devices do not retain basic functionality without network
connectivity [24]. Notifying the user is an option, but many
B. Feature Importance users of home IoT devices will be unequipped to perform
The stateless features greatly outperformed the stateful device maintenance beyond powering off or disconnecting
features, as indicated by Gini impurity score (Table II). We the device.
expected this result, since the differences in the cumulative VII. C ONCLUSION
distributions of normal and attack traffic were more pro-
nounced than those of the stateless features (Fig. 3). This In this work, we showed that packet-level machine learn-
result suggests that real-time anomaly detection of IoT attack ing DoS detection can accurately distinguish normal and
traffic may be practical because the stateless features are DoS attack traffic from consumer IoT devices. We used
lightweight and derived from network-flow attributes (e.g. a limited feature set to restrict computational overhead,
5-tuple and packet size). important for real-time classifcation and middlebox deploy-
Incorporating stateful features nonetheless improved ac- ment. Our choice of features was based on the hypothesis
curacy compared to classification with the stateless features that network traffic patterns from consumer IoT devices
alone (Table III). All of the classifiers experienced a 0.01 differ from those of well-studied non-IoT networked devices.
to 0.05 increase in F1 score by including stateful features. We tested five different ML classifiers on a dataset of
This demonstrates that applying domain knowledge about normal and DoS attack traffic collected from an experimental
IoT device behaviors to feature engineering can enhance consumer IoT device network. All five algorithms had a
DoS detection performance. test set accuracy higher than 0.99. These preliminary results
motivate additional research into machine learning anomaly
VI. D ISCUSSION & F UTURE W ORK detection to protect networks from insecure IoT devices.
This preliminary work demonstrates that simple classifica- ACKNOWLEDGMENTS
tion algorithms and low-dimensional features can effectively
distinguish normal IoT device traffic from DoS attack traffic. We thank Dillon Reisman, Daniel Wood, and Gudrun
This result motivates follow-up research to evaluate IoT DoS Jonsdottir. This work was supported by the Department of
detection in more real-world settings. Defense through the National Defense Science and Engi-
First, we would like to replicate the results of this study neering Graduate Fellowship (NDSEG) Program, a Google
with normal traffic from additional IoT devices and with Faculty Research Award, the National Science Foundation,
attack traffic recorded from a real DDoS attack. This could and the Princeton University Center for Information Tech-
involve using published code to create an IoT device botnet nology Policy Internet of Things Consortium.

34
 R EFERENCES [15] A. Sivanathan, D. Sherratt, H. H. Gharakheili, and A. V.
Vijay Sivaraman, “Low-cost flow-based security solutions for
[1] (2016) Unlocking the potential of the smart-home iot devices,” 2016.
internet of things. McKinsey & Company.
[Online]. Available: http://www.mckinsey.com/ [16] S. Hao, N. A. Syed, N. Feamster, A. G. Gray, and S. Krasser,
business-functions/digital-mckinsey/our-insights/ “Detecting spammers with snare: Spatio-temporal network-
the-internet-of-things-the-value-of-digitizing-the-physical-world level automatic reputation engine,” USENIX security sympo-
sium, vol. 9, 2000.
[2] (2015) Internet of things research study. Hewlett Packard
Enterprise. [Online]. Available: http://h20195.www2.hpe. [17] (2017) Yi home camera. [Online]. Available: https://www.
com/V4/getpdf.aspx/4aa5-4759enw yitechnology.com/yi-home-camera
[3] (2016) Internet of things (iot) security and privacy recommen- [18] (2017) Wemo insight smart plug. [Online]. Available:
dations. BITAG. [Online]. Available: https://www.bitag.org/ http://www.belkin.com/us/F7C029-Belkin/p/P-F7C029/
report-internet-of-things-security-privacy-recommendations.
php [19] (2017) Wireless blood pressure monitor. [Online]. Available:
https://health.nokia.com/us/en/blood-pressure-monitor
[4] S. Hilton. (2016) Dyn analysis summary of friday october
21 attack. Dyn. [Online]. Available: https://dyn.com/blog/ [20] (2017) Goldeneye code repository. [Online]. Available:
dyn-analysis-summary-of-friday-october-21-attack/ https://github.com/jseidl/GoldenEye
[5] (2016) Threat advisory: Mirai botnet. Akamai. [21] (2017) hping3 package description. [Online]. Available:
[Online]. Available: https://www.akamai.com/ http://tools.kali.org/information-gathering/hping3
us/en/multimedia/documents/state-of-the-internet/
akamai-mirai-botnet-threat-advisory.pdf [22] (2017) Scikit learn: Machine learning in python. [Online].
Available: http://scikit-learn.org/stable/
[6] V. Chandola, A. Banerjee, and V. Kumar, “Anomaly detection:
A survey,” ACM computing surveys (CSUR), vol. 41.3: 15, [23] F. Chollet et al., “Keras,” https://github.com/fchollet/keras,
2009. 2015.
[7] N. Apthorpe, D. Reisman, and N. Feamster, “A smart home [24] N. Apthorpe, D. Reisman, and N. Feamster, “Closing the
is no castle: Privacy vulnerabilities of encrypted iot traffic,” blinds: Four strategies for protecting smart home privacy from
2016. network observers,” Workshop on Technology and Consumer
Protection (ConPro), 2017.
[8] L. Ertoz, E. Eilertson, A. Lazarevic, P.-N. Tan, V. Kumar,
J. Srivastava, and P. Dokas, “Minds minnesota intrusion de-
tection system,” In Data Mining: Next Generation Challenges
and Future Directions, 2004.

[9] E. Eskin, W. Lee, and W. Stolfo, “Modeling system call for

intrusion detection using dynamic window sizes,” 2001.

[10] M. Qin and K. Hwang, “Frequent episode rules for internet

anomaly detection,” 2004.

[11] D. Barbard, J. Couto, S. Jajodia, and N. Wu, “Adam: A

testbed for exploring the use of data mining in intrusion
detection,” SIGMOD, vol. 30:4, 2001.

[12] J. Bigham, D. Gamez, and N. Lu, “Safeguarding scada sys-

tems with anomaly detection,” in Computer Network Security,
V. Gorodetsky, L. Popyack, and V. Skormin, Eds. Berlin,
Heidelberg: Springer Berlin Heidelberg, 2003, pp. 171–182.

[13] S. N. Shirazi, A. Gouglidis, K. N. Syeda, S. Simpson,

A. Mauthe, I. M. Stephanakis, and D. Hutchison, “Evaluation
of anomaly detection techniques for scada communication
resilience,” in 2016 Resilience Week (RWS), Aug 2016, pp.
140–145.

[14] M. Miettinen, S. Marchal, I. Hafeez, N. Asokan, A. Sadeghi,

and S. Tarkoma, “Iot sentinel: Automated device-type
identification for security enforcement in iot,” CoRR, vol.
abs/1611.04880, 2016. [Online]. Available: http://arxiv.org/
abs/1611.04880

35