© F

rau

nh

ofe

r-G

esel

lsch

aft

20

16

Improving Network Security by SDN – OrchSec and AutoSec Architectures

Dr.-Ing. Kpatcha BayarouHead of Mobile Networks, Fraunhofer Institute for Secure Information Technology SIT

04. – 09. September 2016, Dagstuhl Seminar 16361Network Attack Detection and Defense - Security Challenges and Opportunities of SDN

– 2 –

© F

rau

nh

ofe

r-G

esel

lsch

aft

20

16

Contents

Motivation

Security for SDN

Security by SDN

OrchSec Architecture

AutoSec Architecture

Ongoing work

SDN to improve Industrie 4.0 Security

Take away

SDN Security

– 3 –

© F

rau

nh

ofe

r-G

esel

lsch

aft

20

16

SDN SecurityMotivation

According to the statistics of Deutche Telekom1, the number of attackers have been increased from 100K to 550K in the last year

Is SDN mature enough in terms of security to protect networks from those attackers?

Can SDN be used to detect and mitigate

the attacks?

An SDN architecture consists of

Control Plane

Data Plane

South Bound Interface (SBI) using

protocols such as OpenFlow

North Bound Interface (NBI)

1 http://www.sicherheitstacho.eu/statistics?lang=en

– 4 –

© F

rau

nh

ofe

r-G

esel

lsch

aft

20

16

SDN SecurityOur contributions

We categorized SDN security research in two types

Security for SDN to improve the security of SDN architectures, protocols, controllers, etc.

e.g. OpenDayLight, ONOS, …

Security by SDN to improve network security based on SDN.

We propose two solutions/approaches

OrchSec is used to detect and mitigate network attacks automatically

AutoSec pre-configures the security of the client computers and the network devices to protect networks against the attackers

– 5 –

© F

rau

nh

ofe

r-G

esel

lsch

aft

20

16

SDN Security

Simple networks with independent components

Component wise configuration, performance measurement, and monitoring

Higher complexity through missing centralization

No co-operation between components

Why Security by SDN?

Classical Networks

– 6 –

© F

rau

nh

ofe

r-G

esel

lsch

aft

20

16

SDN SecurityWhy Security by SDN?

Network Monitoring

Introduction of central Monitoring, for example with sFlow (specified in 2001)

Monitor maintains Counter: Number of packets per connection

...and samples of traffic: A small portion of the traffic goes to the Monitor as a copy

– 7 –

© F

rau

nh

ofe

r-G

esel

lsch

aft

20

16

SDN SecurityWhy Security by SDN?

SDN Controller

Central configuration of the components, through OpenFlow (Version 1.0 in 2009)

Defines Flow Rules, which control how packets will be forwarded

– 8 –

© F

rau

nh

ofe

r-G

esel

lsch

aft

20

16

SDN SecurityWhy Security by SDN?

Attacks

Attacks must be recognized and mitigated manually

Some hardware provide local defense mechanisms, which are not recognized by the rest of the networks

Neither updatable nor programmable

Monitoring can only detect the attacks

Administrators are informed and must be acted upon for mitigation

Simple Examples: Denial-of-Service (DoS) through Flooding

– 9 –

© F

rau

nh

ofe

r-G

esel

lsch

aft

20

16

SDN SecurityWhy Security by SDN?

Classical Counter Measures

Immediate remedy is necessary before other parts of the network get affected

For example, applying a NULL-Route

Disadvantages: Target is Offline: The attack is successful!

Collateral damage: Only one service was attacked, but all services at the targeted IP are offline

Especially critical when VMs are in operation(Shared Hosting, Cloud)

Router discards all of the traffic to the target

Target computer is put back into operation

Wait until attack is over

– 10 –

© F

rau

nh

ofe

r-G

esel

lsch

aft

20

16

SDN SecurityWhy Security by SDN?

Security Through SDN

With SDN, it is possible to act quickly and exactly

Controller inserts the rules for dropping only the attacker's packets

SDN can filter by source IP, port number etc. to avoid collateral damage

Filters earlier: Traffic is dropped on Switch instead of Router

Disadvantages: Manual defense.

– 11 –

© F

rau

nh

ofe

r-G

esel

lsch

aft

20

16

SDN Security

OrchSec connects Network Monitor and SDN Controller:

Automatic and therefore faster response to attacks

Analysis of Monitored Events

Insertion of Flow Rules

Fully programmable via Apps

Security by SDN - OrchSec

– 12 –

© F

rau

nh

ofe

r-G

esel

lsch

aft

20

16

SDN SecuritySecurity by SDN – OrchSec

Attack Detection Definition

OrchSec Apps insert attack threshold (detection definition) on Network Monitor

