Download as PDF, PPTX
SDN Security Talk - (ISC)2_3
- 1. Security in SDN AnIntroduction Wen-Pai Lu, Ph.D. Luxoft July 14, 2015 (ISC)2 Silicon Valley
- 2. Agenda • Status ofNetworks – How they evolve? • Why SDN? • What is SDN? • SDN Threat Analysis • Deep Dive at each Layer … • How SDN can Help to Enhance Security • Conclusion
- 3. STATUS OF NETWORKSTODAY – HOW THEY EVOLVE
- 4. Network Today • Networksused to be simple: switches, routers, LAN, protocols, switching, routing, etc. • Add more switches, routers and networks increases the complexity because of multiple regions, domains, routing exchanges, loop avoidance, etc. • Changes in routers/switches, links, etc. takes time to converge • Add new elements requires careful configurations • Networks are static and cannot adapt to today business demands
- 5. More Complex inthe Networks • New and more controls required in the networks -> increase complexity – Traffic Engineering – QoS – VLANs – ACLs – MPLS, BGP, etc. – Appliances • Firewall • NATs • DPI • Load Balancer • middlebox • Etc. • The protocols are added to solve specific problems and they deployed independently
- 6.
- 7. Key to InternetSuccess: Layers Applications …built on… …built on… …built on… …built on… Reliable (or unreliable) transport Best-effort global packet delivery Best-effort local packet delivery Physical transfer of bits Source: Scott Shenker: The Future of Networking, and the Past of Protocols
- 8.
- 9. What are theProblems • Today’s network architecture cannot meet the demand of users, enterprises and carriers • Complexity in the Network – Protocols are defined in isolation – Networks are relatively static – VM migration challenges many aspects of traditionally networking – Network cannot dynamically adapt to changing traffic applications and user demands • Inconsistent Policies – Difficult to apply a consistent set of access, security, QoS and other policies • Inability to Scale – Scaling challenges based on unpredictable traffic pattern – Multi-tenancy and customized performance control/on-demand delivery • Vendor Dependence – Vendor product cycle – Lack of standards and open interfaces
- 10. What are intoday’s networks and Vendor Equipment? • Many Complex Functions embedded in the networks • Routing (OSPF, BGP, etc.) • MPLS • Metro Ethernet • Layers 2 and 3 • Multicast • Differentiated Services • Traffic Engineering • QoS • Security (NAT, Packet Filtering, IPSec, etc.) Million of lines of source code Billions of gates Specialized Packet Forwarding Hardware Operating System Feature Feature Routing, Switching, Device Management, Access Control, Packet Filtering, VPN, Mobility Management, etc. Adapting to dynamic changes in the network is very challenging
- 11.
- 12. SDN • “Software DefinedNetworking” • Original works were done at UC Berkeley and Stanford Universities (2006) • Software – Abstracted and virtualized IT infrastructure resources managed by “Software” via API invocations • Defined – Applications automatically “defined” infrastructure requirements, configuration and service level expectation • Networking – Infrastructure is fully programmable to rapidly deploy workloads on optimal resources and to instantly respond to changing business demands • Networks becomes abstract resources
- 13. SDN Principles • SeparateControl Plane and Data Plane Entities • Execute or run Control Plane software on general purpose hardware • Centralized network states and intelligence • Have programmable Data Plane – Maintain, control and program Data Plane state from a central entity • Data Plane also run on the commodity hardware (White Box server or Switches) • An architecture to control not just a networking device but an entire network.
- 14. SDN Architecture The controland data planes are decoupled, network intelligence and state centralized, and the underlying network infrastructure is abstracted from the applications SDN Orchestration Tools SDN Controller OpenFlow Switches
- 15. What is OpenFlow •Myth: SDN is OpenFlow and vice versa • OpenFlow is a standard communications interface defined between the control and forwarding layers of an SDN architecture • Allows direct access to and manipulation of the forwarding plane of network devices, both physical and virtual • Overlay network protocols without disrupting underlying fabrics • Attractive in many environments – Dynamic infrastructure as a service – Made networking behave like software
- 16. Basic OpenFlow Architecture Controller OpenFlowSwitch Flow Table Secure Channel Compute Device OpenFlow Switch specification
- 17. SDN (OpenFlow) Controller Manages one or more switch via OpenFlow channels. Uses OpenFlow protocol to communicate with a OpenFlow aware switch. Acts similar to control plane of traditional switch. Provides a network wide abstraction for the applications on north bound. Responsible for programming various tables in the OpenFlow Switch. Single switch can be managed by more than one controller for load balancing or redundancy purpose. In this case the controller can take any one of the following roles. Master. Slave. Equal. 17
- 18. OpenFlow Channel Usedto exchange OpenFlow message between switch and controller. Switch can establish single or multiple connections to same or different controllers (auxiliary connections). A controller configures and manages the switch, receives events from the switch, and send packets out the switch via this interface The OpenFlow channel is a TLS/TCP connection. Switch and controller mutually authenticate by exchanging certificates signed by a site-specific private key 18
- 19. OpenFlow Network Element(Switch) Run on Commodity Hardware Consists of one or more flow tables, group table and meter table. A single switch can be managed by one or more controllers. The flow tables and group table are used during the lookup or forwarding phase in order to forward the packet to appropriate port. Meter table is used to perform simple QOS operations like rate-limiting to complex QOS operations like DiffServ etc 19
- 20. 7/15/2015 Security inSDN 20
- 21. Pipeline Processing 21 * FigureFrom OpenFlow Switch Specification
- 22. Control Program AControl Program B Network OS OpenFlow Forwarding Abstraction Packet Forwarding Packet Forwarding Packet Forwarding Flow Table(s) “If header = p, send to port 4” “If header = ?, send to me” “If header = q, overwrite header with r, add header s, and send to ports 5,6” 7/15/2015 Security in SDN 22
- 23. SDN Benefits • CentralizedControl of Multi-vendor environment • Reduced complexity through automation • Efficiency with applications, services and infrastructure optimizations • Higher Rate of Innovation – Create and deliver new types of applications and services and business model • Scale with rapidly growing of existing applications and services • Increase Network reliability and Security • More Granular Network Control • Better User experiences
- 24.
- 25. Security Concerns • Technologyis new and immature • SDN was not designed with Security in mind • Required proprietary customization for each implementation • Virtual Sprawl” – automated creation of virtual networks, each has its own security needs • Network segment is created without security team knowledge • Software vulnerabilities
- 26. Categorization of theSecurity Issues… Source: Scott-Hayward, S., O’Callaghan, G. and Sezer, S. “SDN Security: A Survey” IEEE SDN4FNS, November 2013
- 27. Source: Scott Hogg,“SDN Security Attack Vectors and SDN Hardenings” http://www.networkworld.com/article/2840273/sdn/sdn-security-attack-vectors-and-sdn-hardening.html
- 28. Data Plane Control &Management 7 SDN device SDN device SDN device Admin Sta on 6 5 4 3 SDN Controller SDN control protocol (e.g., OpenFlow ) Management connec on (e.g., SSH ) 2 Data plane physical / logical connec ons SDN device 1 Source: Diego Kreutz, Fernando Rammos and Paulo Berissimo, “Towards Secure and Dependable Software-Defined Networks”
- 29. Data Plane Control &Management 7 SDN device SDN device SDN device Admin Sta on 6 5 4 3 SDN Controller SDN control protocol (e.g., OpenFlow ) Management connec on (e.g., SSH ) 2 Data plane physical / logical connec ons SDN device 1 Threat vector 1 forged or faked traffic flows Not specific to SDNs, but can be a door for augmented DoS attacks. Possible solutions: IDS + rate bounds for control plane requests
- 30. Data Plane Control &Management 7 SDN device SDN device SDN device Admin Sta on 6 5 4 3 SDN Controller SDN control protocol (e.g., OpenFlow ) Management connec on (e.g., SSH ) 2 Data plane physical / logical connec ons SDN device 1 Threat vector 2 attacks on vulnerabilities in switches Not specific to SDNs, but now the impact is potentially augmented. Possible solutions: sw/hw attestation with autonomic trust management
- 31. Data Plane Control &Management 7 SDN device SDN device SDN device Admin Sta on 6 5 4 3 SDN Controller SDN control protocol (e.g., OpenFlow ) Management connec on (e.g., SSH ) 2 Data plane physical / logical connec ons SDN device 1 Threat vector 3 attacks on control plane communication Specific to SDNs: communication with logically centralized controllers can be exploited. Possible solutions: threshold cryptography across controller replicas
- 32. Data Plane Control &Management 7 SDN device SDN device SDN device Admin Sta on 6 5 4 3 SDN Controller SDN control protocol (e.g., OpenFlow ) Management connec on (e.g., SSH ) 2 Data plane physical / logical connec ons SDN device 1 Threat vector 4 attacks on and vulnerabilities in controllers Specific to SDNs, controlling the controller may compromise the entire network. Possible solutions: replication + diversity + recovery
- 33. Data Plane Control &Management 7 SDN device SDN device SDN device Admin Sta on 6 5 4 3 SDN Controller SDN control protocol (e.g., OpenFlow ) Management connec on (e.g., SSH ) 2 Data plane physical / logical connec ons SDN device 1 Threat vector 5 lack of mechanisms to ensure trust between the controller and management apps Specific to SDNs, malicious applications can now be easily developed and deployed on controllers. Possible solutions: sw attestation with autonomic trust management
- 34. Data Plane Control &Management 7 SDN device SDN device SDN device Admin Sta on 6 5 4 3 SDN Controller SDN control protocol (e.g., OpenFlow ) Management connec on (e.g., SSH ) 2 Data plane physical / logical connec ons SDN device 1 Threat vector 6 attacks on and vulnerabilities in admin stations Not specific to SDNs, but now the impact is potentially augmented. Possible solutions: double credential verification
- 35. Data Plane Control &Management 7 SDN device SDN device SDN device Admin Sta on 6 5 4 3 SDN Controller SDN control protocol (e.g., OpenFlow ) Management connec on (e.g., SSH ) 2 Data plane physical / logical connec ons SDN device 1 Threat vector 7 lack of trusted resources for forensics and remediation Not specific to SDNs, but it is still critical to assure fast recovery and diagnosis when faults happen. Possible solutions: indelible logging
- 36. LET’S LOOK ATEACH LAYER ABOUT THE SECURITY
- 37. OF Network Devices– Data Plane • Software Code Vulnerabilities – Unstable code – Bad Code • Malicious code attacks • DDoS attacks • Target network devices from within the network itself • Rouge OF network devices • Inject undesired network information to the controller
- 38. Communication Channels • OpenFlowchannel defined SSL/TLS, but not mandatory • Authentication between the controller and the OF devices • DDoS Attacks – keep the link saturated
- 39. Control Plane • Needsprotection of the control plane and manage authorization of access and network applications • Need to authenticate application access to control plane • Network should service business applications needs, and business logics dictate how security is applied
- 40. Controller • Secure theController • Compromising this controller gives the attackers command of the entire network • DDoS attacks to the controller • Bogus Controller can change the network topology • Strong authentication mechanism for SDN Controller access • Controller Integrity
- 41. Northbound API toApplications • Not define as standard yet, thus incompatibilities may cause security holes • Every controller has its own set of APIs • Authentication to the applications • Programmable northbound interfaces require their own security policy framework, governance, management, … these opens up a log of very difficult to answer questions • Communication path is not secure
- 42. Applications Layer –SDN layer • No authentication mechanism for Applications • Need to protect authenticated application from attacks • Applications can change how network functions • May lack of secure coding practices • Integrity of applications • If policy is not synchronized, network operations and functions could be disrupted • Applications may not have any idea of security policies
- 43. HOW SDN CANHELP TO IMPROVE SECURITY
- 44. Security Benefits • SDNcan help provide greater security without increasing management headache for complex virtual networks in data center. • SDN can boost security by routing traffic, as appropriate, through a central next-generation firewall and intrusion prevention system • SDN can also dynamically reprogramming and restructuring a network that is suffering a distributed denial-of-service attacks • SDN can also provide capabilities such as automatically quarantining an endpoint or network that has been infected with malware
- 45.
- 46.
- 47. Summary • The Technologyis still new and evolving • A lot of promises with many powerful capabilities, but… • Security was not Considered in the Original Design • Security Issues remains real in SDN (prevent organizations to deploy SDN) • SDN can be an Improvement of Security of Networks