SDN Heartbleed

By Tony Clark, 2-Dooz Inc. – April 30, 2014

By now everyone has heard of Heartbleed, a previously overlooked (and some suspect purposely undisclosed) software bug in the widely used OpenSSL implementation.  Heartbleed is a serious flaw.  However, it is hardly unique.  Coding errors, which create hard to detect security holes, have been around for as long as software has been.  What the Heartbleed bug reminds us of is that threats to cyber systems are not limited to software virus exploits.  Additionally, it signals an alarm that such errors will accompany and will present important challenges to efforts to secure next generation programmable networks such as SDN.

Among its uses, OpenSSL provides encrypted communications tunnels between a sender and a receiver within a data network such as the Internet.  Such connections secure credit card transactions and in virtual private networks (VPN) protect sensitive corporate and personal data from prying eyes. 

Without going into too much technical detail, the Heartbleed flaw enables the theft of passwords and other sensitive data which are supposed to be protected in an OpenSSL tunnel.  In this case, the bug produces an operating state, which was not anticipated by the designers and implementers of OpenSSL; resulting in an opening that can be quietly exploited by malicious hackers.

Almost certainly, software bugs—similar to Heartbleed in terms of their unexpected, incorrect behavior—will be present in SDNs.  Ironically, the enhanced programmability of SDNs will result in a greater level of network vulnerability—presenting new and more highly targeted security challenges. 

Consider the case of a network controller, which has a bug that allows a network operator's password on the controller to be observed.  This is similar to the Heartbleed flaw and is an example of SDN eavesdropping.  Once the password is in the hands of a malicious user, such a user could secretly log into the aforementioned network controller (i.e., into the SDN control layer) and covertly reprogram, or reconfigure the controller to instruct the network elements in the infrastructure layer to behave in an undesired manner. 

More specifically, the malicious user could instruct the SDN to greatly reduce the amount of network bandwidth that is available to one or more important servers.  In the case of a financial services company, for example, these servers might be providing real-time information to customers who are using the company's online trading platform.  As a result of the narrowed paths to the servers, customers could experience extremely slow market pricing updates, which, in turn, could make the financial services company’s trading platform virtually unusable.  If this occurs during a particular heavy stock volume trading day, one can imagine that the affected customers would be irate—especially if trades that they had wanted to make are no longer possible.

Enabled by a Heartbleed type bug, the above example is a new type of denial of service attack that is technically possible within SDNs.  And, as such attacks could be more surgical and harder to detect, their affect could be more impactful and more devastating.  Because of this, SDN vendors must more urgently work to develop effective countermeasures to SDN eavesdropping.  

The Heartbleed bug has raised the awareness of the security vulnerabilities that are inherent in these types of flaws.  Pre-warned, potential customers will rightfully demand that SDN vendors take sufficient steps to ensure that such exploits can quickly be contained with minimal damage.

Those are my thoughts.  As always, I invite and look forward to learning what you think.

©2014 2-Dooz| Privacy | Siteuse