iot security final v1 9 - upcommonsupcommons.upc.edu/bitstream/handle/2117/84150/memoria.pdf ·...

1

MASTER THESIS

TITLE: Improving Internet of Things Security with Software Defined Networking MASTER DEGREE: Master in Science in Telecommunication Engineering & Management AUTHOR: Raluca Ciungu DIRECTOR: Ricard Vilalta and David Pubill DATE: 26th of February 2016

3

Overview Due to the heterogeneous amount of Internet of Things (IoT) applications, different scenarios for the realization of an IoT network have been proposed, though usually they are incompatible among them. Moreover, the heterogeneity of the applications sets different requirements in terms of networking resources such as low delay in emergency applications or dynamic bandwidth allocation in video surveillance. Another challenge of IoT in smart cities arises from the efficient transport of the gathered information from the source nodes up to the processing and storage centres. Namely, the future IoT will connect to the Internet billions of heterogeneous smart devices with the capacity of interacting with the environment. Therefore, the proposed solutions from an IoT networking perspective must take into account the scalability of IoT nodes as well as the operational cost of deploying the networking infrastructure. This will generate a huge volume of data, which poses a tremendous challenge both from the transport, and processing of information point of view. Moreover, security issues appear, due to the fact that untrusted IoT devices are interconnected towards the aggregation networks. In this master thesis, Improving IoT with Software Defined Networking (SDN), SDN is the key enabler to address security challenges posed by IoT in the context networking. SDN is a new networking paradigm aiming to overcome the limitations of traditional IP networks, which are complex and hard to manage in terms of network configuration and reconfiguration due to faults and changes. The idea is to separate the control plane from the data plane, thereby the control logic in routers and switches will be moved to a centralized network controller. That is SDN, can be viewed as a network operating system which interacts with the data plane and the network applications by means of APIs. Therefore, SDN addresses properly the IoT challenges. SDN allows the enforcement of network security at the edge, and this project will benefit from this approach.

4

Resumen

Debido a la enorme variedad de aplicaciones que utilizan datos de sensores, se han propuesto diferentes soluciones para la realización de una red de Internet de las Cosas (IoT), siendo muchas de ellas soluciones verticales. Por otra parte, la heterogeneidad de estas aplicaciones establece diferentes requisitos en términos de recursos de red tales como bajo retardo en aplicaciones de emergencia o la asignación dinámica de ancho de banda en la video vigilancia. Otro de los retos del IoT en el ámbito las “ciudades inteligentes” (Smart Cities) surge del transporte eficiente de la información obtenida de la fuente hasta los centros de procesado y almacenamiento. En el futuro, IoT conectará a miles de millones de dispositivos inteligentes heterogéneos con la capacidad de interactuar con el entorno.

Por lo tanto, las soluciones propuestas desde una perspectiva de red IoT deben tener en cuenta la escalabilidad de los nodos, así como el coste operacional de la implementación de la infraestructura de red. Esto generará un enorme volumen de datos, lo que plantea un enorme desafío tanto para su transporte como para su procesado. Por otra parte, aparecen problemas de seguridad, debido al hecho de que los dispositivos maliciosos de IoT estarán interconectados hacia las redes de agregación.

En este proyecto de master, titulado “Mejora de la seguridad IoT a traves de Sofware Defined Networking (SDN)”, SDN es el factor clave para hacer frente a los retos de seguridad planteados por IoT en el contexto de redes. SDN es un nuevo paradigma de redes que tiene como objetivo de superar las limitaciones de las redes IP tradicionales, que son complejas y difíciles de gestionar en términos de configuración de red y reconfiguración cuando ocurren fallos y cambios.

La novedad que propone SDN es la separación del plano de control y del plano de datos, que se traduce en la separación de la lógica de control en enrutadores y conmutadores a un controlador de red centralizada. Es decir, SDN puede ser visto como un sistema operativo de red que interactúa con el plano de datos y las aplicaciones de la red por medio de una API. Esto permite que SDN aborde adecuadamente los desafíos de la IoT, permitiendo que la aplicación de la seguridad de la red se ejecute en la periferia de la red.

5

Acknowedlegements In these first lines of the Thesis, I take the opportunity to especially thank my tutors Ricard Vilalta and David Pubill, for having guided the selection of my Project Master Thesis and for their valuable assistance in the development thereof. I also want to thank Ricard and David for always being available when needed and for sharing their research projects and extensive bibliographic information that have served as basis and guided me in this project.

6

Table of Contents

INTRODUCTION ................................................................................................. 9

CHAPTER 1. STATE OF THE ART .................................................................. 11

1.1. IoT ..................................................................................................................................... 11 1.1.1. Sensors and actuators ......................................................................................... 12 1.1.2. Wireless Sensors Networks ................................................................................. 12 1.1.3. IoT Gateway ......................................................................................................... 13 1.1.4. IoT Applications .................................................................................................... 13

1.2. SDN ................................................................................................................................... 15 1.2.1. SDN basic principles ............................................................................................ 15 1.2.2. OpenFlow Switch ................................................................................................. 16 1.2.3. SDN Controller ..................................................................................................... 19 1.2.4. SDN Applications ................................................................................................. 20

1.3. Security ............................................................................................................................ 22 1.3.1. IoT security architecture ....................................................................................... 22 1.3.2 Anomaly detection methods .................................................................................. 27 1.3.3 Anomaly mitigation strategies ............................................................................... 28

CHAPTER 2. IOT SECURITY WITH SDN ........................................................ 30

2.1. IoT Security architecture ................................................................................................ 30

2.2. End-to-end Security Application .................................................................................... 31

2.3. Anomaly Detection .......................................................................................................... 32

2.4. Algorithm evaluation ....................................................................................................... 33

2.5. Simulation results ........................................................................................................... 35 2.5.1 Analysed data: pkts/sec, N_SIGMA ......................................................................... 36 2.5.2 Analysed data: pkts/sec, WINDOW .......................................................................... 37 2.5.3 Analysed data: bytes/sec, N_SIGMA ....................................................................... 38 2.5.4 Analysed data: bytes/sec, WINDOW ........................................................................ 39

CHAPTER 3. EXPERIMENTAL RESULTS ...................................................... 41

3.1 Testbed description ......................................................................................................... 41

3.2 Testbed configuration ..................................................................................................... 44

3.2.1 Flow description .............................................................................................................. 46

3.2.2 Port monitoring (Collector) ............................................................................................. 48

3.3 Intrusion detection algorithm (Anomaly detection) ...................................................... 50

3.4 Anomaly Mitigation .......................................................................................................... 50

CHAPTER 4. CONCLUSIONS AND FUTURE WORK LINES ......................... 52

7

4.1 Conclusions and results ................................................................................................. 52

4.2 Future work lines ............................................................................................................. 53

4.3 Environmental aspects .................................................................................................... 53

ABBREVIATIONS AND ACRONYMS .............................................................. 55

BIBLIOGRAPHY ............................................................................................... 56

ANNEX: SECURITY ALGORITHM ................................................................... 58

Improving IoT Security with SDN

9

INTRODUCTION Billions of objects will be connected to the internet in the coming years. Therefore it is expected a real revolution on the amount of data gathered and shared. This is known as the Internet of Things (IoT). Objects such as home appliances, lampposts, traffic lights or irrigation outlets are some examples of smart things. They are equipped with several sensors generating data, which then should be gathered and analysed Cloud computing means the ability to store and access data and programs over the Internet. It is a service offered by centralized data centers, which might be geographically distributed. Instead, fog computing is a decentralised and distributed computing infrastructure in which application services are handled at the network edge. Its goal is to improve efficiency and reduce the amount of data that needs to be transported to the cloud for data processing, analysis and storage [1]. The integration of IoT with fog and cloud computing is a valuable solution due to the functionality of computing, storage and networking resources at the edge of the network, thus allowing fast interaction with the data and low latency. Fog and cloud computing are expected to allow the data storage and processing from billions of smart things and IoT gateways, while delivering these functionalities at the edge of the network. IoT gateways are key enablers for IoT and typically consists of small gateways which are able to interconnect distributed wireless sensors, interconnected through wireless sensor networks (WSN), and acting as an internet gateway for the interconnected devices. Software Defined Networking (SDN) [11] is expected to be a key enabler for the next generation networks, the so-called 5G (5th generation of wireless systems), which will need to integrate both IoT services together with traditional human-based services. In this context, SDN enables a global orchestration of distributed cloud, heterogeneous network and IoT resources required in order to:

a) Transport the huge amount of data generated at the terminals, sensors, machines, nodes, etc., to any distributed computing node, edge, or core data center;

b) Allocate computing and storage resources in distributed data centers, and;

c) Process the collected data (Big Data) and make the proper decisions (cognition).

SDN automatically configures network devices, gathering the data needed for the analysis, while keeping private the details of the underlying infrastructure of devices. It is designed to authenticate users and devices and follow the prescribed rules of access. One of the biggest challenges IoT network administrators face, is the ability to collect data and conduct analyses to produce a positive user experience on the go. SDN makes it much faster and better than legacy network hardware. SDN is able to redirect traffic automatically when needed, which significantly improves


10

IoT applications. SDN can also provision the environment where is carried out and instantly delivered the analysis of data. Moreover, security issues appear, due to the fact that untrusted IoT devices are interconnected towards the aggregation networks or external malware are applied to the network [7]. It is in this context, where SDN can provide a huge advantage with regard to security. The technical solution proposed in this Master Thesis is intended to provide an agile answer on how to overcome and improve the IoT security with software-defined networks. The proposed work will consists in the programming of an intrusion detection algorithm as an SDN application and the validation of this intrusion detection algorithm in an experimental platform (network/environment). SDN is a method for centralized control of the network and devices, while it is allowing the network to be extremely flexible. The use of automated policy-based control allows transparent access across any device or platform (accepting Bring Your Own Device – BYOD policy). The permanent monitoring of own devices behaviour allows the scanning for potential threats. This Master Thesis has been performed in the premises of CTTC (Centre Tecnològic Telecomunicacions Catalunya), a research center located in Castelldefels (Spain). More exactly, the master thesis has been performed at the cloud/fog computing platforms and transport network of the ADRENALINE Testbed ®. In the context of evolving the capabilities of this testbed, my work has consisted in:

