Heartbleed: Making The Case For SDN

Vulnerabilities of Heartbleed's magnitude are rare. The security bug has its own website and logo. It's being discussed not only in security circles but across IT and beyond. Businesses are concerned. End users are concerned. Everyone is potentially impacted by this one, making it the most significant vulnerability in years.

Figure 1:

Eventually the chaos will subside and folks will start looking at how such vulnerabilities can be better mitigated in the future. At this point patches are rapidly becoming available and organizations will certainly apply those fixes as quickly as possible. But in the meantime, they -- and anyone interacting with them -- remain open to exploitation.

This leads to a serious question: how can organizations stop a heartbleed so they can get to the operating room to fix it permanently?

[What does the Heartbleed bug really mean for enterprises and end users? Read More Than A Half-Million Servers Exposed To Heartbleed Flaw.]

Certainly one option is to shut it all down -- pull the plug and eliminate the threat entirely. But business isn't likely to accept that as a viable solution. Going dark, especially in today's fickle consumer environment, isn't really an option. Businesses need to address the vulnerability while a more long-term fix is put into place.

If you've ever read the early documents published by the Open Networking Foundation (ONF) on the benefits of Software Defined Networks (SDN), you might recall that "experimental protocol" support was one. This capability was promoted as a way for organizations to insert support for new or experimental networking protocols into the network without having to wait for vendor implementations.

While this concept has been largely ignored by business and industry in general, the escalating concern over Heartbleed and how to mitigate such vulnerabilities provides ample reason to reevaluate programmability in the network -- not control plane APIs like OpenFlow or OpFlex, but in the network in the data path.

Heartbleed, at its core, is the exploitation of a protocol within a protocol RFC 6520 describes an extension to the TLS/DTLS transport protocol which is commonly referred to as the "heartbeat extension." Implementation in vulnerable versions of OpenSSL don't effectively ensure that the only data returned is the heartbeat data; instead it ends up sharing a significant amount of other data, including passwords, private keys, and even confidential corporate data.

The problem is that it exploits the protocol. A software-defined architecture should insert a new protocol handler and stop the request in its tracks before it ever gets to a vulnerable server in the first place.

But that would require an architecture that doesn't yet exist. Existing SDN architectures enable northbound applications that could ostensibly provide this functionality, but no such solution exists today. It would require development, which takes as much time as delivering on a patch to permanently address the problem.

The concept, however, is valid. Programmable data path elements could allow organizations to immediately implement a handler in the network that identifies and rejects the offensive protocol request. Programmability in the data path -- whether enabled through a northbound SDN application or through the capabilities of an existing SDN data path element -- would provide immediate triage and mitigation and give companies the time they need to deploy a permanent solution.

SDN is still maturing, and the benefits of programmable data path elements as part of the larger architecture have been dwarfed by the operational benefits of software-defined control planes for automation and orchestration. But Heartbleed reminds us that the ability to programmatically adapt network behavior to the protocols and payloads being transported should not be dismissed.

The NSA leak showed that one rogue insider can do massive damage. Use these three steps to keep your information safe from internal threats. Also in the Stop Data Leaks issue of Dark Reading: Technology is critical, but corporate culture also plays a central role in stopping a big breach. (Free registration required.)