The boom of hybrid cloud, BYOD and private virtual clouds are upon us, and as the use of bandwidth-intensive enterprise applications spiking, many large players are spearheading the adoption of Software Defined Networks (SDN) for flexibility, availability and performance. After all the initial skepticism was put to rest, it is quite clear that SDN is here to stay. But the pressing issue seems to be the protection of its dynamic potentiality from compromise.
SDNs present completely new ways of building services and defining architecture. In the last two years, many organizations have been adopting network virtualization using standards and facilitating technology like OpenFlow which lets them configure the network to fit any kind or size of traffic. In SDN, the Data Plane responsible for forwarding traffic is now physically separated from the Control Plane which is typically moved to a dedicated application hosted on a servicing agent. The Control Plane is like the brain of the network and therefore provides centralized view and control of networked devices. Due to the sweeping control it enables, many SDN applications are designed to offer protection against DDoS-based flooding aimed at the Data Plane Layer. But unsecure configuration of these applications and protocol features can still affect resilience. A higher risk factor you need to pay attention to is DDoS attacks directly on the SDN stack or in other words, the Controller Layer.
The open, software-based To fully grasp the gravity of an attack on the Software Defined Network Controller, compare it to a viral infection that affects the central nervous system of the human body. When the Controller is infected, all sensitive networked assets stand in the line of impact. Attacks on availability get a high mileage.
Managing SDN environments? Here’s how you can harden them:
Fortify SDN Controllers with risk-based security measures
Access to the Controller stack gives an attacker access to policies and programmability via both northbound and southbound APIs which he can leverage to alter data flows. Identifying and resolving suspicious events becomes a lot more rapid owing to the centralized monitoring that enables easier isolation of threat agents to cull attacks from spreading across the infrastructure. Attacks on this layer are aimed at obstructing response of the controller to data layer units. DoS attacks take advantage of the fact that Controllers in production environments are deployed on widely-used, unhardened operating systems known to have zero-day bugs and the situation is worsened by the use of default passwords perhaps to avoid disruptions to performance. So what we have is a vulnerable controller in production – the perfect loophole for a hacker looking to build a rogue controller that he could use to supply his own flow table controls, while being perfectly concealed.
Basic protection mechanisms for the control plane must include Access and Privilege Management. OS hardening and patch management go without saying but what needs attention is the rising need for protecting mission-critical systems which can only be addressed using continuous infrastructure monitoring. Look for a real-time threat management platform that is built for the SDN control plane of your virtual private clouds. Such tools can provide an extensive, universal view of data center operations. Apart from the management GUI, you may have network applications and services using Open APIs to communicate with the controller platform. These include DDoS prevention tools, and network management tools like OpenStack. Install an SIEM solution within the environment and bring in your IAM and access control audit trail logs to realize the benefits of behavior-centric, host-based threat detection. Ensure centralized visibility to keep an eye on myriad issues such as authenticity of resource access, system provisioning with risks of arbitrary execution, log flow disruptions and memory overloads.
Rule out Protocol Implementation Flaws
As mentioned earlier, SDN applications are being beefed up with capabilities to detect and thwart attempts to forge data flows into routers’ flow tables. However, even with the use of preventive technology, things could go wrong if a data center administrator were to insecurely implement a protocol such as OpenFlow or OVSDB. In that case, it creates an inherent weakness because spoofed traffic could pass off as legitimate traffic. If an attacker finds a way to mess with the data flow instructions passed via southbound APIs from the Controller to routers, he would create a new data flow to bypass the original command which steers the traffic into a gateway firewall before entering the network. He would then have a dramatic advantage. The situation entails better discipline in the implementation of data transit encryption. The Controller usually communicates with the Data Plane through TLS channels and it is important to use available security options and attributes to adequately set up authentication between network devices and Controller to avoid interception and spoofing.
Depending on the protocol used for southbound links, there may be additional options to secure the data flow using nonce and secret-sharing to prevent replay attacks and flooding.
Secure Northbound links to Applications (The SDN Layer)
The interface of the SDN management console could be home to a number of vulnerabilities which could let an attacker or a spoofer gain sensitive, security-compromising details of the environment. Fundamental security is achieved by implementing an appropriate level of transport security using TLS, secure shell, etc. Use REST APIs and invoke services in a secure manner, validating authorization and identity.
Adopt secure coding practices just as you would for web applications. Finally, equip the SDN system with adequate configuration analysis and inconsistency filtering for flow tables and set up log monitoring which comes ensures most rapid anomaly detection.