- The debugging of the Fog node and its SDN controller, which was quite unstable.

- The design of an overall architecture for the security application, which takes into account the several needed modules in order to properly analyse possible security threads.

- Design and validation of a simple algorithm (several have been studied) in order to validate the proposed application. The algorithm has been studied against a simulated security thread and its performance has been evaluated.

- Develop a security application which interacts with the Fog node SDN controller. Using a REST API, the flow statistics are read and analysed, using the previously validated algorithm.

This master thesis is organized as follows. In Chapter 1, an introduction on the State of the Art is provided on the related several topics: IoT, SDN and security. Chapter 2 proposes an SDN-enabled security architecture, which leverages the available real-time network flows information in order to take decisions regarding the provided security at the edge. A basic intrusion detection algorithm is proposed to validate the architecture design and it is evaluated in a simulated environment. In Chapter 3, the experimental evaluation and results are provided for the proposed security architecture. Finally, Chapter 4 presents the conclusions and proposals for future developments.


11

CHAPTER 1. STATE OF THE ART In this chapter, the state of the art for the Internet of Things and Software Defined Networking is presented. Additionally, security applications and IoT applications benchmarks are presented in order to offer a better approach and understanding with regard on the market already created around the Internet of Things.

1.1. IoT

The International Telecommunications Union defines the Internet of Things (IoT) as the “global infrastructure for the information society, enabling advanced services by interconnecting (physical and virtual) things based on existing and evolving interoperable information and communication technologies” [22]. Currently, the IoT is composed by a large number of networks designed for a wide range of applications. For example, the cars of today have different networks for controlling engine operation, the safety functions, communication systems, etc. Commercial and residential buildings have also various control systems for heating, ventilation and air conditioning; telephone service; security and lighting. As IoT progresses, these networks and many others, will be connected and will have more security features, analysis and management (see Fig.1.1) and will offer better services by breaking the silos built in through different IoT Networks. As Mario Campolargo, DG CONNECT European Commission states in [11] “IoT will boost the economy while improving our citizens’ lives.”

Fig.1.1 IoT a network of networks


12

At a wider level, cities are starting to adopt in different ways the IoT technology by deploying sensors around the cities with the purpose of providing new services for citizen (sensors parking, transport sensors, air quality sensors etc.), municipality (smart building, energy efficiency, resilient city) and third parties. This new services are grouped in the term smart cities. Thus, IoT is not only a new paradigm in which respect the technology delivered but also is a business ecosystem engine for the cities economic development.

1.1.1. Sensors and actuators

A sensor is a device whose main purpose is to detect and measure events or environment changes, providing the corresponding measurement output. Usually a sensor is compared with a transducer due to the fact that it converts one form of energy to another. Sensors may provide various types of output, but typically use electrical (analog or digital) or optical signals [22]. Sensors are used in innumerable applications or services, through large deployments of devices such as touch elevator buttons (tactile sensor), parking sensors, lighting sensors, industrial machine sensors etc. Applications include manufacturing and machinery, airplanes and aerospace, cars, medicine and robotics are also included in our day-to-day life. With advances in easy-to-use micro controller platforms, the uses of sensors have enlarged beyond the more traditional fields of temperature, air quality, shadow detection and pressure or flow measurement. An actuator is a type of device operated by a source of energy that can control or move a system or a mechanism. The actuator can be compared with a mechanism that converts energy in motion and through which a system acts upon an environment. Typically the source of energy is electric current, hydraulic fluid pressure or pneumatic pressure. The control system can be simple (a fixed mechanical or electronic system), software-based (e.g. a printer driver, robot control system), a human, or any other input.

1.1.2. Wireless Sensors Networks

A wireless sensor network (WSN) is a computer network composed by autonomous devices that uses sensors to monitor environmental or physical conditions such as vibration, temperature, sound, pressure or motion at different locations. Wireless sensor networks are now used in many application areas (e.g., smart cities, eHealth, Industry 4.0), including environment and habitat monitoring, healthcare applications, home automation, parking, waste management, air quality, noise measurement, traffic control and many others useful applications [12]. The WSN is built of "nodes" – from a few to several hundreds or even thousands, where each node is connected to one (or sometimes) several sensors. Each sensor network node has typically several parts: a radio transceiver with an internal antenna or connection to an external antenna, a microcontroller, an electronic circuit for interfacing with the sensors and an energy source, usually a battery or an embedded form of energy harvesting.


13

Size and cost constraints on sensor nodes result in corresponding constraints on resources such as energy, memory, computational speed and communications bandwidth. The topology of the WSNs can vary from a simple star network to an advanced multi-hop wireless mesh network.

1.1.3. IoT Gateway

A gateway is a network point that acts as an entrance to another network. An example of gateway node can be considered the computers that control traffic within a company network or at your local Internet service provider (ISP). Gateways are simplifying the IoT networks by supporting the connection of different network devices and by consolidating and mitigating the great variety and diversity of disparate data coming from different network devices. There are several ways to implement an IoT gateway, depending upon the application. Two common approaches are a simple gateway and an embedded control gateway. Both provide consolidated connectivity by aggregating data from multiple end points. In general, a simple gateway organizes and packetizes the data for transport over the Internet. It is also responsible for distributing data back to end points in applications where two-way communications is advantageous or required. Is important to specify that a gateway is different from a router. A router manages similar traffic, and it connects devices that share a common interface. For example, the devices that connect to a home router all use IP.

A gateway acts as a bridge, thus is able to route different types of traffic and convert these streams to a common protocol for access across the WAN. Some devices might use IP natively while others might use PAN-based protocols like Bluetooth, ZigBee or 6LoWPAN. Nodes that are simple sensors may need to be connected to an ADC (Analog to digital converter) to convert their raw analog voltage to a digital value before transport.

1.1.4. IoT Applications

Along with the increase in maturity of the IoT, the technology market is starting to develop services that are key solutions for the society challenges. Below are presented some of the market applications that are build based upon IoT concepts [13]: Table 1.1 IoT Applications

Smart Cities 01 Smart Parking Monitoring of parking spaces availability in the city. 02 Structural Health Monitoring of vibrations and material conditions in the buildings. 03 Noise Urban Maps Sound monitoring in bar areas and centric zones in real time. 04 Smartphone detection Detect iPhone and android devices and in general any device, which works with WiFi


14

and Bluetooth, interfaces. 05 Electromagnetic field levels Measurement of the energy radiated by cell stations and WiFi routers. 06 Traffic congestion Monitoring of vehicles and pedestrian levels to optimize traffic and walking routes. 07 Smart Lighting Intelligent and winter adapting streetlights. 08 Waste Management Detection of rubbish levels in containers to optimize the trash collection routes. 09 Smart Roads Intelligent highways with warning messages and diversions according to climate conditions and unexpected events like accidents or traffic jams. Smart Environment 10 Forest Fire Detection Monitoring of combustion gases and pre-emptive fire conditions alert zones. 11 Air Pollution Control of CO2 emissions of factories, pollution emitted by cars and toxic gases generated in farms. 12 Snow Level Monitoring Snow level measurement to know in real time the quality of ski tracks and allow security corps avalanche prevention. 13 Landslide and avalanche prevention Monitoring of soil moisture, vibrations and earth density to detect dangerous patterns in land conditions. 14 Earthquake Early Detection Distributed controls in specific places of tremors. Smart Water 15 Potable water monitoring Monitor the quality of tap water in cities. 16 Chemical leakage detection in rivers Detect Leakages and wastes of factories in rivers. 17 Swimming pool remote measurement Control remotely the swimming pool conditions. 18 Pollution levels in the sea Control real-time leakages and wastes in the sea. 19 Water Leakages Detection of liquid presence outside tanks and pressure variation along pipes. 20 River Floods Monitoring the water level variations in rivers, dams and reservoirs.

The IoT technology takes shape and many applications of the sensors are starting to be deployed through the cities. Nevertheless these applications need to have a layer of security due to the fact that malware attacks are at the moment a menace for the data owners.


15

1.2. SDN

Software-Defined Networking (SDN) is a network architecture that allows the programming of the network through clearly defined interfaces. SDN allows the possibility of creating new services and more efficient applications based on the interaction with networks traffic, network security implementation, or quality of service.

1.2.1. SDN basic principles

Given the heterogeneity of networks, it is challenging to coordinate and optimize the use of the heterogeneous network resources with the goal of satisfying as many tasks and services as possible. It is conjecture that the SDN paradigm is a good candidate to solve the resource management needs for network environments for multiple reasons [1]:

• SDN allows for a clear separation between services in the control plane (that makes decisions about how traffic is managed) and the data plane (actual mechanisms for forwarding traffic to desired destinations). The decoupling of the control plane from the forwarding plane encourages abstractions of low level network functionalities.

• Logically centralized view of the network, which allows to perform network optimization techniques. Redundancy and other mitigation failures can be applied in order to avoid single points of failure.

• Network programmability allows the dynamic and fast introduction of new network services.

Fig.1.2 SDN Architecture [19]

Figure 1.2 shows the SDN architecture, which is being defined by the Open Networking Foundation (ONF) [2]. It basically consists of three layers:


16

• Infrastructure layer, which consists of the OpenFlow-enabled network elements, such as layer 2 switches.

• Control layer, which allows the dynamic provisioning of network services by means of an SDN controller.

• Application layer, which allows the deployment of network-aware applications on top of an SDN controller.

The OpenFlow protocol is an open source protocol that is a foundational element for building SDN solutions. This protocol allows network controllers to determine the flow paths across a network of switches thus enabling the easy traffic management through the separation of the control plane from the forwarding plane.

1.2.2. OpenFlow Switch

An OpenFlow Switch consists of one or more flow tables and a group table, which perform packet lookups and forwarding, and an OpenFlow channel to an external controller Fig. 1.3. The SDN controller manages the switch via the OpenFlow protocol. Using this protocol, the controller can add, update, and delete flow entries, both reactively (in response to packets) and proactively [2].

Fig.1.3 An OpenFlow communicates with a controller over a secure connection using the OpenFlow protocol [18]

Each flow table in the switch contains a set of flow entries; each flow entry consists of match fields, counters, and a set of instructions to apply to matching packets.

