Security has a problem with Software Defined Networking. Organizations are embracing SDN for its adaptability to business needs, lower acquisition costs, and potentially lower operating costs. However, there is insufficient practical experience to guide the security industry in adequately supporting SDN infrastructures. This results in either organizations moving forward with SDN without waiting for security to catch up or organizations moving forward at greater expense by shoe-horning traditional security capabilities into SDN architectures. We feel that the time has never been better for new network security upstarts to challenge the status quo.
The Ogren Group View
It seemed like every other keynote presentation at RSA Conference 2015 pointed out that security has failed miserably, however it was terribly difficult to find compelling ideas from these industry leaders as to how to fix the security problems. Much of the discussion focused on the existence of security product silos that do not interact effectively with each other, and the need for organizations to try harder.
It is our take that many of the traditional network security silos are obsolete and over-valued, and that the network security industry desperately needs to get ahead of the curve by adopting the principles of software defined networking architectures. Traditional inspection and rigid perimeter concepts will be even more ineffective in cloud-driven SDN architectures than they are today.
The security vendors that break the mold of traditional security, with a particular emphasis on detection and incident response/automated remediation, will have significant security impact in the SDN world.
With challenges come opportunities for security vendors. Security is typically a reactionary industry that often gets called out for battling attackers with defenses designed for the last cyber-war. We believe it is very clear that traditional security products will struggle to be effective in SDN environments.
SDN, with its ability to efficiently reconfigure the network, is a disruptive approach that requires security vendors to step up with innovative solutions to remain relevant. We find significant potential in companies such as Cyphort, Exabeam, Fortscale, LightCyber, TaaSera, vArmour, Vectra, and zScaler that offer many of the characteristics of successful SDN-oriented security companies:
Adapt with changes in the network infrastructure. Static, monolithic products will have to become agile and flexible. For instance, IPS's cannot expect to be on every data path and placing an IPS inside every virtual server makes little sense. Many of the content inspection security capabilities, such as IPS and DLP, will have to become software defined themselves to deliver benefits to the business.
Empower analytical detection capabilities. It will become increasingly difficult for security teams to detect the presence of attacks as resources are automatically provisioned, upgraded, put in motion, and expired. While organizations understand that security cannot block every attack, they do need more help detecting attacks living within their networks. We feel that there is room to grow for analytical and behavioral approaches that can be customized to detect faults within complex networks.
Accelerate incident response and incident remediation. Just as SDN offers the capability to adapt to business performance demands, so too should SDN adapt to security incident demands. Security seems to be one of the few industries that is excused when its products fail - organizations will seek out vendors that make headway automating incidence response and remediation for attacks that evade security.
In many ways SDN is the antithesis of traditional security concepts. The SDN approach of virtualizing control planes and data planes for a flexible network that can adapt at the speed of business presents problems for security vendors schooled in rigid controls and content inspections.
One large challenge is aligning security with the adaptive nature of SDN. Software defined networks promise to dynamically shift resources to meet business demands, even if those resources lie off premise in the cloud. Security needs to adapt with shifting applications and network resources to ensure acceptable coverage, prevention, detection, and remediation capabilities.
While security prefers to inspect all content and log everything for subsequent investigations, this comes at the price of performance degradation if done inline. That is why most IPS and data collectors hang off switch SPAN ports, but forcing traffic routes through security devices becomes much more challenging with SDN. Placing security devices everywhere is just not practical for organizations committed to an SDN infrastructure.
Finally there is the challenge of access controls and blocking risky applications, connections, and users. A Software Defined Network needs to react to a dynamic business environment, effectively responding to spikes in service demands without destabilizing the network. There simply is not going to be much opportunity in most verticals for security teams to insert themselves into these processes.
The Security Driven Network concept, defined as security policies inhibiting evolution to business-enhancing Software Defined Networking, is a dog that will not hunt for most organizations.
Get in the minds of IT
Some of the security challenges in an SDN world revolve around the hesitancy to deploy new security technologies. IT can be risk averse when it comes to evaluating new architectures, especially when it comes to security with concerns about effectiveness, loss of control, costs, and the job continuation program if new technologies fail. It is incumbent on SDN-oriented security vendors to educate corporate decision makers so they can act without resorting to old ineffective bromides or the lack of compliance history as excuses to not change, and to help justify budget line items for SDN security proof-of-concept projects.
The industry does not understand what it means to operate a compliant software defined network. We feel it is the vendors that must interpret compliance standards for SDN, and in some cases form best practice standards to help guide early adopters.