Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Software-defined security: The future of network security?

Software-defined security is becoming an IT buzzword, but does it live up to the hype? Expert Kevin Beaver takes a look at the benefits and pitfalls of the technology in the enterprise.

If you haven't heard, the latest buzz around network security is software-defined security.

A sister technology to software-defined networking, (SDN), software-defined security (SDS) allows businesses to deploy and automate network segmentation, intrusion detection and other network security controls with software instead of using more traditional, siloed security controls. SDS uses virtualization-like resources that are disassociated from the hardware layer to cross traditional boundaries we've known, such as network segments and business functions, to bring security control up to a higher layer.

So, is SDS for your business? On the surface, SDS appears to be nothing more than what we've already been doing to manage security -- it's just all managed at a higher level via policies and objects that are defined and customized for any given enterprise. It's not unlike how organizations are currently managing certain storage systems, firewall policies and objects within a directory service. SDS just builds upon this concept at a higher layer of abstraction. It's logical versus physical.

Software-defined security offers a number of specific benefits that can improve enterprise security. For example, SDS:

Of course, like all great things, there are some potential drawbacks to SDS.
  • Allows companies to organize specific security groups and systems (e.g., with policies for hosts, applications and similar network entities) that cross physical and logical boundaries and have proven to be difficult to manage with any semblance of efficiency.
  • Facilitates dynamic security domains for mobile, cloud and across traditional enterprise network systems, allowing organizations to bring up and take down systems at will and, at the same time, to be able to consistently enforce security policies across the board, regardless of the timing and the location of these systems.
  • Offers better integration with other software-defined technologies enterprises may already have in place (e.g., SDN) to move toward more holistic automation for such security technologies as intrusion prevention, identity and access management, data loss prevention and geolocation.
  • Focuses intelligence at a higher level -- in the software -- rather than in the hardware, which can allow enterprise architects and security managers to focus on policies rather than on keeping systems running at a lower level.

Of course, like all great things, there are some potential drawbacks to SDS. These include:

  • An initial learning curve will be needed to provision, deploy and enforce security policies across unique systems and platforms that may or may not support SDS.
  • A new type of complexity involving the creation and management of security policies will be introduced. The who, what, when, where and why of policies will have to be well-defined before your organization embarks on such a project.
  • Specific server hardware (either your organization's or in the cloud) is still going to be needed to run SDS.
  • Price might be an issue: Though hardware is relatively inexpensive, most SDS products are expensive and have higher margins.
  • Outlying security controls for such technologies as malware protection and content filtering security may not scale well at this level.

Your enterprise will need to make some careful considerations in order to decide which security controls are to be deployed via SDS. Some organizations might benefit from SDS more than others, such as those in highly regulated industries (e.g., financial) or larger enterprises that have a more national or global presence. SDS isn't a one-size-fits-all technology; each organization's use case will differ. In the end, it shouldn't matter whether your security controls are hardware- or software-based, as long as you are using what's truly needed to minimize your risks.

My recommended SDS focal points, at least for now, would be the ones that are causing your enterprise the most pain. These are likely in the areas of IPS, access control, and event logging and monitoring, but your deployments will certainly be limited to what your vendors support. However, if you're an Intel or Symantec shop -- as many businesses are -- you're in luck: These vendors will readily sell you these services today.

As with the cloud, big data and even cybersecurity in recent times, I suspect SDS is going to be the next big buzzword we'll be hearing for a while. As to whether or not it turns into something very positive for the enterprise, we'll have to wait and see. Talk is cheap, but I'm optimistic about the innovation in this area.

About the author:
Kevin Beaver is an information security consultant, writer, professional speaker and expert witness with Atlanta-based Principle Logic LLC. With over 25 years of experience in the industry, Kevin specializes in performing independent security vulnerability assessments of network systems, as well as Web and mobile applications. He has authored/co-authored 11 books on information security including the best-selling Hacking For Dummies and The Practical Guide to HIPAA Privacy and Security Compliance. In addition, he's the creator of the Security On Wheels information security audio books and blog providing security learning for IT professionals on the go. You can reach Kevin through his website and follow him on Twitter at @kevinbeaver.

Next Steps

Learn why you need SDS for SDN

Join the conversation: Has your company invested in SDS?

This was last published in December 2014

Dig Deeper on Secure SaaS: Cloud application security

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Do you think SDS is the future of network security?
I guess new technology will always be at risk as more threats are launched each day. In my view, SDS can be a good way to monitor any threats made towards my organization, as well as allow or restrict access controls. But to ensure my network remains safe, I still need to incorporate traditional methods that can possibly guarantee network security. Hence, I don't think SDS will contribute greatly to network security, minus my input.
yes i think so
wangzelang, this could be a good place to start to learn more about software-defined security
Nice post Kevin. There's a ton being written about SDSec; it's being driven by the increased investment in cloud technologies by companies of all sizes. I disagree, however with the assertion that "Specific server hardware (either your organization's or in the cloud) is still going to be needed to run SDS."

There are a number of "Security as a Service" (SaaS) providers on the market today that implement various components of SDSec. Readers with a SDSec mindset should look for the following 5 essential ingredients from SDSec solutions they're considering:

Abstraction: security and compliance for the cloud needs to be virtualized and able to operate regardless of where underlying hardware might be physically located.

Automation: security automation is required that implements security and compliance controls (e.g. firewall policies, intrusion detection) with minimal human intervention in deployment, configuration, and operation.

Orchestration: Security orchestration platforms centrally manage the composition, deployment, and management of individual control components into more complex, service-oriented security systems.

Automatic scalability: Scaling application and infrastructure environments automatically, on-demand, and in near real-time is one of the essential capabilities that makes cloud computing so valuable. Security controls must be deployed directly into the application scaling mechanism (e.g., building controls directly into cloud-burstable virtual machines) or must have the ability to scale based on application scaling triggers (e.g., detection of a cloud-burst triggers deployment of more virtual appliances).

API Enabled: Security monitoring and enforcement control functions should be fully accessible via open Application Programming Interfaces (APIs), so that security and infrastructure organizations can fully integrate and use the tools with which they’re already familiar. This speaks to the original post emphasis on layers and the integration between the layers.
Thanks a bunch for the additional info mbishop006!