OpenFlow is an open protocol that programs the flow tables in different switches and routers with the aim to create a shared management of the traffic flow. A usual example is the partition of the traffic into production and research traffic flow. A network administrator can partition the network traffic flow into research and production traffic flow, creating in this way a viable environment for research. Therefore, on the same network researchers are provided with entire control on their own flows by choosing the routes their packets follow.


17

This easiness of network data management facilitates the research on security models and scenarios addressing schemes, routing protocols and even alternatives to IP, while isolating the network production traffic.

An OpenFlow Switch consists of at least three parts:

1) A Flow Table, with an action associated with each flow entry, to tell the switch how to process the flow;

2) A Secure Channel that connects the switch to a remote control process, called the controller, allowing commands and packets to be sent between a controller and the switch;

3) The OpenFlow Protocol, which provides an open and standard way for a controller to communicate with a switch. By specifying a standard interface (the OpenFlow Protocol) through which entries in the Flow Table can be defined externally, the OpenFlow Switch avoids the need for researchers to program the switch.

OpenFlow provides remote administration of an up to layer 3 switch's packet forwarding tables, by adding, modifying and removing packet matching rules and actions, allowing controllers to make periodically or ad hoc decisions. Decisions are translated into actions and rules with a configurable lifecycle, which are deployed to a switch flow table. Unmatched packets by the switch can be forwarded to the controller. The controller can then decide to modify existing flow table rules on one or more switches or to deploy new rules, to prevent a structural flow of traffic between switch and controller. It could even decide to forward the traffic itself, provided that it has told the switch to forward entire packets instead of just their header. The OpenFlow protocol is layered on top of the Transmission Control Protocol (TCP), and prescribes the use of Transport Layer Security (TLS). A basic match table for flow definition, included in OF 1.3 includes the following parameters [17]:

• Switch input port. • Switch physical input port. • Metadata passed between tables. • Ethernet destination address. • Ethernet source address. • Ethernet frame type. • VLAN id. • VLAN priority. • IP DSCP (6 bits in ToS field). • IP ECN (2 bits in ToS field). • IP protocol. • IPv4 source address. • IPv4 destination address.


18

• TCP source port. • TCP destination port. • UDP source port. • UDP destination port. • SCTP source port. • SCTP destination port. • ICMP type. • ICMP code. • ARP opcode. • ARP source IPv4 address. • ARP target IPv4 address. • ARP source hardware address. • ARP target hardware address. • IPv6 source address. • IPv6 destination address. • IPv6 Flow Label • ICMPv6 type. • ICMPv6 code. • Target address for ND. • Source link-layer for ND. • Target link-layer for ND. • MPLS label. • MPLS TC. • MPLS BoS bit. • PBB I-SID. • Logical Port Metadata. • IPv6 Extension Header pseudo-field

The possible actions to be applied to a flow are the following (simplified) in OF 1.3:

• The Output action forwards a packet to a specified OpenFlow port. OpenFlow switches must support forwarding to physical ports, switch-defined logical ports and the required reserved ports.

• The set-queue action sets the queue id for a packet. When the packet is forwarded to a port using the output action, the queue id determines which queue attached to this port is used for scheduling and forwarding the packet. Forwarding behaviour is dictated by the configuration of the queue and is used to provide basic Quality-of-Service (QoS) support.

• There is no explicit action to represent drops. Instead, packets whose action sets have no output actions should be dropped. This result could come from empty instruction sets or empty action buckets in the processing pipeline, or after executing a Clear-Actions instruction.

• Required Action: Group. Process the packet through the specified group. The exact interpretation depends on group type.

• Switches may support the ability to push/pop tags to aid integration with existing networks, such as the ability to push/pop VLAN tags.


19

Moreover, the available flow counters per flow entry are the following:

• Received Packets

• Received Bytes

• Duration (seconds)

• Duration (nanoseconds) Finally, OF v1.3 introduces a new message (i.e. OFPT_METER_MOD) which enables the specification of traffic meters into the OF-switches, with an associated Band-rate and a QoS-enabling strategy, such dropping packets at a determined Drop-rate or Differentiated Services Code Point (DSCP) packet tagging to allow DiffServ. Flows can be attached to these predefined meters, associating a maximum rate to each flow. A Meter instruction has to be included inside the OFPT_FLOW_MOD message indicating the Meter-Id desired to be attached to.

Open vSwitch [20]: Open vSwitch sometimes abbreviated to OVS, is a production quality open source implementation of a distributed virtual multilayer switch. The main purpose of Open vSwitch is to provide a switching stack for hardware virtualization environments, while supporting multiple protocols and standards used in computer networks, such as OpenFlow. OVS have extensive hardware support through the usage of Intel’s DPDK (DataPath Development Kit), allowing faster responses and low latencies in Intel Network Interface Cards (NIC).

Other examples of virtual software switches are the following:

• The OpenFlow eXtensible DataPath daemon (xDPd) is a multi-platform, multi OF version, open-source datapath built focusing on performance and extensibility.

• Lagopus switch is a high-performance software OpenFlow 1.3 switch.

1.2.3. SDN Controller

As defined in SDN architecture [1], the SDN controller is a software entity that has exclusive control over an abstract set of data plane resources. An SDN controller may also offer an abstracted information model instance to at least one client. An SDN controller may be implemented as any number of software components, which reside on any number of physical platforms. The distributed components are required to maintain a synchronized and self-consistent view of information and state. This requirement bounds the concept of a single SDN controller; software components that do not share this characteristic are necessarily external to the controller. Several open source implementations of an SDN controller are available, being the most important the following.


20

The OpenDaylight Project [14] is a collaborative open source project hosted by The Linux Foundation. The goal of the project is to accelerate the adoption of software-defined networking (SDN) and create a solid foundation for Network Functions Virtualization (NFV). By supporting open standards such as OpenFlow, OpenDaylight delivers a common open source framework and platform for SDN across the industry for customers, partners and developers. A source code repository includes contributed source code from Big Switch Networks, Cisco and NEC. Open Daylight project is sponsored by the LINUX foundation, and it has its own website, wiki, and a mailing list available. These resources appear to currently be aimed at developers wishing to contribute to the project. The software is written in Java. ONOS [15] is the SDN network operating system for service providers architected for performance, high availability, scale-out and well-defined northbound and southbound abstractions and interfaces. ONOS was open-sourced on December 5th, 2014. The first open source release of ONOS was called Avocet and the next is Blackbird. Blackbird, which was released recently focuses on performance optimizations, defining metrics for measuring the "carrier-grade quotient" of SDN control planes/controllers and publicly providing the measurements for ONOS using these metrics. RYU [16] is a component-based software defined networking framework. Ryu provides software components with well-defined API that make it easy for developers to create new network management and control applications.

1.2.4. SDN Applications

It is surprising to notice that actually both in research and commercial industries there is a lot of research related with SDN architecture for security applied in IoT but there is a lack of published security algorithms and applications. By using the SDN controller, a wide range of applications can be developed covering the following topics, among others:

1) TAP Monitoring fabric application: advanced network monitoring solution that leverages high-performance bare metal Ethernet switches to provide the most scalable, flexible and cost-effective monitoring fabric

2) Security application 3) Network performance optimization and monitoring application 4) Data center fabric application

A special focus is dedicated to security applications to offer a better understanding on the commercial already developed solutions that apply security to data networks by using SDN. Security is a big concern in Data centers, sensor networks and industrial environments, and use of SDN technology gives the capability to dynamically adapt to new threats. Openflow is used both to get useful information from the


21

L2/L3 switches as well as to redirect/drop the traffic in case a positive threat is identified. SDN controllers work closely with DDos (distributed denial attack of service) application platforms in most cases. It has been decide to analyse the HP SDN VAN (Virtualized applications networks) controller [21]. Although it wasn’t found a security application applied in IoT with HP SDN VAN controller this solution could be used for IoT security. Below is presented a benchmark of some examples of security applied with SDN.

F5’s Big DDoS umbrella F5’s Big IP platform is a DDoS (distributed denial attack of service) application that monitors different kind of threats and once it confirms that the threat is real, it talks to HP’S VAN SDN controller so that the traffic can be filtered out in the edge. HP VAN SDN controller programs the OpenFlow switches to drop the malicious traffic. This approach saves precious network bandwidth in the data center. BlueCat DNS director This application is targeted towards security threats caused by BYOD (Bring your own device). DNS director programs Openflow switches in the network using HP VAN SDN controller to redirect requests for non-corporate DNS servers towards BlueCat’s DNS server. BlueCat’s DNS server sends back proper DNS response and the requestor will not even know that the DNS request was intercepted. HP Network protector HP Network protector is a SDN application on top of HP VAN SDN controller, which programs the Openflow switches. It’s mainly targeted for BYOD (Bring your own device) scenarios in Enterprises. Some of the important features of HP Network protector are:

• Creating custom white and black filter lists • Monitoring suspicious DNS requests • Malicious identity detection

Guardicore Defense suite Guardicore’s Defense suite application is built on top of HP VAN SDN controller. Its mainly targeted towards East-West traffic in Data Center. If there is 1 malicious host that has got inside the data center somehow, that host can target all other hosts in data center and external firewalls will not be able to catch this. Most of the times, the suspicious connections gets blocked inside the data center by firewalls. Defense suite monitors these blocked connections using the SDN controller and redirects these connections to Active Honeypot server that responds to these connections. The malicious host would not know that it is talking to Honeypot. Using this approach, critical information can be collected about the malicious host and this would prevent attacks before happening.


22

1.3. Security