For example, how many ICMP- Packets trigger a Ping Flood Suspicion

– 13 –

© F

rau

nh

ofe

r-G

esel

lsch

aft

20

16

SDN SecuritySecurity by SDN – OrchSec

Attack Detection

In case of an attack, this threshold is exceeded

Orchestrator is informed

App initiates an analysis

– 14 –

© F

rau

nh

ofe

r-G

esel

lsch

aft

20

16

SDN SecuritySecurity by SDN – OrchSec

Attack Analysis

App asks for a portion of the traffic from the Controller

For example, all ICMP-Packets from Switch A, received on Port 1

– 15 –

© F

rau

nh

ofe

r-G

esel

lsch

aft

20

16

SDN SecuritySecurity by SDN – OrchSec

Mitigation Mechanism

App determines the attacker and attack type, and instructs the Controller to drop attacker traffic at the switch

Exact analysis offers the best match rules for filtering

Minimization of collateral damage

– 16 –

© F

rau

nh

ofe

r-G

esel

lsch

aft

20

16

SDN SecuritySecurity by SDN – OrchSec

Advantages and Features

Modular, programmable security solution:

Adjustable to fulfill individual requirements

Independent of the Hardware-Vendor through standard protocols

Possibility of buying external modules or implementing own ideas

Security, Load-Balancing, Monitoring, Reporting, Access Control

Our current solutions:

Flooding: ICMP, TCP, UDP

DNS-Amplification, ARP Poisoning,

HTTP Slow Read

– 17 –

© F

rau

nh

ofe

r-G

esel

lsch

aft

20

16

SDN Security

OrchSec is extended to ensure that the security of the end-nodes (clients and servers) conform to policy before giving the access to the network

AutoSecSDN-App contains security policies (for example, all communication from a particular client/application must be encrypted)

Security by SDN - AutoSec

– 18 –

© F

rau

nh

ofe

r-G

esel

lsch

aft

20

16

SDN Security

AutoSecSDN-Configuration-Protocol was developed for the configuration task

1. The client sends the

configuration request to the

controller which contains

Source IP, Destination IP, Source

Port, Destination Port, and the

Protocol

Security by SDN – AutoSec Configuration

– 19 –

© F

rau

nh

ofe

r-G

esel

lsch

aft

20

16

SDN Security

AutoSecSDN-Configuration-Protocol was developed for the configuration task

2. The configuration reply is sent by the

the controller to the client and the

server which contains Source IP,

Destination IP, Source Port,

Destination Port, Protocol,

Configuration-ID, Error Code

Security by SDN – AutoSec Configuration

– 20 –

© F

rau

nh

ofe

r-G

esel

lsch

aft

20

16

SDN Security

AutoSecSDN-Configuration-Protocol was developed for the configuration task

3. The controller initiates the installationof the flow rules on the SDN switches

Security by SDN – AutoSec Configuration

– 21 –

© F

rau

nh

ofe

r-G

esel

lsch

aft

20

16

SDN Security

AutoSecSDN-Configuration-Protocol was developed for the configuration task

4. The clients and the server

download the security mechanisms

from the repository

Security by SDN – AutoSec Configuration

– 22 –

© F

rau

nh

ofe

r-G

esel

lsch

aft

20

16

SDN Security

Now, the client and the server can communicate securely as they conform to the security policies

Security by SDN – AutoSec

– 23 –

© F

rau

nh

ofe

r-G

esel

lsch

aft

20

16

SDN Security

In the next industrial evolution like Industrie 4.0, the production machines and components will be accessed by the Internet

Production networks provides new requirements

They use real-time protocols such as Ethernet/IP, EtherCAT, Modbus, Profinet, etc.

Availability must be guranteed

IDS/IPS based on office network may not be suitable to fulfill those requirements

We are designing SDN-based IDS for Industrie 4.0

Security by SDN – Industrial Internet

– 24 –

© F

rau

nh

ofe

r-G

esel

lsch

aft

20

16

SDN Security

SDN Security research are categorized into two types – Security by SDN and Security for SDN

Security for SDN

We analyzed the security of SDN architectures, protocols, etc. and suggested protection mechanisms to be activated before using in production environment

Security by SDN

OrchSec was developed to detect and mitigate different types of attacks automatically

AutoSec was designed to configure end-nodes so that they conform to security policies

Currently, we are building Industrial IDS for Industrie 4.0

Take Away Messages

– 25 –

© F

rau

nh

ofe

r-G

esel

lsch

aft

20

16

Dr.-Ing. Kpatcha Bayarou

Fraunhofer Institute forSecure Information Technology SIT

Mobile Networks

www.sit.fraunhofer.de

Rheinstrasse 75, 64295 Darmstadt

kpatcha.bayarou@sit.fraunhofer.de