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.