The integration of Internet of Things (IoT) has provided the control of different connected devices into a single network or smart device, such as different types of wireless sensors networks, smartphones, tablets and at the same time gave born to a new paradigm related with security in IoT networks due to the fact that hacked devices can be easily introduced in the networks. Thus, IoT security has become essential for citizens’, organizations, governments and utilities for protection of data and infrastructures and is gaining power in day to day deployment. Since the beginning of the Internet era and development of networks, security has always been a primary concern for everyone, be it enterprises, small and medium businesses (SMBs), individuals or governments. Due to the increase of the networking applications and technological advancement security has converted in a big concern both in public a private environments. Prior to the emergence of IoT, the adverse effect of threats was limited to theft of money and intellectual properties. Now, the effect can lead to loss of human life, hacking of critical infrastructures like electricity and nuclear power grids, organizational productivity, and even national intelligence. Initially, the connection of devices took place between PCs (personal computers) and then threats and cyber attacks such as viruses and malwares showed their presence and effects. To minimize the damages caused due to such attacks and ensure proper security to prevent future attacks, cyber security solutions such as anti-viruses and anti-malwares were designed. Similarly, diversified networking led to the evolution of IoT and to secure the IoT, cyber security vendors modified their solutions to ensure security in IoT. The solutions such as intrusion detection and prevention systems, encryption, access management and SDN (software defined management) are the major solutions securing IoT. In the following subsections, we explore the state of the art for:

• Security architectures for SDN and IoT

• Anomaly detection methods

• Anomaly mitigation strategies

1.3.1. IoT security architecture

Several architectures have been taken into consideration in order to propose the IoT security architecture that better fits to the project requirements. The most relevant architectures are described below:

• Generic Architecture Network Intrusion Detection System (ANIDS)

• Simplified model of Architecture Intrusion Detection System

• Malware Monitor Generic Architecture Network Intrusion Detection System (ANIDS)


23

Many Network Intrusion Detection Systems (NIDSs) have been developed by researchers and practitioners [3]. However, the development of an efficient Architecture Network Intrusion Detection System (ANIDS’s) architecture is still being investigated.

A generic architecture of an ANIDS is shown in Fig. 1.4 [3]:

Fig.1.4 A generic architecture of a NIDSs

Fig.1.5 Steps for updating of configuration data in ANIDS

The main components of the generic model of the ANIDS are discussed below.

1) Anomaly detection engine: this module it attempts to detect occurrence of any intrusion either online or offline. However, before sending any network traffic to the detection engine, it needs pre-processing. If the attacks are known, they can be detected using the misuse detection approach. On the other hand, unknown attacks can be detected using the anomaly-based approach based on


24

an appropriate matching mechanism.

Matching mechanism: It entails looking for a particular pattern or profile in network traffic that can be built by continuous monitoring of network behaviour including known exploits or vulnerabilities. The following are some important requirements in the design of an efficient matching mechanism.

– Matching determines whether the new instance belongs to a known class defined by a high dimensional profile or not. Matching may be inexact.

– Matching must be fast. – Effective organization of the profiles may facilitate faster search during

matching. 2) Reference data: The reference data stores information about known intrusion signatures or profiles of normal behaviour. Reference data needs to be stored in an efficient manner. Possible types of reference data used in the generic architecture of a NIDS are: profile, signature and rule. In case of an ANIDS, it is mostly profiles. The processing elements update the profiles as new knowledge about the observed behaviour becomes available. These updates are performed in regular intervals in a batch-oriented fashion. 3) Configuration data: This corresponds to intermediate results, e.g., partially created intrusion signatures. The space needed to store such information can be quite large. The steps for updating of the configuration data are given in Fig. 1.5. Intermediate results need to be integrated with existing knowledge to produce consistent, up-to-date results. 4) Alarm: This component of the architecture is responsible for generation of alarm based on the indication received from the detection engine. 5) Human analyst: A human analyst is responsible for analysis, interpretation and for taking necessary action based on the alarm information provided by the detection engine. The analyst also takes necessary steps to diagnose the alarm information as a post-processing activity to support reference or profile updating with the help of security manager. 6) Post-processing: This is an important module in a NIDS for post-processing of the generated alarms for diagnosis of actual attacks. 7) Capturing traffic: Traffic capturing is an important module in a NIDS. The raw traffic data is captured at both packet and flow levels. Packet level traffic can be captured using a common tool, e.g., Wireshark1 and then pre-processed before sending to the detection engine 8) Security manager: Stored intrusion signatures are updated by the Security Manager (SM) as and when new intrusions become known. The analysis of novel intrusions is a highly complex task.

Simplified model of Architecture Intrusion Detection System

Another architecture that has been studied for the security detection intrusion is based on a simplified model composed by 3 modules:


25

a) Collector, b) Anomaly Detection, c) Anomaly Mitigation

Fig. 1.6 [3] shows each module named accordingly with the functionality that represents:

Fig.1.6 Architectural view of the proposed IDS on SDN environments

a) Collector Module: The Collector module is responsible for data gathering, a prerequisite in order to perform flow-based anomaly detection. This module collects flow information and periodically exports them to the Anomaly Detection module.

b) Anomaly Detection Module: Data produced by the previous module are subsequently fed to the Anomaly Detection module at periodic time intervals, thus creating discrete time windows. For every time-window this module inspects all flow entries, exposing any flow-related network anomaly and identifying a potential attacker or the victim of the attack. Moreover, it performs successfully not only in identifying the attack pattern, but also the attacker or the victim (i.e. host under attack). As soon as an anomaly is detected in the network, our algorithm inspects and correlates specific network metrics identifying the attack and exposing all related information to the Anomaly Mitigation module.

c) Anomaly Mitigation Module: The Anomaly Mitigation module aims to neutralize identified attacks, inserting flow-entries in the flow table of the Open Flow switch (or modify existing ones) in order to block the desired malicious traffic. These flow-entries have higher priority than any other in the flow table. In order to avoid blocking benign network flows that resemble malicious anomalies behaviour, we choose to insert specific host-related rules in a white list table.

Malware Monitor

Finally the third type of architecture, called Malware Monitor [4], was studied (Fig.1.7).


26

Fig.1.7 Architecture of Malware Monitor

Bellow it is presented how is envisioned the implementation of each module that composes the architecture [5]: a) Elastic Load Balancer: The load balancer is an SDN application running on an OpenFlow controller. It comprises a virtual machine (VM) Controller and network slicing logic. The VM controller assesses the network load and spawns a number n of machines implementing detection logic (detector nodes) from a VM pool it controls – hence the notion of elasticity. The job of the network slicing logic is to then logically partition the network into n slices, where a slice is defined as all track having a particular characteristic such as a certain port, protocol, or set of source addresses. It then creates flow rules in the data plane to forward a copy of all packets from each slice to the corresponding detector node.

b) Detector Nodes: Detector nodes first state fully inspect each received packet for malicious content to detect events associated with malware infections (e.g. DoS attacks or communication with malicious servers). Secondly, they compute flow statistics for each flow they receive, such as byte and packet counts or burst sizes. The second job can be accomplished by leveraging a feature of OpenFlow where switches maintain flow statistics for each flow that passes through them; thus the detector node can run an OF controller and simply pull flow statistics from the upstream edge switch. More advanced statistics can be calculated using simple utilities (tshark, capinfos, tcpdump) available for Unix-based operating systems. The detector node then


27

amalgamates the flow identification tuple (source/destination IP and port, and protocol) with any detected malicious activity (as an alert message) and the computed flow statistics, and sends it to the decision module.

c) Decision Module: The decision module examines the flow meta-data sent by the detector nodes to compute a maliciousness score for each individual flow. However unlike the detector nodes, which looked at only one flow at a time, the decision module performs correlation across flows to discover suspicious patterns or combinations of events – for example, a distributed DoS attack, or a number of flows from different hosts connecting to a common blacklisted IP (indicating members of a botnet). Thus it assigns a maliciousness score to a flow based not only on the events that have been detected as part of it but also on its similarity with other malicious flows this similarity can be seen in common events occurring in a flow or similar statistical characteristics. We believe that some stealthy flows that are able to disguise themselves individually can be discovered in this manner.

1.3.2 Anomaly detection methods

In this section are presented several network anomaly detection methods that are usually used for the development of detection anomaly algorithms.

These methods were studied in order to have a better approach on the suitable method to be used for the security algorithm development.

A network intrusion detection system (NIDS) usually integrates a network intrusion detection method within an architecture that comprises other associated sub-systems to build stand-alone practical system that can perform the entire range of activities needed for intrusion detection.

In the figure below, Fig.1.8. is presented the classification of methods that were studied for the development of the security algorithm.


28

Fig. 1.8 Classification of network anomaly methods [3]

A. Statistical methods and systems

An anomaly (from the statistical perspective) is behaviour considered being partially or entirely inappropriate due to the fact that is not generated by the stochastic model assumed.

Usually, statistical methods fit a statistical model to the given data and then apply a statistical inference test to determine if an unseen instance belongs to this model. Instances that have a low probability to be generated from the learnt model based on the applied test statistic are declared anomalies.

B. Classification-based methods and systems

Classification based methods and systems is the method that identifies the belonging of an observation to a set of categories, where the set of categories is a training set of data containing observations whose category membership is known.

C. Clustering and Outlier-based methods and systems

Clustering is the method of distributing a set of objects into groups called clusters in such way that object from the same cluster are more similar (in certain sense) than those from different clusters. Clustering method is used in explorative data mining. For example, if we have a set of objects in two dimensions, we may be able to cluster them into a defined number of clusters by drawing circles or ellipses around them. Outliers are points from a dataset that for a given model of data they are highly unlikely to occur.

D. Soft computing methods and systems

Soft computing is usually thought of as incorporating methods such as Genetic Algorithms, Artificial Neural Networks, Fuzzy Sets, Rough Sets, Ant Colony Algorithms and Artificial Im-mune Systems. This method is used for the network anomaly detection because of the easiness to detect the exact solution.

E. Knowledge-based methods and systems

The objective of this method is to represent the attacks in a generic way to allow for an easy detection of the malware. This method search for instances of known attacks, by attempting to match with pre-determined attack representations.

In the first instance the search of malware begins with a complete lack of knowledge and subsequent, matching of activities against a known attack helps acquire knowledge and enter into a zone with higher confidence.

1.3.3 Anomaly mitigation strategies

Two important mitigation strategies are discussed. The first focuses on limiting the effect of an anomaly to the network bandwidth, while the second tries to


29

minimize completely the impact of an anomaly, and can be understood as a corner case of the first strategy. Rate Limiting In computer networks, rate limiting is used to control the rate of traffic sent or received by a network interface controller. It can be induced by the network protocol stack of the sender and also by the network scheduler of any router along the way. The rate limiting (or traffic shaping) is the regulation of the rate at which flows are allowed to inject packets into the network and is therefore one of the cornerstones of any QoS architecture. OpenFlow 1.3 allows different rate limiting policies once a certain rate has been reached:

