Post on 02-Aug-2020
Towards Secure and Dependable So2ware-‐Defined Networks
Diego Kreutz, Fernando M. V. Ramos, Paulo Veríssimo LaSIGE/FCUL, University of Lisbon
SDN in short 1. Decoupling control
and data plane
2. Logical centraliza?on of network control
3. Programming the network
Excellent, now we can program the network!
Applications (control logic)
Network OS (programming abstractions, data distribution, low level controls, etc.)
App1 App2 App3 … AppN
Global Network View
Wait, now others can program the network!
Applications (control logic)
Network OS (programming abstractions, data distribution, low level controls, etc.)
App1 App2 App3 … AppN
Global Network View
Outline
Main threat vectors in SDNs
Security & Dependability by design
Final remarks
Outline
Main threat vectors in SDNs
Security & Dependability by design
Final remarks
Data Plane!
Control & Mana
gement!
SDN device
SDN device
SDN device
Admin StaMon SDN
Controller
SDN device
1
Not specific to SDNs, but can be a door for augmented DoS aNacks.
Possible solu*ons: IDS + rate bounds for control plane requests
Threat vectors map
Threat vector 1 forged or faked traffic
flows
Data Plane!
Control & Mana
gement!
SDN device
SDN device
SDN device
Admin StaMon SDN
Controller
2 SDN device
Not specific to SDNs, but now the impact is potenMally augmented.
Possible solu*ons: so2ware aNestaMon with autonomic trust management
Threat vectors map
Threat vector 2 exploiMng vulnerabiliMes in forwarding devices
Data Plane!
Control & Mana
gement!
SDN device
SDN device
SDN device
Admin StaMon
3
SDN Controller
SDN device
Specific to SDNs: communicaMon with logically centralized controllers can be explored.
Possible solu*ons: threshold cryptography across controller replicas
Threat vectors map
Threat vector 3 aNacking control communicaMons
Data Plane!
Control & Mana
gement!
SDN device
SDN device
SDN device
Admin StaMon
4
SDN Controller
SDN device
Specific to SDNs, controlling the controller may compromise the enMre network.
Possible solu*ons: replicaMon + diversity + recovery
Threat vectors map
Threat vector 4 exploiMng vulnerabiliMes
in controllers
Data Plane!
Control & Mana
gement!
SDN device
SDN device
SDN device
Admin StaMon
5
SDN Controller
SDN device
Specific to SDNs, malicious applicaMons can now be easily developed and deployed on controllers.
Possible solu*ons: so2ware aNestaMon, security domains
Threat vectors map
Threat vector 5 lack of trust between the
controller and apps
Data Plane!
Control & Mana
gement!
SDN device
SDN device
SDN device
Admin StaMon
6
SDN Controller
SDN device
Not specific to SDNs, but now the impact is potenMally augmented.
Possible solu*ons: double credenMal verificaMon
Threat vectors map
Threat vector 6 exploiMng vulnerabiliMes
in admin staMons
Data Plane!
Control & Mana
gement!
7
SDN device
SDN device
SDN device
Admin StaMon SDN
Controller
SDN device
Threat vector 7 lack of trusted resources
for forensics and remediaMon
Not specific to SDNs, but it is sMll criMcal to assure fast recovery and diagnosis when faults happen.
Possible solu*ons: immutable and secure logging, secure and reliable snapshots
Threat vectors map
Data Plane!
Control & Mana
gement!
7
SDN device
SDN device
SDN device
Admin StaMon
6 5
4
3
SDN Controller
2 SDN device
1
Seven main threat vectors Ø 1 and 3: communicaMons Ø 2, 4, 5, 6: elements Ø 7: communicaMons and elements
Threat vectors map
Outline
Main threat vectors in SDNs
Security & Dependability by design
Final remarks
Sec&Dep tools to consider • ReplicaMon
– Dynamic device associaMon – Self-‐healing mechanisms for perpetual operaMon
• Diversity
– Avoid shared, common vulnerabiliMes
• (Autonomic) trust – between controllers and devices – between applicaMons and controller so2ware
vulnerable systems
exploiMng a vulnerability
• Security domains – kernel mode vs user mode
• Fast and reliable so2ware update and patching
Sec&Dep tools to consider
(e.g., HotSwap)
(e.g., FortNOX)
DESIGN OF A SEC&DEP SDN CONTROL PLATFORM v0.1
Controller A
App A
One single centralized controller
Controller B
App A
Controller C
App A
Controller A
App A
Mul?ple instances of a centralized controller
Controller B
App A
Controller C
App A
Controller A
App A
Master-‐slave controllers
Controller B
App A
Controller C
App A
Controller A
App A
Master-‐slave controllers (what if B fails?)
Controller B
App A
Controller C
App A
Controller A
App A
East/Westbound API (data distribution service)
Master-‐slave controllers (adding a consistency layer)
Controller B
App A
Controller C
App A
Controller A
App A
East/Westbound API (data distribution service)
Mul?ple ac?ve controllers
Controller B Controller C Controller A
One single app instance (App B) can now configure the whole network
East/Westbound API (data distribution service)
App A App A App A App B
Controller B Controller C Controller A
One single app instance (App B) can now configure the whole network
East/Westbound API (data distribution service)
App A App A App A App B
Northbound API Northbound API Northbound API
App A
Controller A Controller B Controller C
Increasing the robustness of the system by adding diversity
East/Westbound API (data distribution service)
App A App A App B
Northbound API Northbound API Northbound API
Controller B
App A
Controller C
App A
Controller A
App A App B
Common Northbound API
Diversity of controllers requires a common Northbound API
East/Westbound API (data distribution service)
Outline
Main threat vectors in SDNs
Security & Dependability by design
Final remarks
Our main message • SDN: a fascinaMng dilemma
– evolu?on of networking versus
– increasing the threat surface
Security & Dependability should be built by design.