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.
Opportunities
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.
Challenges
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.
No comments:
Post a Comment