– Drop: Drop (discard) the packet. Can be used to define a rate limiter band.

– Dscp: decreases the drop precedence of the DSCP field in the IP header of the packet. Can be used to define a simple DiffServ police.

Flow interruption In order to do not allow any traffic of a suspicious flow, the flow rule can be directly removed from the SDN controller.


30

CHAPTER 2. IOT SECURITY WITH SDN After analysing the current state of the art in previous chapter, this chapter focuses on the following objectives:

- Propose an open source IoT security architecture based on SDN principles.

- Describe different IoT security threats and design an anomaly detection mechanism.

- Evaluate the behaviour of the proposed anomaly detection mechanism, taking into account a specified IoT security threat.

2.1. IoT Security architecture Our proposed IoT security architecture consists of three basic components, which are show in Fig. 2.1: An SDN/NFV edge node, an SDN controller and an E2E security application. The SDN/NFV Edge Node is a distributed computing infrastructure in which some application services are handled at the network edge. The industry has named this technology as fog computing. The goal of this fog node is to improve efficiency and reduce the amount of data that needs to be transported to the cloud for data processing, analysis and storage. This is often done for efficiency reasons, but it may also be carried out for security and compliance reasons. This Fog node has the ability to act as:

a. An OpenFlow-enabled switch. To this switch the different IoT gateways are connected, as well as connectivity to aggregation and transport networks is provided.

b. Virtual Machines running different services, such as an IoT database, where the measurements of the different WSN are stored for local processing.

The SDN controller shall be able to support OpenFlow control of flow tables, meters and actions. A clear North Bound Interface (NBI) of the SDN controller shall be described in order to ease the integration of higher level applications. The End-to-end security application will be responsible for the monitoring of the current flows, and through different anomaly detection mechanism it will be able to identify malicious flows. Finally, this application will apply the desired security policies with regard to the detected anomalies in order to mitigate them. It will consists of three main modules shown in Fig. 2.1: (a) the Collector, (b) the Anomaly Detection and (c) the Anomaly Mitigation.


31

Fig 2.1 IoT Security Testbed

2.2. End-to-end Security Application

Below, the different components of the E2E security application are described. Collector Module

The Collector module is responsible for data gathering, a prerequisite in order to perform flow-based anomaly detection. This module collects flow information and periodically exports them to the Anomaly Detection module.

If we focus on the available information from the SDN controller, the different per flow counters might be obtained. From this information we can estimate the following data per flow:

- Packets per second.

- Bytes per second.

These data will allow us to detect anomalies in the flows, such as for example intrusion detection, or WSN malfunction.

Anomaly Detection Module

Data produced by the previous module are subsequently fed to the Anomaly Detection module at periodic time intervals, thus creating discrete time windows. For every time window this module inspects all flow entries, exposing any flow-related network anomaly and identifying a potential attacker or the


32

victim of the attack. Moreover, it performs successfully not only in identifying the attack pattern, but also the attacker or the victim (i.e. host under attack). As soon as an anomaly is detected in the network, our algorithm inspects and correlates specific network metrics identifying the attack and exposing all related information to the Anomaly Mitigation module.

In later sections of this chapter, we will describe an anomaly detection mechanism and we will evaluate its behaviour against this kind of attack.

Anomaly Mitigation Module

The Anomaly Mitigation module aims to neutralize identified attacks, inserting flow meters in the flow table of the Open Flow switch (or removing existing flows) in order to block/mitigate the desired malicious traffic. These flow entries have higher priority than any other in the flow table.

This module is presented in Chapter 3, in the experimental results.

2.3. Anomaly Detection

In data mining, anomaly detection (or outlier detection) is the identification of items, events or observations, which do not conform to an expected pattern, or other items in a dataset. Typically the anomalous items will translate to some kind of problem such as bank fraud, a structural defect, medical problems or errors in a text. Anomalies are also referred to as outliers, novelties, noise, deviations and exceptions. In particular in the context of abuse and network intrusion detection, the interesting objects are often not rare objects, but unexpected bursts in activity. This pattern does not adhere to the common statistical definition of an outlier as a rare object, and many outlier detection methods (in particular unsupervised methods) will fail on such data, unless it has been aggregated appropriately. The most common measures of dispersion for continuous data are the variance and standard deviation. Both describe how much the individual values in a data set vary from the mean or average value. The variance and standard deviation are calculated slightly differently depending on whether a population or a sample is being studied, but basically the variance is the average of the squared deviation from the mean, and the standard deviation is the square root of the variance. For the detection of the anomalies it has been envisaged an algorithm based on the data variance gathered from a sensors network. The formula presented below is the deviation calculated for the data provided by the sensors:

Standard deviation: 𝜎 = !!

(𝑥! − 𝑥)!!!!! (2.1)

Where,


33

𝜎 = 𝑠𝑡𝑎𝑛𝑑𝑎𝑟𝑑 𝑑𝑒𝑣𝑖𝑎𝑡𝑖𝑜𝑛 𝑥! = 𝑠𝑒𝑛𝑠𝑜𝑟 𝑑𝑎𝑡𝑎 (𝑥) = 𝑚𝑒𝑎𝑛 𝑣𝑎𝑢𝑒 𝑐𝑎𝑙𝑐𝑢𝑙𝑎𝑡𝑒𝑑 𝑓𝑜𝑟 𝑡ℎ𝑒 𝑑𝑎𝑡𝑎 The malware detection is sensed for the data processed by the sensors and is conditioned by the following formula: Condition: 𝑥! < 𝑥 ± 𝑛 ∗ 𝜎 (2.2)

2.4. Algorithm evaluation

The IoT security algorithm has been developed by using Python programming language. Python is an interpreted, object-oriented programming language with dynamic semantics. The programming language is built in data structures, combined with dynamic typing and dynamic binding, make it very attractive for Rapid Application Development, as well as for use as a scripting or glue language to connect existing components together. Python reduces the cost of program maintenance due to it’s simple, easy to learn syntax emphasizes readability and therefore. Python supports modules and packages, which encourages program modularity and code reuse. The Python interpreter and the extensive standard library are available in source or binary form without charge for all major platforms, and can be freely distributed. In the picture below, Fig.2.2, is depicted the module of flows creation algorithm. It can be observed how dangerous flows are modelled.

a) A conformant flow is created with the following properties:

a. Using the base of 20 packets/second – which shall match for example the readings of 20 sensors each second, we introduce a small uniform variance.

b. The number of bytes per second is linearly obtained from the packets per second (using a standard 100 bytes per packet).

b) A bad flow is created with a probability of 10%. A bad flow has different

properties: a. The number of packets per second are duplicated (in comparison

with a conformant flow). b. Packet size is also 50% increased.


34

Fig.2.2 Flows creation

In the following figure are presented the modules of: mean function definition, standard deviation definition and flows checking algorithm.

Fig.2.3 Definition of Mean function, standard deviation and check flows

The following module presents the evaluation of the algorithm. First the algorithm is checking for bad flows through the flows created in the module presented in Fig.2.2 then the algorithm it calculates the percentage bad flows error by applying the condition presented through the formula 2.2 that is comprised between, (N_SIGMA) threshold_up and (N_SIGMA) threshold_down.


35

Fig.2.4 Evaluation algorithm

2.5. Simulation results In the previous section were presented the main modules of the security algorithm, thus, during the simulation process, the main purpose was to simulate the algorithm and to detect the ideal length of window and standard deviation for which the error to detect the traffic malware is the smallest. Also, is important to mention that the simulation was realized for 5 simulated parameters N_SIGMA and 3 simulated parameters of WINDOW (see below scenarios results a, b, c, d) for both types of traffic simulated, packets/s and bytes/s, therefore the conclusions and explanations made for each scenario are based strictly on these results. For the simulation of the algorithm were modelled the following simulation scenarios:

a) Standard Deviation: N_SIGMA, Simulated Traffic: packets/s, Detected Error (%): error,

b) Simulated traffic: packets/s, Window of simulation: w, Detected error (%): error

c) Standard Deviation: N_SIGMA, Simulated Traffic: bytes/s, Detected Error (%): error

d) Simulated Traffic: bytes/s, Window of simulation: w, Detected Error (%): error


36

2.5.1 Analysed data: packets/sec, N_SIGMA

The main purpose of this simulation was to detect the best (smallest) standard deviation of the flow for which the error to detect the traffic malware is the smallest.

The simulation has been realized for 1000 samples. For each N_SIGMA it has been simulated the algorithm 3 times and each time the error was tracked, afterwards it has been calculated the mean value of Error (%). The calculated mean value of Error (%) is presented in the table below: Table 2.1 Simulation results Error (%) vs N_SIGMA, packets/s

N_SIGMA 2 4 8 10 12 Error (%) vs N_SIGMA 73,3 26,9 17,2 13,8 18,3

By variations of the traffic standard deviation (sigma) it was noticed that when incrementing sigma the error was decrementing reaching the best result for N_SIGMA =10 and error = 13,8% (see values in Table 2.1). As can be visualized in the Fig. 2.2 the best result has been obtained for N_SIGMA = 10, error= 13,8%. If we take a deeper look, we can observe that is an optimal value, due to the fact that for lower and higher values, the performance of the algorithm decreases in terms of errors in detected security threats. This optimal value for N_SIGMA is related somehow to the dangerous flows properties, in terms of both the number of times that packets per second are multiplied and the small standard deviation produced due to the fact that only values from 20 to 23 packets/sec are generated. If the selected N_SIGMA is lower that the optimal, the algorithm might detect false positives, due to the proximity to standard flows. On the other hand, if the selected N_SIGMA is higher than the optimal, the algorithm doesn’t detect many possible threats due to the fact that only a small portion of dangerous flows might have such a higher number of packets/sec.


37

Fig.2.2 Simulation Scenario a)

2.5.2 Analysed data: packets/sec, WINDOW

