INFRASTRUCTURE

Heartbleed: Making The Case For SDN

Software-defined networking technology could help protect against vulnerabilities like Heartbleed. It's time to develop a more mature SDN option.

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?

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.)

Reports

Comments

Charles.Babcock

User Rank: Apprentice

Thu, 04/10/2014 - 12:58

SDN is not just for flexibility

Lori MacVittie makes a good point.The software-defined network is good, not only for the flexible protocols you may implement, but for the the short term things you can do as well. The ability to isolate and reject the requests that may now be creeping into the data center as a result of HeartBleed is a necessary weapon in the netwoork manager's arsenal.

SDN is a fundamental change to the traditional network. It's a new framework/architecture instead of a standalone technology. From networking protocol perpsective, it provides a proactive approach to mitigate possible flaws/vulnerabilities. But I am afraid it will take longer time to establish SDN framework than developing the security patch - there is still some distance from the ideal state.

The IT landscape might be our modern day version of the wild wild west. Security issues that get lots of media attention are easy to react to.

The truth of the matter is that security vulnerabilities that affect consumers are likely to be much more prevalent than the average person realizes. Perhaps it is time for internet security software developers to step up to the plate and address this growing need. If I go to a given website, there should be a quick and easy alert system in place to let me know where it currently stands as well as its security track record.