Software-Defined Networking and Security

Software-Defined Networking (SDN) is a new approach to building networks; previously hardwired network topology gets replaced with a software implementation. For large-scale networks (think “cloud”), the additional flexibility and efficiency make all the difference in the world.

Within Software-Defined Networking, one trend is to move data using off-the-shelf, generalist server processors rather than specialized integrated circuits (ASIC). Again, to much flexibility and efficiency even within the spectrum of SDN solutions.

The security-sensitive, however, may be concerned with the loss of the security that was implicit in the relative inefficiency of the old ways. When the only way to adjust the routing requires physical access to a room of switches, security is “enhanced” as a consequence of this very limitation.
The new programmable ASICs for Software-Defined Networking may be susceptible to attacks that previous, dumb ASICs were impervious to by virtue of being dumb. And of course, generalist processors can run arbitrary code, expanding the possibilities for unintentional failure and malicious appropriation.

How do you make sure that the software works in Software-Defined Networks?

TrustInSoft verified safety properties for part of an Open-Source software component found in many SDN switches, the DPDK framework from The Git repository reveals that the main contributors are leading SDN companies such as Intel or 6WIND. The perimeter of the study was the testpmd application, plus the parts of the DPDK library exerted by testpmd. The verified properties were the absence of undefined behaviors, including all the memory errors and integer overflows that are at the root of many bugs and security vulnerabilities.

The few defects found were minor in the extreme, and still the code-changes to fix them were well-received by the DPDK community. Interestingly, with the help of TrustInSoft Analyzer to make sense of this very specialized code, Julien was also able to identify a minor optimization opportunity in this code already written with an eye towards performance. But the important fact is that since the study, carried out to completion, did not identify any Heartbleed-like memory error, no such errors exist in testpmd.

So, then, how do you make sure that SDN software works and is secure? We think that one natural step is to extend the analysis initiated by Julien to the rest of DPDK, and then to the other software components of an SDN device, using TrustInSoft Analyzer. Not to mention other software layers that are critical to the network’s security.

No More Heartbleed


The Heartbleed Bug ( is a severe vulnerability in OpenSSL a popular cryptographic software library. This weakness allows stealing the information protected, by the SSL/TLS encryption used to secure the Internet.

OK. So one more bug has been found. What’s next? Maybe a second Heartbleed? To address this issue, at TrustInSoft, we rely on mathematical methods to provide guarantees on existing software. For instance, we created the PolarSSL Verification Kit. PolarSSL is an alternative to OpenSSL. The PolarSSL Verification Kit guarantees the immunity to the following weaknesses: CWE 119 to 127, 369, 415, 416, 457, 476, 562, 690. The Verification Kit tells you how to compile, configure, and use PolarSSL to benefit from these guarantees. It means that a flaw similar to Heartbleed cannot occur if you follow the verification kit.

All the bugs we found (for instance CVE-2013-5914) have been reported to Paul Bakker, main designer and maintainer of PolarSSL.

Now, if you want, you will not suffer from the next heartbleed. Buy TrustInSoft’s PolarSSL Verification Kit: being on the safe side is cheaper than you imagine.

NIST assessment

samate How is it possible to protect smart phones, information systems and computers from cyber threats? To answer these questions NIST launched the SATE exhibit. TrustInSoft technology was the only one to meet SATE V Ockham Sound Analysis Criteria. full story