The simulation has been realized for N_SIGMA= 10 and 1000 samples. For each WINDOW length it was simulated the algorithm 3 times and each time the error was tracked, afterwards it has been calculated the mean value of Error (%). The calculated mean value of Error (%) is presented in the table below: Table 2.2 Simulation results Error (%) vs WINDOW, packets/s

WINDOW 5 10 20 Error (%) vs WINDOW 13,8 3,9 5,2

As a first approach it was observed that when incrementing the window of simulation from 5 to 10 the error was decrementing (see Table 2.2). This can be explained due to the fact that a small window size, doesn’t leave time to properly measure the flow standard deviation. Decisions made by this incorrect measurement of standard deviation will be error prone. Nevertheless this behaviour wasn’t linear as for incrementing the window length from 10 to 20, the error incremented. As can be visualized in the Fig. 2.3 the best result has been obtained for WINDOW = 10, error= 3,9%.

0,0

10,0

20,0

30,0

40,0

50,0

60,0

70,0

80,0

2 4 8 10 12

Error (%) vs N_SIGMA


38

Fig.2.3 Simulation Scenario b)

2.5.3 Analysed data: bytes/sec, N_SIGMA

The main purpose of this simulation was to detect the best (smallest) standard deviation of the flow for which the error to detect the traffic malware is the smallest. The simulation has been realized for 1000 samples. For each N_SIGMA it has been simulated the algorithm 3 times and each time the error was tracked, afterwards it has been calculated the mean value of Error (%). The calculated mean value of Error (%) is presented in the table below: Table 2.3 Simulation results Error (%) vs N_SIGMA, bytes/s

N_SIGMA 2 4 8 10 12 Error (%) vs N_SIGMA 73,3 30,7 14,6 6,5 20,0

By variation of the traffic standard deviation (N_SIGMA) it has been noticed that when incrementing sigma the error was decrementing. As can be visualized in the Fig. 2.4 the best result has been obtained for N_SIGMA = 10, error= 6,5%. This systems has the same behaviour as the scenario from section 2.5.1 as somehow is similar with the one presented in this section, the change is that analysis is realized for the traffic-bytes/s.

0,0

2,0

4,0

6,0

8,0

10,0

12,0

14,0

16,0

5 10 20

Error (%) vs WINDOW


39

Fig.2.4 Simulation Scenario c)

2.5.4 Analysed data: bytes/sec, WINDOW The simulation has been realized for N_SIGMA= 10 and 1000 samples. For each WINDOW length it was simulated the algorithm 3 times and each time the error was tracked, afterwards it has been calculated the mean value of the Error (%). The calculated mean value of Error (%) is presented in the table below:

Table 2.4 Simulation results Error (%) vs WINDOW, bytes/s

WINDOW 5 10 20 Error (%) vs WINDOW 6,53 0,03 0,56

As a first approach it was observed that when incrementing the window of simulation from 5 to 10 the error was decrementing (see Table 2.4). This can be explained due to the fact that a small window size, doesn’t leave time to properly measure the flow standard deviation. Decisions made by this incorrect measurement of standard deviation will be error prone. Nevertheless this behaviour wasn’t linear as for incrementing the window length from 10 to 20, the error incremented. As can be visualized in the Fig. 2.5 the best result has been obtained for WINDOW = 10, error= 0,03%.

0,0

10,0

20,0

30,0

40,0

50,0

60,0

70,0

80,0

2 4 8 10 12

Error (%) vs N_SIGMA


40

Fig.2.5 Simulation Scenario d)

Overall, it has been observed that for both type of simulated traffic (packets/s and bytes/s) the best behaviour of the algorithm is attained for window length =10 and N_SIGMA=10. It results that the behaviour of the algorithm is stable for the values mentioned before. Additional to the simulation results it can be observed in the figure depicted below (see Fig 2.6) that for flows which vary dynamically, smaller (but not too small) – local- window sizes are better, as they allow the better tracking of flow anomalies.

Fig.2.6 Window importance

0,00

1,00

2,00

3,00

4,00

5,00

6,00

7,00

5 10 20

Error (%) vs WINDOW


41

CHAPTER 3. EXPERIMENTAL RESULTS

3.1 Testbed description In order to carry out the experimental part of this work an IoT platform has been connected to the ADRENALINE Testbed®, developed by the researchers form CTTC (Fig 3.1). The cloud/fog computing platforms and transport network offer an integrated cloud and network orchestration which is capable of creating VMs and establishing End-to-End (E2E) paths through heterogeneous networks considering multi-domain SDN orchestration. The deployed architecture allows providing E2E connectivity services of VMs located in different network locations, interconnected though multi-layer multi-domain networks considering heterogeneous SDN/OpenFlow (OF) and General Multiprotocol Label Switches (MPLS)/Path Computation Element control planes [8].

The IoT platform (Fig 3.2) consists of a temperature and a dioxide carbon (CO2) sensors, 2 Wireless Sensor Network (WSN) nodes and 2 gateways that gather the data generated by the sensors, one SDN NFV Edge Node to control the flows of data coming from the sensors and a database where the data is stored. The SDN NFV Edge Node network element is able to provide computing, storage and networking services, acting as a cloud edge node (fog node) and has been introduced in [8].

Fig.3.1 presents the considered system architecture which includes the proposed SDN/NFV-enabled edge node. The proposed node consists of an OF-enabled switch, compute and storage resources. The switch is controlled via an edge SDN controller, while the computation and storage resources are controlled with an edge cloud/fog controller. On top of the proposed architecture, the Integrated Cloud/Fog and Network Orchestrator is responsible for handling a VM and network connectivity requests, which are processed through the Cloud/Fog and Multi-domain SDN orchestrators.

Fig.3.1 Overall ADRENALINE Testbed


42

The proposed E2E security application (Fig.3.2) runs on top of the SDN/NFV-enabled edge node and it has been implemented as described in previous chapter and the implementation has been done in python.

Fig.3.2 IoT Security Testbed The proposed SDN/NFV edge node has been developed using an Intel NUC NUC5i5RYH, with 16Gb RAM and 120 Gb SSD. Several USB to Ethernet port converters have been included in order to extent the node switching capabilities. RYU SDN controller and OpenStack nova services are run in the node as well. The WSN nodes are Z1 motes by Zolertia (Fig 3.3), which feature a 16-bit RISC CPU @16MHz, an 8KB RAM and a 92 KB flash memory. They also include the CC2420 transceiver, which is IEEE 802.15.4 compliant. These nodes support ContikiOS, an open-source operating system for the IoT, which connects tiny, low-cost, low-power microcontrollers to the Internet and supports Ipv6 through 6LowPAN. It is worth noting that each mote can operate as either a source or a sink node.


43

Fig.3.3 WSN node – Z1 mote by Zolertia Finally, the IoT gateways are connected to 2 WSN sink nodes via USB. IoT gateways have been implemented using a Raspberry Pi 2, using Raspbian, based on Debian. The IoT gateway reads the measurements in the USB port and it retransmits them to a processing software, which is run in a VM running at the edge node. Fig. 3.4 shows the network topology as seen by the SDN orchestrator. It can be observed that the SDN/NFV- enabled edge node is depicted in red, and interconnected towards the metro network.


44

Fig.3.4 Network Topology

3.2 Testbed configuration

In Fig.3.5, the overall system from the networking perspective is depicted. First, two IoT gateways are interconnected towards a virtual software switch (SW1), running on the edge node. This external virtual software switch is interconnected towards an internal virtual software switch (SW2) into with the virtual machines are connected. Finally, the IoT virtual machine (test_iot) is connected to this second switch.


45

Fig.3.5 Overall system configuration

Fig.3.6 System motes


46

3.2.1 Flow description In the table below, are described the technical details of the flow, MAC addresses and IP addresses that are configured in the IoT Security Testbed, for the gateways and the SDN/NFV Edge Node. The details, in terms of flow traffic were described in the Section 3.1 Testbed description. While iot-gw1 and iot-gw2 are the external IoT gateways, test_iot is the virtual machine running in the edge node, which is responsible for running the storage services (implemented as a MySQL database). Table 3.1 Testbed description

Name flow IP address Gateway MAC

address Switch MAC address switches

Port no.

iot-gw2 iot-gw2 private-iot

10.1.14.8 10.1.7.45 b8:27:eb:8a:c5:ff 00:00:80:3f:5d:08:2b:72 3

iot-gw1 iot-gw1 private-iot

10.1.14.7 10.1.7.45 b8:27:eb:4f:67:5b 00:00:80:3f:5d:08:2b:72 1

test_iot

6f16ab70-b9b6-47ca-886e-36b3c6696375 private-iot

10.1.14.17 192.168.30.30 fa:16:3e:ef:ef:15 00:00:6a:5a:fb:3b:66:41 41

Fig 3.5 shows the SQL Database, which is composed by the following data columns: date and hour when the data has been recorded, id of the mote (in this case id of the sensor), value recorder, description of the recorded value and the id of the value.


47

Fig.3.6 IoT SQL Database Flow Description The traffic is routed from IoT Gateway 1 with MAC address b8:27:eb:4f:67:5b and IP address 10.1.14.7 through the source: OpenFlow switch with the following MAC address 00:00:80:3f:5d:08:2b:72 and interface connected to port 1, with the following IP address 10.1.7.48 and the destination: a switch with the following MAC address 00:00:6a:5a:fb:3b:66:41, this switch is in charge of managing the traffic of the IoT SQL Database through an interface of the controller, number 41, with the following IP address 192.168.30.30. Below is presented the script of the flow.


48

