Is SDN always vulnerable to network security vulnerabilities?

Theoretically, SDN technology should bring about a safer network. Because, through virtual networks to programmable stacks, the network will become more flexible and operations should be more automated, which should mean less "fat finger" disaster.

However, for any interconnected system, when we allocate basic operations to software, we also introduce new risks. When we connect servers to the internet, we know that some servers will be attacked, so we do our best to reduce this risk. But what happens when the network itself is under attack? What is the SDN toolkit? What is comprehensive and effective SDN security? How can we avoid SDN vulnerabilities?

Is SDN the cradle of Stuxnet's dream?

SDN has become short for network programmable. Both standard-based solutions and proprietary technologies from a single vendor (building your own OpenDaylight solution or the SDN environment created by VMware) bring about the same dilemma: you will be forced to believe that this new complicated software carries the key to your kingdom. This "solution" will involve a wider range and will change power and capacity to a level that exceeds any senior administrator. It also controls the status of network logs.

However, the problem is not so bad, but enterprises need to consider the impact of SDN security belt, or worse, the zero-day vulnerability exploitation. One of the reasons why Stuxnet is so hard to create is the various challenges it needs to overcome. It needs to respond to multiple versions of proprietary industrial controllers and use various protocols and application interfaces (APIS). But in the SDN environment, the situation is different.

SDN brings new network security problems

Through a programmable network, worms no longer need to use existing network cracks; they can seize a weak control point, create a backdoor through this control point, and then hide it. Unlike Stuxnet, SDN worms do not need to manage hundreds of different attack vectors. Even in the deployment of a proprietary vendor, SDN worms can be controlled through well-recorded and easy-to-navigate APIs.

When we migrate from the CLI, SNMP, and other "Old World" interfaces, we also face an additional threat. We will connect our performance monitoring and security policy scanning systems through the SDN architecture. That is to say, If attackers break the SDN control layer, they can hide their whereabouts from the monitoring and security systems. As the technology matures and we rely more and more on automation, we should also expect the same changes in administrator configuration as the system, especially in small and medium-sized enterprises. After all, less experienced teams are unlikely to discover security problems better than the green screen administrators they replace.

How to Avoid SDN security nightmare

The future of SDN is bright. We should not come to the conclusion that SDN will bring a backdoor to the US National Security Agency. This technology does bring about a series of new challenges, but we can use the rich experience gained from other programmable platforms to solve these problems, such as servers. Whether you are communicating with the supplier or trying to build your own SDN solution, when deploying a secure SDN, consider the following:

• How many ratio documents (or marketing materials) are used for security? Is Security something dispensable, or is it part of the solution architecture?
• Does this solution not require security protection in the firewall? Too many products think that there is no Internet-oriented system to enjoy magic-like security protection.
• For combined SDN and other composite solutions, how does the consortium network manage the trust relationships allocated between controllers? Where will you deploy the demarcation points to limit the scope of multi-layer allocation changes?
• How will this solution manage distributed policies? Do all controlled devices trust change requests from any long command lines? Can they be aware of the inherited, simulated, or requester roles?
• How do you trust or verify? Does the solution contain at least a few stone-age technologies to monitor SDN controllers that are not under its control?

Like any other new technology, network programmability may encounter some problems in the early stage, but if we look a little farther, ask the problem, and study it under a laboratory microscope, this will be a good thing