Source: {“routerId”:”00:00:80:3f:5d:08:2b:72”,”interfaceId”:”1”,”endpointId”:”iot-gw1”} Dst:{“routerId”:”00:00:6a:5a:fb:3b:66:41”,”interfaceId”:”41”,”endpointId”:”test_iot”} Traffic Params: {“reservedBandwidth”:”100000000”} ConnectionType: {“direction”:”bidir”,”layer”:”48thernet”,”layerId”:”48thernet”} Match: {“ethDst”:”fa:16:3e:ef:ef:15”,”ethSrc”:”b8:27:eb:4f:67:5b”} The traffic is routed from Gateway 2 with MAC address b8:27:eb:8a:c5:ff and IP address 10.1.14.8 through the source, OpenFlow switch with the following MAC address 00:00:80:3f:5d:08:2b:72 and interface connected to port 3, with the following IP address 10.1.7.49 and the destination: a switch with the following MAC address 00:00:6a:5a:fb:3b:66:41 , this switch is in charged to manage the traffic of the IoT SQL Data Base through an interface of the controller, number 41, with the following IP address 192.168.30.30. Below is presented the script of the flow. Src: {“routerId”:”00:00:80:3f:5d:08:2b:72”,”interfaceId”:”3”,”endpointId”:”iot-gw2”} Dst: {“routerId”:”00:00:6a:5a:fb:3b:66:41”,”interfaceId”:”41”,”endpointId”:”test_iot”} Traffic Params: {“reservedBandwidth”:”100000000”} ConnectionType: {“direction”:”bidir”,”layer”:”48thernet”,”layerId”:”48thernet”} Match: {“ethDst”:”fa:16:3e:ef:ef:15”,”ethSrc”:”b8:27:eb:8a:c5:ff”}

3.2.2 Port monitoring (Collector)

As explained in the section 3.1 IoT Security Architecture, the Collector module is responsible for data gathering, a prerequisite in order to perform flow-based anomaly detection. This module collects flow information and periodically exports them to the Anomaly Detection module.

Below are presented the scripts that are collecting the traffic from the switch OF_1 (Fig.3.5) and send them to the algorithm presented in the section 2.4:


49

Fig.3.7 Script 1: traffic collection

Fig.3.8 Script 2: traffic collection

The flows are recorded as per packets per second and bytes per second as presented in the traffic frame presented below.

Flow 1: Flow 1match: {u’dl_type’: 2048, u’nw_dst’: u’0.0.0.0’, u’dl_vlan_pcp’: 0, u’dl_src’: u’b8:27:eb:8a:c5:ff’, u’nw_proto’: 0, u’tp_dst’: 0, u’tp_src’: 0, u’dl_dst’: u’fa:16:3e:ef:ef:15’, u’dl_vlan’: 0, u’nw_src’: u’0.0.0.0’, u’in_port’: 3} Flow 1 packets per second: 10.1859442215 Flow 1 bytes per second: 1013.40158784 packets_per_second [10.185960712699861, 10.185944221504872] packets_per_second diff -1.64911949891e-05 bytes_per_second [1008.6098352771432, 1013.4015878414848] bytes_per_second diff 4.79175256434 Flow 2: Flow 2match: {u’dl_type’: 2048, u’nw_dst’: u’0.0.0.0’, u’dl_vlan_pcp’: 0, u’dl_src’: u’b8:27:eb:4f:67:5b’, u’nw_proto’: 0, u’tp_dst’: 0, u’tp_src’: 0, u’dl_dst’: u’fa:16:3e:ef:ef:15’, u’dl_vlan’: 0, u’nw_src’: u’0.0.0.0’, u’in_port’: 1} Flow 2 packets per second: 3.99448802511 Flow 2 bytes per second: 365.495654297 packets_per_second [3.994500008345081, 3.99448802510669] packets_per_second diff -1.19832383909e-05 bytes_per_second [365.4967507635749, 365.49565429726215] bytes_per_second diff -0.00109646631273


50

Flow 3: Flow 3match: {u’dl_type’: 2048, u’nw_dst’: u’0.0.0.0’, u’dl_vlan_pcp’: 0, u’dl_src’: u’fa:16:3e:ef:ef:15’, u’nw_proto’: 0, u’tp_dst’: 0, u’tp_src’: 0, u’dl_dst’: u’b8:27:eb:8a:c5:ff’, u’dl_vlan’: 0, u’nw_src’: u’0.0.0.0’, u’in_port’: 8} Flow 3 packets per second: 6.19145643892 Flow 3 bytes per second: 458.567225282 packets_per_second [6.091620344662047, 6.1914564389153695] packets_per_second diff 0.0998360942533 bytes_per_second [456.7716632210525, 458.567225282248] bytes_per_second diff 1.7955620612 Flow 4: Flow 4match: {u’dl_type’: 2048, u’nw_dst’: u’0.0.0.0’, u’dl_vlan_pcp’: 0, u’dl_src’: u’fa:16:3e:ef:ef:15’, u’nw_proto’: 0, u’tp_dst’: 0, u’tp_src’: 0, u’dl_dst’: u’b8:27:eb:4f:67:5b’, u’dl_vlan’: 0, u’nw_src’: u’0.0.0.0’, u’in_port’: 8} Flow 4 packets per second: 1.99724420276 Flow 4 bytes per second: 156.783669917 packets_per_second [1.99725537763938, 1.9972442027629256] packets_per_second diff -1.11748764544e-05 bytes_per_second [156.78454714469135, 156.78366991688966] bytes_per_second diff -0.000877227801681

The fist part of the algorithm, collector module, is devoted to generate the flows in packets per second and bits per second. In the first step is depicted, through def create bad_flows function, the percent of error (bad_flow) that will be generated. In the second approach are depicted the flows comprised between a range of 0 and N_Flows, where N_Flows is 5. The depiction of the dangerous flows starts when the condition if not create bad_flow () is not accomplished.

3.3 Intrusion detection algorithm (Anomaly detection)

As explained in the Section 3.1 IoT Security Architecture, the data produced by the previous module (Data Collector) are subsequently fed to the Anomaly Detection module at periodic time intervals, thus creating discrete time windows. For every time-window this module inspects all flow entries, exposing any flow-related network anomaly and identifying a potential attacker or the victim of the attack. Moreover, it performs successfully not only in identifying the attack pattern, but also the attacker or the victim (i.e. host under attack). As soon as an anomaly is detected in the network, our algorithm inspects and correlates specific network metrics identifying the attack and exposing all related information to the Anomaly Mitigation module.

3.4 Anomaly Mitigation

The Anomaly Mitigation module aims to neutralize identified attacks, inserting flow-entries in the flow table of the Open Flow switch (or modify existing ones) in order to block the desired malicious traffic.


51

A widely used and easy to be implemented method for the flow mitigation is the flow limiting in the OF Switch. In the picture depicted below can be visualized through Wireshark the flow traffic eliminated from the switch OF_1, IP address 10.1.7.45.

Fig.3.9 Wireshak: Flow limiting in the OF Switch


52

CHAPTER 4. CONCLUSIONS AND FUTURE WORK LINES

This chapter presents the conclusions and possible future improvements of the project. Moreover, are also described some aspects related with the ambient impact of the project.

4.1 Conclusions and results

This master thesis final project has been motivated by the growing globalization experienced by IoT applications that are covering a wide area of fields, such as energy efficiency, transport, home, health etc. As explained in the first chapter of this thesis, is proved that the IoT presents numerous benefits to consumers and to all types of cities, developed and emergent, from all over the world. IoT has the potential to change the ways that consumers interact with technology in fundamental ways and is likely to fusion the virtual and physical worlds together in ways that are currently difficult to grasp and imagine. From a security perspective, the predicted widespread deployment of sensors and sensing devices through a wide area, such as cars, homes, through the cities (managed by the cities municipalities), even the body – stances particular challenges. As physical objects in our everyday lives increasingly detect and share observations about us, consumers will likely want to interact with a secure environment. On the other side, IoT network administrators are handling with big challenge in terms of IoT network security due to the fast market deployment of heterogeneous IoT networks and missing mass research on the IoT security side. In this complete scenario surrounded by IoT market concerns and challenges related with security, the results obtained through the work developed in this master thesis are delivering a simple, detached and efficient security algorithm for IoT sensors networks for uses related with sensing of temperature and air pollution. Nevertheless, the Software-Defined Networking (SDN) is a viable alternative network architecture that allowed for programming the network and opening the possibility of creating a more efficient security application. This master thesis has been performed in the premises of CTTC, a research center located in Castelldefels (Spain). More exactly, the master thesis has been performed at the cloud/fog computing platforms and transport network of the ADRENALINE Testbed ®. In the context of evolving the capabilities of this testbed, my work has consisted in:

- The debugging of the Fog node and its SDN controller, which was quite unstable.

- The design of an overall architecture for the security application, which takes into account the several needed modules in order to properly analyse possible security threads.

- Design and validation of a simple algorithm (several have been studied) in order to validate the proposed application. The algorithm has been studied against a simulated security thread and its performance has been evaluated.


53

- Develop a security application which interacts with the Fog node SDN controller. Using a REST API, the flow statistics are read and analysed, using the previously validated algorithm.

The results obtained during the experimental process are valuable insights in which regards the election of the most proficient parameters (standard deviation and window supervision length) that ensure the efficiency of the algorithm. By knowing and implementing the most efficient parameters, it ensures the best effort of the algorithm and therefore is created a secure environment for the proposed testbed.

4.2 Future work lines

In terms of future improvements, is desirable to run the algorithm in an extended network (composed by more than 4 sensors) in order to test the efficiency of the algorithm and to make further improvements. Although the algorithm is efficient, when tested in the proposed testbed of the project, it could be the case that the algorithm will require further improvements in order to cope with the challenges encountered in the extended IoT network. Another further improvement of the security algorithm will be to extend the functionalities for other types of applications such as car sensor based networks, health sensor based networks, parking sensors, etc., that contain different types of sensors than the ones used in the testbed of this project. Added interesting future work line will be to analyse a different type of security architecture, as for example Generic Architecture Network Intrusion Detection System (ANIDS) described in section 1.1.3 IoT Security Architecture. This architecture contains a dedicated module for the anomaly detection, called Anomaly Detection Engine, that attempts to detect occurrence of any intrusion either online or offline. At a first glance, this architecture is more efficient in terms of anomaly detection due to the fact that it executes a pre-processing of the traffic before sending it to the detection engine. If the attacks are known, they can be detected using the misuse detection approach. On the other hand, unknown attacks can be detected using the anomaly-based approach based on an appropriate matching mechanism. In terms of improvement of anomaly detection it could be also studied others Anomaly Methods as for example K-means clustering algorithm that is an unified approach to cluster the data and identify the outliers. This approach has been studied for the implementation of the project security algorithm but the development of the programming algorithm it wasn’t realized due to the fact that it was considered more appropriate the implementation of the standard deviation algorithm. Anyhow, is worth to continue the development of this algorithm for further possible improvements of the security algorithm.

4.3 Environmental aspects

As explained in this Master Thesis, in the testbed of the project was used the fog concept, which brings the cloud computing at the edge of the network. The use of the fog computing delivers a faster response in terms of data stored in


54

the IoT database. Along with the fast testbed repose it is improved the energy use of the networks due to the fact that the fast network response is translated by a decrement of the energy used to obtain the query data.


55

Abbreviations and Acronyms

Acronym Description

ADC Analog to digital converter

ANIDS Architecture Network Intrusion Detection System

ARP Address Resolution Protocol

BOS bit Bit Oriented Signalling

BYOD Bring your own device

CTTC Centre Tecnològic Telecomunicacions Catalunya

DDos Distributed denial attack of service

DNS Domain Name System

ECP Explicit Congestion Notification

ICMP Internet Control Message Protocol

ISP Internet Service Provider

OF Open Flow

OVS Open Vswitch

ONOS Open Network Operating System

PAN Personal Area Network

PBB Provider Backbone Bridge

I-SID Backbone Service Identifier

MPLS Multiprotocol Label Switching

NIDS Network intrusion detection system RSPAN Remote Switch Port Analyser

WSN Wireless Sensors Networks

WAN Wide Area Network

SCTP Stream Control Transmission Protocol

SDN Software Defined Networking

SPAN Switched Port Analyser

TLS Transport Layer Security

VAN Virtualized application networks


56

Bibliography [1] Bonomi, Flavio, et al. "Fog computing and its role in the internet of things." Proceedings of the first edition of the MCC workshop on Mobile cloud computing. ACM, 2012. [1] Nadeau, Thomas D., and Ken Gray. SDN: software defined networks. O'Reilly Media, Inc., (2013). [2] Bhuyan, Monowar H., Dhruba Kumar Bhattacharyya, and Jugal Kumar Kalita. Network anomaly detection: methods, systems and tools. pp. 303-336 Communications Surveys & Tutorials, January 2014 [3] Li, Bingdong, et al. "A survey of network flow applications." Pp 567-581, Journal of Network and Computer Applications 36.2 (2013) [4] Abaid, Zainab, Mohsen Rezvani, and Sanjay Jha. "MalwareMonitor: An sdn-based framework for securing large networks." Proceedings of the 2014 CoNEXT on Student Workshop. ACM, (2014) [5] Giotis, K., et al. "Combining OpenFlow and sFlow for an effective and scalable anomaly detection and mitigation mechanism on SDN environments." Pp 122-136, Computer Networks 62 (2014) [7] Telefonica, “Trend Report. Insecurity in the Internet of Things”, pp 3-10, (2015) [8] R. Vilalta, A. Mayoral, R. Muñoz, R. Casellas, R. Martínez, Multi-Tenant Transport Networks with SDN/NFV, IEEE/OSA Journal of Lightwave Technology, Vol. 34, No. 8, April 2016. [9] R. Vilalta, A. Mayoral, D. Pubill, R. Casellas, R. Martínez, J. Serra, C. Verikoukis, R. Muñoz, End-to-End SDN Orchestration of IoT Services Using an SDN/NFV-enabled Edge Node , in Proceedings of the Optical Fiber Communication Conference and Exhibition (OFC), 20-24 March 2016, Anaheim, California (USA). [10] Seugwon Shin, Philip Porras, Vinod Yegneswaran, Martin Fong, “FRESCO: Modular Composable Security Services for Software Defined Networks”, ISOC Network and Distributed Security Symposium (2013) [11] Dr. Ovidiu Vermesan, Dr. Peter Friess, Internet of Things: Converging Technologies for Smart Environments and Integrated Ecosystems, River Publishess Alborg, 2013 [12] Dinesh Kumar Gupta , “A Review on Wireless Sensors Networks”, Network and Complex Systems , ISSN 2224-610x (Paper) [13] IoT Applications: http://www.libelium.com/top_50_iot_sensor_applications_ranking/


57

[14] OpenDayLight Project: https://www.opendaylight.org

[15] ONOS: http://onosproject.org

[16] Ryu: https://osrg.github.io/ryu/

[17] OpenFlow 1.3 switch specification: https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.3.0.pdf

[18] OpenFlow Switch Specifications, version 1.1.0 implemented, February 28, 2011: http://archive.openflow.org/documents/openflow-spec-v1.1.0.pdf

[19] SDN Architecture: https://www.opennetworking.org/sdn-resources/sdn-definition

[20] Aparicio Carraza, Julio Tax, Jose Reyes Alamo, “Building a Future in SDN with one Controller”, The City University of New York, https://openlab.citytech.cuny.edu/jreyesalamo/files/2012/08/Building-a-Future-in-SDN-with-one-Controller.pdf

[21] HP SDN VAN Controller: http://h17007.www1.hp.com/docs/networking/solutions/sdn/4AA4-8807ENW.PDF

[22] ITU-T Y.2060 (06/2012), Overview of the Internet of things.


58

Annex: Security algorithm #!/usr/bin/python import time import random import math TIME_WINDOW = 1 N_FLOWS = 5 T_MAX = 1000 * TIME_WINDOW flow_results_db = {} values_db = {} N_SIGMA =10 WINDOW = 10 #CHECK_PARAM='packets_per_second' CHECK_PARAM='bytes_per_second' ALGOERRORS = 0 ALGODECISIONS = 0 FLOWS = 0 BADFLOWS = 0 BADFLOWS_ERROR = 0 def create_bad_flow (percent=10) : return random.randrange(100) < percent def read_flows(T) : #print "reading flows" for i in range(0, N_FLOWS): #select if flow is ok or not base_pkts_sec = 20 if not create_bad_flow(): flow_results_db[i]['timestamp'].append( time.time() ) flow_results_db[i]['packets_per_second'].append( base_pkts_sec + random.randint( 0, i+4) ) flow_results_db[i]['bytes_per_second'].append( 100 * flow_results_db[i]['packets_per_second'][-‐1] ) flow_results_db[i]['bad_flow'] = False else: #print "Creating dangerous flows"


59

flow_results_db[i]['timestamp'].append( time.time() ) flow_results_db[i]['packets_per_second'].append( 2*( base_pkts_sec + random.randint( 0, i+4) ) ) flow_results_db[i]['bytes_per_second'].append( 150*flow_results_db[i]['packets_per_second'][-‐1] ) flow_results_db[i]['bad_flow'] = True #print "Flow: " + str(i) + " packets_per_second " + str(flow_results_db[i]['packets_per_second'][-‐1]) + " bytes_per_second: " + str(flow_results_db[i]['bytes_per_second'][-‐1]) #def mean function def mean(values): return sum(values)*1.0/len(values) #def standard deviation mean def stanDev(values): length=len(values) m=mean(values) total_sum=0 for i in range (0,length): total_sum+= (values[i]-‐m)**2 under_root=total_sum*1.0/length return math.sqrt(under_root) def check_flow(flow_id): global ALGODECISIONS, ALGOERRORS, FLOWS, BADFLOWS, BADFLOWS_ERROR ALGODECISIONS = ALGODECISIONS + 1 FLOWS+=1 result = False if CHECK_PARAM=='packets_per_second': #check pkts_per_sec result = check_flow_param(flow_id, 'packets_per_second' ) else: #check bytes_per_sec result = check_flow_param(flow_id, 'bytes_per_second' ) #evaluating algorithm if ALGODECISIONS >= WINDOW * N_FLOWS : if flow_results_db[flow_id]['bad_flow']: BADFLOWS += 1 print "Checking a bad flow" if (result != flow_results_db[flow_id]['bad_flow'] ):


60

print "ALGO OK" else: print "ALGO FAILED" ALGOERRORS = ALGOERRORS + 1 if flow_results_db[flow_id]['bad_flow']: BADFLOWS_ERROR = BADFLOWS_ERROR +1 print "ALGORITHM ERROR PERCENTAGE: " + str( ALGOERRORS * 100.0 / ALGODECISIONS ) + "%" if BADFLOWS > 1: print "BAD FLOWS NOT DETECTED PERCENTAGE: " + str( BADFLOWS_ERROR * 100.0 / BADFLOWS ) + "%" print "BAD FLOWS PERCENTAGE: " + str( BADFLOWS * 100.0 / FLOWS ) + "%" def check_flow_param(flow_id, param) : values = values_db[flow_id] #values = flow_results_db[flow_id][param][0:-‐1] print values if len(values) < WINDOW : print "Not checking. SMALL WINDOW. Adding: " + str(flow_results_db[flow_id][param][-‐1]) values_db[flow_id].append(flow_results_db[flow_id][param][-‐1]) return True #condicion print "Flow: " + str(flow_id) + " Current param " + param + " mean: " + str(mean(values)) + " stanDev: " + str(stanDev(values)) threshold_up = mean(values)+N_SIGMA*stanDev(values) threshold_down = mean(values)-‐N_SIGMA*stanDev(values) print "Flow: " + str(flow_id) + " Current param " + param + " value: " + str(flow_results_db[flow_id][param][-‐1]) + " threshold_up: " + str(threshold_up) + " threshold_down: " + str(threshold_down) if ( flow_results_db[flow_id][param][-‐1] > threshold_up ) or ( flow_results_db[flow_id][param][-‐1] < threshold_down ) : print "Security warning in Flow " + str(flow_id) + " parameter: " + param return False values_db[flow_id].pop(0)


61

values_db[flow_id].append(flow_results_db[flow_id][param][-‐1]) return True def process_flows(): for i in range(0, N_FLOWS): check_flow(i) if __name__ == '__main__': #print "SECURITY APP" T = 0 #INIT for i in range(0, N_FLOWS): flow_results_db[i] = { 'timestamp' : [], 'packets_per_second' : [], 'bytes_per_second' : [], 'bad_flow' : False } values_db[i] = [] #START FLOW LOOP while(T<=T_MAX): print "HI. Current time: " + str(T) read_flows(T) process_flows() #time.sleep(TIME_WINDOW) T += TIME_WINDOW

iot security final v1 9 - upcommonsupcommons.upc.edu/bitstream/handle/2117/84150/memoria.pdf ·...

Documents